他人の遺産で築く資産

人の遺産で築く資産 だけど試算は悲惨 無惨

— 一級河川さん (@aereal) 2013年4月25日

いまさわっているコードがどうしてこんなにつらいのか考えてみたけど、いろいろ要因はあるにせよ、結局、背骨となる考え方や指針が共有されずにいろんな人が手を入れていった結果、「おれはこう理解していた」というすれ違いが積み重なったからだ、と一応の結論付けが (自分の中で) なされた。

たとえば Rails のような考え方の指針を与えるアプリケーションフレームワークがあって、それを使う限りは与えられた指針に基いて設計しないといけない。設計で迷ったときや悩んだときの判断を逐次、いちから試行錯誤することになる。

人間の試行錯誤は記録しづらくまた再生しづらいものなので、たとえば実装の意図がわからず仕様かバグか判断がつかない場合にたいへんなコストがかかることになる。

適切に考え方の指針が提供され、かつそれに則って設計が行われると、遡らなければいけない思考の過程がかなり省かれうる。

省かれるというのは、アプリケーションソフトウェアから省かれるということで、実際にはアプリケーションフレームワークが持っているので省略というより移譲に近いと思う。

もしもコードというかたちでそういったアプリケーションフレームワークを構成するとしたら、アプリケーションソフトウェアの実装を共有するようなものではなくて、むしろコードを解析して命名やクラスの大きさについてひとつの指針に基いて指摘してくれるようなものになると思う。

もちろん、日々、手が入れられるソフトウェアをこれからも安全で堅牢に保つためには人の手も必要で、コードレビューのような場は必ず設けられていて然るべき。

的確な判断を素早く下し計算量を適切に抑えて実装できるような、そんなスーパーソフトウェアエンジニアが存在したとしても、それが人間でひとりである限り SPOF でしかない。

レガシーコード改善ガイド (Object Oriented SELECTION)

yugui さんがリファクタリングするとき、心が折れそうになりながらもこの本を読みながら為した、というようなエピソードを聞いた記憶があるので、ぜひ読みたい。