良い設計の標準化やプログラミング能力の底上げに対する気持ちを残しておく
これ進研ゼミでみたことあるやつだ！みたいなのがよくあって意思決定のトレードオフを提唱するのに役にはたった この積み重ねによって得られたもの
技術投資の損益分岐点みたいなラインが肌感でわかるようになってきた 大体の設計手法やパターンも意味や具体的なコード例が頭の中で浮かんでくる
良いプログラムの理解が進んだ
いま持っている気持ちが冷めない内に書き残しておこうと思う
---
良いプログラムの現時点での結論
やはり関数設計が全てだなと思う
すべてのコードは書いた瞬間負債になりうるというメンタルモデルが大事で、関数単位で捨てやすさを念頭に考える 全ては大なり小なりの判断の積み重ねによって行われている
それが良い判断かは後からじゃないとわからないし、ドッグフーディングし続けることでしかわからない
処理のまとまりの捉え方も人によって変わるし、結局属人化は避けられないだろうなーと思う。
Reactだったり普段お世話になってるOSSのコードリーディングをしてみても、コードにブレはある でも根っこの部分で関心が分離されているのでお互いに影響はないように作られてたりする
チームの生産性や保守性をあげたい、という目的や属人化の排除で実装を標準化(共通化)したいといった試みをよく見るが(自分も過去に何度か依頼された経験がある)が、その判断のトレードオフをよく理解していないと実運用に乗せるのは難しいんじゃないかなと思う 文化が違うと使う言葉も異なるので会話が噛み合わない ここでの副作用ってなに、冪等性ってなにみたいな定義から議論する時間などない 原則を理解していないジュニアも腹落ちしないままメンタルモデルとコードが乖離していく 仕組み化する前にはまず、仕組み化できるものか、していいものかの分析も大事で、そのアプローチの仕方を間違えると効果が薄い
何なら、デメリットの方が高くつくこともある
構造化スキルは数年の経験の上に成り立つ高度な技術であり、属技能性が高い
ゴールが曖昧なまま突き進んでも本質的ではない
プログラムが生まれるまでそれなりの試行錯誤があったはずで、それは成果物には現れない
要件定義や仕様理解を通して開発者なりのメンタルモデルをベースを作って、トライアンドエラーを繰り返しながら理想系に向けて育つものだと思う コードに内在する性質だけに着目すると、外部環境に対する適応度の考慮が不足してしまう
構造や仕組みで解決などは固有のルールを閉じ込めているだけで根本解決ではない
その裏のルールを知る必要はあるし、一般的に学習ハードルはもっと高くなり、むしろ生産性が高いとは逆方向に向かう 例えば、通知はドメインサービスなのか、アプリケーションサービスなのかは視点次第 視点に”正しい”の定義もないし、逆説的に”間違い”もない
ドメインかアプリケーションか分類することが無駄というわけではない
手段に囚われすぎて設計に必要なメンタルモデルを育てるという超大事な過程を忘れると本末転倒となるということ 一般的にいい設計、いいプログラミングをするためにはより抽象度の高い前工程に入っていって、問題定義の段階で整理整頓しておく必要がある