はじめに
エンジニアとして働く上で、一見真逆のことを言います
- 動くものをどんどん作ってください
- 動くだけのものを作らないでください
どういうこと？
「学習のためには」動くものをどんどん作ってください
- 頭で考えるより手を動かした方が圧倒的に理解できる
- 理論だけでうまくいかないことは頻繁にある
- どんどん試行錯誤をするべき
「業務では」動くだけのものを作らないでください
- 「作る」のはゴール地点ではなくスタート地点
- あなたが作ったシステム・機能は数年、モノによっては10年以上使う
- 雑な実装は未来のあなたとチームメンバーを永劫苦しめる
- レガシーをなくすはずが、作った時点からレガシーにならないように
今回は「動くだけのものを作らない」ための話です
この場ですべてを覚える必要はありません
頭の片隅に置いておいて、見返し・思い返せるようにしてください
おさらい: アーキテクチャの目的
オブジェクト指向回より:
📄
【オブジェクト指向2024 #1】設計の目的・オブジェクト指向とは？
ソフトウェアアーキテクチャの目的は、変更容易性を高めるためにある
現場感覚から補足
-
ソフトウェアの価値は
ソフト
であることにある
- 変更できない = ハード ウェアにしない
-
変更しないという選択肢は
ない
-
ビジネス上変更の必要がなくても、変更は発生する
- OS・ミドルウェア・ライブラリのアップデート・破壊的変更
- OS・ミドルウェア・ライブラリのEOL
- 連携システムの仕様変更
- …etc
-
何もしないとシステムは”経年劣化”する
- 脆弱性の累積
- ドメイン・システム知識の消失
- 一般的な技術からの乖離
- エンジニア確保困難
-
ビジネス上変更の必要がなくても、変更は発生する
余談1: 言語のアップデート間隔
| 言語 | リリース間隔 | サポート期間 | 備考 |
|---|---|---|---|
| Python | 1年 | 5年 | |
| Node.js | 1年(LTS) | 3年(LTS) | マイナーアップデートでも動作が変わる |
| Java | 2年(LTS) | 5年(LTS) |
- リリース後に多少待ってから更新するので、実際に使える期間はもっと短い
余談2: 担当サービスのフロントアプリ(Next.js)で1週間にくるライブラリアップデート数
約10件
- マイナーアップデート以上(機能変更がある)でこれだけある
-
1年放置すると
約520件
の変更をチェックする羽目に…
- バックエンドは別言語なのでもっと増える
これらを実現するために、 エンジニアができることを適切に制約する のがアーキテクチャです 。
今回はアーキテクチャを考える上での基本的なアプローチについて解説します。