「クリーンアーキテクチャの本、勉強しました!」
「ドメイン駆動、めっちゃ分厚い本、読みました!」
「デザインパターン、勉強しました!」
で、実際の現場入って『じゃあ設計やって』って言われた時。
え?
あれ?
なんも、わからん……
あれだけ勉強したのに、なんで?w
これね、めっちゃおる。
いや、ホンマにめっちゃおる。
笑い話じゃなくて、日本のエンジニアの半分くらい、これじゃないかなって思うんですよ。
本、読んでるんですよ。
Qiitaも、読み込んでる。
Udemyの設計講座、3周してる人もおる。
「知識、ちゃんと積んでるはずやのに。」
「なんで、現場で1個も出てこないんやろ?」
これ、答えあります。
勉強の順番が、逆なんですよ。
「パターンから入る」って、詰みルート
でね、これめっちゃありがちなんですけど。
みんな、こういう順番で勉強してるんですよ。
「デザインパターン覚えた、よし、これを使える場所探そう」
「クリーンアーキテクチャ学んだ、よし、これを今の現場に当てはめよう」
「DDD勉強した、よし、うちのプロジェクトをDDDで書き直そう」
これがね、詰みルートなんですw
なんでかって言うと。
現場の設計って、「パターンを当てはめる」ゲームじゃないからなんですよ。
現場は「この問題、どう解決する?」から始まる。
パターンは、その解き方を調べたら、たまたま名前ついてただけ。
順番が、逆なんですよ。
パターンから入ると、なんが起きるかっていうと。
目の前の問題じゃなくて。
「自分が覚えたパターンに合う問題」を、無意識に探し始めるんですよw
いや、それ、パターンに現場が使われてますやんw
で、実際こういうやらかしをする
具体的に、どういうやらかしをするか。
めっちゃあるあるを、2個いきましょう。
現場で「このAPI、レスポンス遅いんですよね」って話が出たとします。
パターンから入る人、こう考えるんですよ。
「よし、キャッシュ入れよう」
「読み取りと書き込み、分離しよう」
「イベント駆動にしたらもっと速くなるんちゃう?」
いや、待って待ってw
まだ、原因1個も見てないやんw
で、実際に調べてみたらどうかっていうと。
データベースへの問い合わせが、無駄にループん中でめっちゃ叩かれてただけ。
クエリを1つ直すだけで、解決。
パターンの出番、ゼロw
大掛かりな仕組み考えてた時間、全部無駄。
クリーンアーキテクチャやりたい病、これもヤバい
もう1個、あるあるいきますね。
「うちのプロジェクト、クリーンアーキテクチャで作り直したいんですよね」
って、言い出す人。
でね、そのプロジェクト、よく見たら。
メンバー、3人。
サービスリリースして、まだ半年。
仕様が、毎週ガンガン変わってるフェーズ。
……そこにクリーンアーキテクチャ、入れたらどうなるか。
機能1個追加するのに、ファイルが10個増えるんですよw
Entity書いて、UseCase書いて、Repository書いて、Interface書いて、Presenter書いて。
「え、ボタン1個追加するだけやのに、なんで10ファイル触るん?」
開発、めっちゃ遅くなる。
仕様変更が来た瞬間、10ファイル全部書き直し。
メンバーからは「もう、素で書かせてくれ……」って地味に不満が出る。
本末転倒w
クリーンアーキテクチャが悪いんちゃう
ちょっと大事な話するんですけどね。
クリーンアーキテクチャが悪いって話じゃないんですよ。
100人規模の大きいプロダクトで、責務がめっちゃ複雑で、5年10年保守する前提のシステム。
こういうやつには、クリーンアーキテクチャ、めっちゃ効きます。
でね、逆にさっきの「3人・半年・仕様変わりまくり」みたいなやつだと、シンプルなMVCとかベタ書きの方が、圧倒的に速い。
それだけの話なんですよ。
結局、設計パターンが「正解」になるかどうかは、現場の状況次第なんですよ。
パターンを知ってることと。
パターンをいつ使うべきか判断できること。
これ、全然別のスキルなんですよね。
現場で評価されるのは、判断できる方
でね、現場でホンマに評価されるのは、判断できる方なんですよ。
「こいつは状況見て判断できるな」
って思われる人が、設計を任される。
単価も、上がる。
逆にパターンを何個も暗記してるだけの人は。
「こいつパターンには詳しいけど、なんでもかんでもクリーンアーキテクチャ言うてくるから、任せづらいな」
って、地味に敬遠される。
技術書10冊読んだ努力、報われてないw
じゃあ、設計力ってなんやねん
ここまで来て「じゃあ、設計力って結局なんなん?」ってなりますよね。
なりますよね。
僕の結論、こうです。
構造を、シンプルにする力。
これだけ。
設計の本質って、複雑なものを複雑なまま作ることちゃうんですよ。
複雑なもんを、シンプルに整理するのが、設計。
たとえば、機能が10個あるシステム、作るとするじゃないですか。
10個全部バラバラに実装したら、後から見た人、迷子確定。
でも。
「この3つは同じデータ扱ってるから、ここにまとめよう」
「この2つは同じ流れの処理やから、共通化しよう」
って整理したら、10個が3つのまとまりになる。
これが、設計。
それぞれの役割を、はっきり分けるってこと。
「責務の分離」って、言ったりします。
で、面白いことに、こうやってシンプルにまとめた結果が、たまたまデザインパターンの形になってたりする。
パターンって、結果なんですよ。
目的じゃない。
判断基準はたった1つ「次に読む人が迷わないか?」
じゃあ、シンプルに整理する時、何を基準にすればいいか。
これも、シンプル。
「次に、これ読む人が迷わないか?」
これだけ。
・このファイルの役割、1個に絞られてる?
・この関数名見て、何する関数か伝わる?
・新しいメンバー入ってきた時、このディレクトリ構成で迷わへん?
こういう「他人が読んで、わかるか?」を判断基準にしてる。
現場で「設計できる人」って、パターンの名前を暗記してる人ちゃうんですよ。
「このコード、次に読む人、迷わへんかな?」って常に考えてる人。
これがね、逆に言うと。
設計パターンを1個も知らんくても、「次に読む人が迷わないコード」が書ける人は、現場で「設計できる人」って評価されるんですよw
パターンの知識は後からいくらでも足せる。
でも、「他人の目線で構造を考える」思考習慣は、意識せんと絶対身につかへんのですよ。
じゃあ、この思考どう鍛えるか
3つ、あります。
①1週間後の自分に、コード読み返させる
これ、一番手軽で、一番効きます。
1週間前に自分が書いたコード、開いてみてください。
「ここ、何やってるんやっけ?」ってなった箇所。
そこが、設計の改善ポイントです。
自分で書いたのに1週間で忘れるんやから、他人が見たら、もっとわからん。
他人が見ても、絶対迷子。
その箇所の関数名を変える。
処理を分割する。
コメントを、1行足す。
小さい改善で、ええんですよ。
これを繰り返すと「次に読む人が迷わへん構造」の感覚が、ジワジワついてくる。
②「なんでこのディレクトリ構成なん?」を説明できるようにする
現場のプロジェクト、なんとなく既存の構成に合わせてファイル置いてませんか?
controllers/、services/、repositories/ って分かれてるけど、なんでそう分かれてる?
この分け方のメリットは?
デメリットは?
これを、自分の言葉で説明してみる。
できひんかったら、それは設計、理解してないってことなんですよ。
で、これができるようになると。
「新しい機能追加する時、どこに置くべきか?」の判断が、自分でできるようになる。
めっちゃデカいですよ、これ。
③パターンは「問題から逆引き」する
デザインパターン、正面から勉強するの、やめましょう。
代わりに、こうします。
「条件分岐が多すぎて読みにくいコードがある。どうすればいい?」
って問題を、先に持つ。
で、その解決策を調べてみたら、たまたまデザインパターンの1個やった。
この順番なんですよ。
パターン何個覚えたかじゃなくて。
「このコード、責務が混ざってて読みにくいなあ。どう分けたらスッキリするやろ?」
って考える癖がつくかどうか。
その結果、調べたらデザインパターンやった、ってだけの話。
覚えた数、関係ないんですよ。
パターン0個知らん人でも、勝てる
まとめると、こういう話です。
設計力を鍛えるのに必要なんは、パターンの暗記じゃない。
「このコード、他人が見てわかるか?」の視点、これ1個。
これを意識するだけで、半年後には設計の議論、堂々と入れるようになります。
ほんまに、これ1個です。
技術書10冊読み終わってから、って考えてる人。
その10冊読む前に、まず自分の書いたコード、1週間後に読み返してみてください。
たぶん、10冊読むより、遥かに設計力伸びますw
ここから先の話
で、ここから先。
「じゃあ現場で、実際どうやって『他人が読める構造』を作るん?」
「大規模なシステムの設計判断って、どうやって身につけるん?」
「面接で『設計はどう考えてますか?』って聞かれた時、どう答えれば通るん?」
こういう話、僕の無料メルマガで書いてます。
今日の話は「設計パターンから入るな・問題から入れ」っていう枠組みだけ。
その先、「じゃあ現場でどう判断するか」「面接でどう伝えるか」は、メルマガで深掘りしてます。
「パターン暗記じゃなく、判断できる側のエンジニアになりたい」
「設計任される側に回って、月単価100万超えたい」
「面接で『設計もできます』って堂々と言える人になりたい」
って人だけ、下から登録しといてください。
ほな、また。
コメント