「達人プログラマー―システム開発の職人から名匠への道」を読みました。
こちらは UNIXという考え方―その設計思想と哲学と共に t_wada さんが「若者向け課題図書」として挙げられていた本です。
necojackarc.hatenablog.com
読んだ感想ですが、流石若者向け課題図書と言うだけあって「全部入り教本」という感じでした。
開発者としての哲学に始まり、ツール、設計技法、そしてプロジェクト運営など、
システムを作る上で必要になることに対して一通り言及しています。
そして、それぞれで述べられている「心がけ」は色々なプラクティスや手法にも通ずる的を射たものでした。
確かにこの辺りの内容は早い段階で抑えておくべきだなと思います。
知っておいて欲しい心がけの宝庫でした。
ただ、そういった特性上、タイミングによって響く言葉は違うということも痛感しました。
リーダブルコードの時もそうだったのですが、
知っていることや当然だと思っていることも多く載っており、
一瞬「せやな」という感情に支配されていたりもしました。笑
necojackarc.hatenablog.com
もちろん幅広いトピックを扱っているので、響いた部分も多々あります。
以下、響いた言葉を一部抜粋していきます。
早めにクラッシュさせること
障害対応やデバッグをしている際に、本当の原因がどこかわからないで困ることがあるなというのを思い出しました。
例外が起きた位置でクラッシュさせておけば、原因究明に大いに役立ちます。死んだプログラムは嘘をつかない。
全ての例外ハンドラーを除去しても、そのプログラムは動作することができるだろうか?
例外を通常の制御フローに組み込むのは間違いなく悪手です。
そしてこのセリフは例外ハンドラーの使われ方が正しいか正しくないかを考える際に役立つなと思いました。
ソフトウェアは建築と言うよりもガーデニング(つまりコンクリートではなく、より有機的なもの)に近い
「建築のようには絶対行きません!そうだそうだ!もしそうならウォーターフローでうまくいくはずだ!」みたいな気持ちになりました。
今度からソフトウェア開発はガーデニングに例えようと思います。もしそんな機会があれば……。
まず、初期の計画と条件に従って、庭にさまざまな植物を植えます。すると、あるものは力強く育ち、あるものは枯れてコンポストの材料になってしまいます。また、日当たりや雨風の関係で植物をお互いに動かすようなことも行います。育ちすぎた植物は、株分けしたり剪定し、配色の合わないものは美的感覚を満足できるところに移動させます。雑草を抜き、必要に応じて肥料もやります。常に庭の健康状態を監視して、必要な調整(土壌、植物、レイアウト)を行うのです。
小さい内に摘出しないと肥大化して転移するという点で、まさに腫瘍だなと思いました。
腫瘍を見つけたらしっかり無視せず、チケットを切るなど何らかの対応はしておきたい。
プロジェクトの用語集を作ること
これ大事!共通言語大事!
枠にとらわれずに考えるのではなく、枠を見つけだすこと
見かけ上の制約に囚われず、自分が思っているよりも大きな「真の制約」を見つけるべきという話です。
枠を見誤っているケースというのは確かによくあると思います。本物の枠を見極めていきたい。
解説しない方が良い場合もある
「靴ひもの結び方を言葉で説明してみる」とこれの意味がすぐにわかると思います。
自然言語だけでは伝わらない情報がある、というのは肝に銘じておきたいです。
ストレート・ジャケット*1効果
解釈の余地を与えない設計というのは、スキルや技芸といったプログラミング努力を奪い去る意味らしいです。
解釈の余地がないとなると、単なる作業になってしまい、全く面白くないですものね。
「自然言語の限界」と「ストレート・ジャケット効果」から、詳細過ぎる仕様書がいかに害であるかがわかりますね。
まとめ
エンジニアとして心がけを幅広く教えてくれる良書でした!