新人の頃、なぜ設計を理解できなかったのか
エンジニアとして働き始めた頃、
ずっと疑問に思っていたことがあります。
なぜこのシステムはこんなに複雑なのか
コードを書くこと自体は理解できます。
しかし、実務のプロジェクトに入ると
急にこういうものが登場します。
Controller
Service
Repository
DTO
Entity
そして設計レビューではこう言われます。
責務が分離できていない
依存関係がおかしい
レイヤーを意識してください
新人の頃の私は正直こう思っていました。
いや…動けばよくない？
しかし数年実務を経験して思うのは
新人の頃に設計を理解できなかったのは
とても自然だった
ということです。
今回は
新人の頃に設計が理解できなかった理由
を、自分の経験を元に整理してみます。
理由① 設計の「目的」を知らなかった
新人の頃の私はこう思っていました。
設計 = コードを綺麗に書くこと
しかし実際は違いました。
設計の本当の目的は
変更に強い構造を作ること
です。
システムは必ず変わります。
仕様変更
機能追加
バグ修正
このとき重要なのは
変更しやすい構造
です。
例えば
Controller → DB
のような単純な構造だと
すぐにコードが壊れます。
一方で
Controller
↓
Service
↓
Repository
のように分けておくと
変更の影響範囲
を小さくできます。
新人の頃は
未来の変更
を経験していないので
設計の意味が理解できませんでした。
理由② 小さなプログラムしか書いたことがなかった
新人の頃に書いていたコードは
数百行
くらいの規模でした。
この規模なら
Controller → DB
でも全く問題ありません。
しかし実務のシステムは違います。
数十万行
数百テーブル
数十人の開発者
という規模になります。
この規模になると
1行の修正
↓
10画面に影響
みたいなことが普通に起きます。
だからこそ
責務分離
レイヤー設計
依存関係管理
が重要になります。
新人の頃は
大規模システムの怖さ
をまだ知らなかったのだと思います。
理由③ レイヤーの意味を理解していなかった
新人の頃はこの構造が本当に謎でした。
Controller
↓
Service
↓
Repository
当時の感想は
なんでこんな遠回りするの？
でした。
しかし今思うと
それぞれの役割はシンプルです。
Controller
= HTTP通信
Service
= ビジネスルール
Repository
= データ操作
つまり
役割ごとに分けている
だけです。
料理で例えるなら
注文
↓
調理
↓
配膳
のようなものです。
全部一人でやると
すぐに混乱します。
システムも同じです。
理由④ 設計は「コード」ではなく「考え方」
新人の頃は
コード = 理解できる
設計 = 難しい
と感じていました。
理由は単純で
設計は
抽象度が高い
からです。
例えばコード
userRepository.save(user);
これはすぐ理解できます。
しかし設計の議論になると
永続化層
依存関係
責務分離
のような概念になります。
つまり
設計はコードではなく
考え方の話
なのです。
そのため
経験
がないと理解しにくいのだと思います。
理由⑤ 設計の失敗を経験していなかった
個人的に
これが一番大きいと思っています。
新人の頃は
設計ミス
を経験していませんでした。
しかし実務では
巨大Controller
巨大Service
循環依存
などが普通に起きます。
その結果どうなるかというと
1行修正
↓
別の機能が壊れる
という状態になります。
この経験をすると
初めて
設計の重要性
を実感します。
正直なところ
設計は痛い経験から学ぶもの
だと思っています。
個人的な考察
ここまで振り返って思うのは
設計は知識だけでは理解できない
ということです。
理由はシンプルで
設計は未来の問題を解決する技術
だからです。
新人の頃は
未来の問題
を知らないので
必要性が見えません。
しかし実務で
仕様変更
機能追加
バグ修正
を何度も経験すると
あの設計には意味があったんだ
と少しずつ理解できるようになります。
まとめ
新人の頃、設計が理解できなかった理由は
設計の目的を知らなかった
小さなプログラムしか経験していない
レイヤーの意味を理解していない
抽象度が高い
設計ミスを経験していない
でした。
今振り返ると
理解できなかったのは当たり前
だったと思います。
もし新人の頃の自分に
アドバイスするならこう言います。
設計はすぐ理解できなくていい
実務を経験していく中で
少しずつ理解できるものだからです。