この記事はハワイアンAdvent Calendar 2020 2日目の記事です。ツイートアナリティクスによれば、1日目のブログへのエンゲージメントは32という事だそうです。今確認のためにもう一回開いたので33です。わたしは自分のブログを何回も読み直すので、99%は自分のアクセスでしょう。これまでご愛読頂きありがとうございました。 Advent Calendarの前半では進化的アーキテクチャについて触れてやっていくつもりなので、その為の前提を埋めていきたいと思います。
2020年現在、サービス開発や製品開発の為のソースコードの自動生成が進んでいますが、残念ながら製品開発の根幹となるロジックは人間が書いています。人間がソースコードを書くこの時代において、ソフトウェア設計とはなんの為にあるのでしょうか。リファクタリングはなぜ行うのでしょうか。綺麗なコードを書くのはなんの為でしょうか。綺麗なコードは誰にとって綺麗なコードなのでしょうか。Testableなコードを書くのはなんの為でしょうか。良い設計とはなんなのでしょうか。こうしたトピックは時代の変化とともに再考する必要があります。それはなぜかと言われれば、ソフトウェア設計はソフトウェアに対する投資の側面が非常に強いからです。例えばプロトタイプフェーズからいざ製品化やサービスの拡大となった際によく訪れる「成長痛」といったものもソフトウェアアーキテクチャの寿命が尽きたといえますし、無意味な拡張性や再利用性も理解可能性を低下させ反感を買い生産性の低下にも繋がり結果的にビジネスチャンスを失いかねません。それでも尚、サービスの根幹となるソフトウェアが漸進的に成長していくための投資のバランス感覚を養う必要があります。わたし自身そのどちらの失敗経験もあるので耳の痛い話ではあります。
この話をすると2日目にして全て終わらせてしまう事になるので翌日以降に回しますが、そうした経験というのは機会に恵まれなければなかなか得られないもので、想像だけでは及ばない所ではあります。しかしながら自身のエンジニアの半生を思うと常に意識してやっている事があり、これは身近な所から実践できるし、自分もこれを継続して設計力を養ってきた節があるので、2日目はそれを文書化して終わりにしようと思います。
設計力を伸ばす為に常に遺書を残す
「遺書」とはなんらかの要因で死を覚悟した人が残す文章です。ソフトウェア開発における死の定義については人によって判断が違う所があります。生産性を伴うものであったり、ソフトウェア内部品質を下げるBad Smellなコードが生まれるようになった、ソフトウェアアーキテクチャを支えていた人がチームから離れた、そもそもサービスが終了した等、多岐に渡るでしょう。チームでのソフトウェア開発に携わっているのであれば、チームで認識を揃えておくと良いでしょう。その全ての要因を考慮した遺書を書いてください。
遺書は寿命が尽きたとき、該当ソースコードが削除された時、あるいは寿命より前にサービスが終了した時にあらためて開封し、遺書の内容と現在が一致しているか確認してください。ずれていれば、設計力がまだまだ足りないという事です。予期せぬ出来事があって寿命を迎えた、もしくは寿命を迎えることなく終了したのなら、それは今後の寿命の計算に考慮しましょう。
遺書の内容は可能であればチームや組織に対してオープンな方が良いですが、奥手なアーキテクトや、一個人として取り組むのであればうちに秘める形でも良いでしょう。遺書なんて表現をしてますが、要するに設計をソフトウェアに反映して一定期間運用したらちゃんと蒸留する機会を設けよう、という事です。
今日あなたが取り組むものについて、寿命を計算してみてください。プログラミング初心者であれば1行のコードから徐々に、メソッド、型、コラボレーションへと対象を大きくしていきます。中級者・上級者であれば、モジュール、アプリケーション設計全体、複数アプリケーションと広げていってください。記載する内容は以下を参考にしてください。
- ソースコード、メソッド
- たとえばソースコードの間に空白行1行を挟んだとして、その空行の意味を説明でき、かつ寿命はどれだけか、書いてください
- その寿命を具体的な期間として示した際の根拠となる評価軸はなんでしょうか。これも書き残してください。自分なりの表現で良いです
- 型、コラボレーション
- その型はどうなったら寿命を迎えるのでしょうか。書いてください
- 何かしらの設計パターンを適用してソースコードが綺麗になった、よかった、で満足せず、その設計パターンを適用する事で周辺のソースコードの寿命が何年伸びたか具体的に書いてください
- 合算して、今あなたが開発しているソフトウェアが現在の設計で何年持つか試算してみましょう
- モジュール、アプリケーション設計全体、複数アプリケーション
- あなたが開発チームからいなくなったらどうなりますか
- チームメンバーのスキルセットを踏まえ、その設計は何年持ちますか。チームメンバーの教育も前提でしょうか。書いてください。会社務めであれば、会社の人員の流動性・組織運営の風土も考慮してください
- 今取り組んでいるアプリケーションがn年後にどうなっているでしょうか。予測できない未来は予測しなくて良いですが、いつまでたってもそれでは成長痛から逃れられません。アーキテクトとしては未熟です。サービスに関心を持ってください。サービスの展開が想像できないのであればプロダクトオーナーともっと会話し、予測できる未来は予測し、精度を高めて遺書に書き記してください。
もちろん、これらは動くものが作れる前提です。動いてなければ寿命もなにも生まれていません。