まとめ

この講義では、「設計」を変更しやすいソフトウェアをつくるための考え方として扱ってきました。

• アーキテクチャは変更を容易にするためにあり、プログラマに対して適切な制約をかけるものです
• 型を使うことで、変数の値を制約し、想定外の値の混入を防ぐことができます
• モジュール分割を行うことで、関心ごとを分け、テストパターンを減らすことができます
• インターフェースを使うことでアクセス方法を制約し、実装の入れ替えを可能にします
• 先人の考えたアーキテクチャパターンに沿うことで、適切な責務の分割を考えやすくなります

覚えておいてほしいこと

アーキテクチャに絶対はない

• 「これを使えばいついかなる時でもOK」という魔法のアーキテクチャは存在しません
• 取り扱うシステムの性質・規模・改修頻度などを見て、選択・検討していく必要があります
• 特定のアーキテクチャパターンを採用すること自体が目的にならないようにしてください
  • 何を目的にしているのか？
  • そのシステムに適しているのか？
  • 将来の変更に耐えられるのか？

  を考えることが重要です

とはいえ、オレオレ実装には気をつける

• 一般的にどうやっているのかを調べる習慣は大切です
• オレオレ実装は後の人が理解しづらく、レガシー化しやすくなります
• 既存のパターンや考え方は、先人たちの失敗と工夫の蓄積です

数年先のことを考える

• 開発はスタートでしかありません
• 数年後に色々忘れた自分や、新しいメンバーが運用していけるか？を意識しましょう
• アーキテクチャを考えるだけでなく、それを説明し継承できるようにしましょう
  • ex) Design Docs、Architectural Decision Records(ADR)、…etc

終わりに

口を酸っぱくするようですが、アーキテクチャに銀の弾丸などない、という言葉をもう一度お伝えしておきます。

これから皆さんは業務でさまざまなコードに出会うことになります。

つらい気持ちになるコードと向き合うときもあるでしょう。

ただ、どれだけ考え抜かれたシステム設計でも、時間が経つにつれて技術的負債は増えていくものです。

ベースとしている言語や OS は相対的に古くなっていきます。担当者も変わっていきます。

当時は最先端だった設計も、さらに良いとされる設計手法に移り変わっていった結果、誰もわからない設計になることがあります。

ビジネス的な判断で、想定していた以上の仕様変更を乗り越えるために歪めざるをえないこともあります。

それでも、システムができるだけ綺麗な状態を保ち、可能な限り寿命を延ばせるようにするのが設計の役目です。

今回の説明で内容を全て理解しきれなくても大丈夫です。

業務でコードを見たときに「わからないな」と思ったこと、「なんでこうしてるんだろう」と気になったこと、それを大切にしてください。

その違和感が、よりよい設計につながっていきます。

どこでも通用して、すべてを解決してくれるような銀の弾丸はありません。

一緒によりよいソフトウェアの姿について考えていきましょう！