今週は技術的な選択の仕方について考えることが多かった。
どうやって決めるか、というだけでなくて、どこに決めポイントがあるか、というところの見極めも難しい。
何も決めずに進んでいって、あとで見返すとすごいことになってしまい、ここをもうちょっと考えておけると良かったね、ということもあるし、考えすぎて重厚に作りすぎだったので、あとからシンプルな形に直していく、ということもある。
個人的には、ふだんはこのように考えています、という手順を書いておくと、
- 実現方法を考えるだけでなくて、他に取れる作戦がないか考えていく
- よさそうな方針が、他の作戦と比べてこれが一番良い、という確証を得る
- 確証が得られないときは、考えて決める
- 昼休みにプールに行って泳いでいると、これだけ考え続けて何も出てこないということはこれで行くしかない!と決められることが多かった
というような形でやっていると思う。これでできるのでこれでいきます、だけでなくて、他の案と比べてもたしかにこれが良いですね、というところまで考えきれてないと、他になにかあるのでは、と思ってしまう。どの方法でやってもできるのはわかるのだけど、一番良い選択をしたくて、どっちでもいいけど、雰囲気でこっち、みたいなことで決めてしまうと、あとでひどい目にあうのではないか、ということがある。
個人的には過去にさまざまなひどい目にあって腕力で直す経験をたびたび経験しているので、良い選択によって不幸な目にあう人類が減ると良いと思っているけど、ひどい目に遭うのも織り込み済みで、みんなに平等に実験してもらったほうがよいのかな？小さい失敗なら歓迎で、どこまでの規模の失敗は推奨する、これ以上は失敗したときの夫妻の規模が大きすぎてサービスの継続開発が不可能になるので慎重に、みたいな基準があればよいのかな、わかりません。
ひどい目にあったときは散歩に行って心を落ち着けたりしていた。いつの間にかすごいことになってしまったコードを、半日くらいエディタにかじりついてなんとかなるまで机を離れない、みたいな、腕力以外のアプローチのとりようがない経験がよくある。
こういう事を考えるときに思い出すのはこの辺の本。
- レガシーコード改善ガイド
- 学生のときに読んだので感想書いてなかったけど、こういう純粋な(?)字句的なリファクタリングが必要になる、くらいの失敗ならいつでもやったら良いと思っている
- レガシーソフトウェア改善ガイド読んだ - hitode909の日記
- アーキテクチャの刷新や、すべてを捨てての書き直し、みたいな話が載っていた
- 進化的アーキテクチャおもしろかった - hitode909の日記
- 変化に適用できる尺度を考えながら設計しましょう、という話があったと思う
- Design It! - hitode909の日記
- どこまで遅らせられるかという話や、権限移譲の話。
- 書名を忘れたけどMozillaの人の書いた本で、プラグイン機構を構築したけど世の中にプラグインが1つしか存在せず、プラグインは不要だった、という本
- 凝ったことやらずに済むならそれが一番良いですねと思う
- プラグイン1個しかないエピソードは印象に残ってるけど書名を思い出せない…
- 発見した!!!!!!コード・シンプリシティでした
コード シンプリシティよかった。機能が増える未来を予想してプラグイン機構作ったけど、結局一箇所でしかしか使われないとかはひどいから、今必要なもの作って変更しやすくしておこう、みたいな話がいろいろのってて良い感じやった。
— hakobe (@hakobe) 2012年12月1日- →コード・シンプリシティ - hitode909の日記
- エンジニアリング組織論への招待 - hitode909の日記
- 負債とは何でしょうか、という話が腑に落ちた。今後の改修するかどうかの期待値をみて決めましょうという話がおもしろかった
技術的な選択、昼ごはん何にするかみたいな好きに選べるものではなくて、重要なところは、これしかない、というところまで情報を集めたいのだけど、どういうときが重要かは自明でなくて、そのタイミングさえ正しく分かれば大半の開発がうまくいき、タイミングを逃すと作りすぎか雑すぎになる気がする
— 趣味はマリンスポーツです (@hitode909) 2020年9月2日
