エンジニアリングリーダーが選ぶ「必読書」：複雑さを嫌い、シンプルさを愛する
Carl's Required Reading
エンジニアリングリーダーのCarl Kolon氏が、自身のチームに送る「必読書」リストを公開。複雑さを避けることの重要性、ORMの危険性、フロントエンドのシンプルさなど、彼の意見が色濃く反映された記事や書籍を厳選。各項目には彼自身の解説付きで、プログラマーなら共感できる内容が満載。
複雑さは悪だ。
HNでの議論
30- pragmatic
まともなリストだが、ORMの件には疑念を抱く。
彼はここを、ORMがデフォルトで悪いという決定的な証拠としてリンクしている。
https://openai.com/index/scaling-postgresql/
「道具を責めるのは下手な職人だ。」
私のORMの経験則：
ORMはCRUDには使うが、レポートには使わない。
運用データで12テーブルを結合しているなら、それは設計上の欠陥だ。それはレポート用クエリのパターンだ。
多くの場合、一時テーブルやCTEなどが即効性のある修正として必要で、再設計が長期的な修正となる。クエリプランナーはそれを合理的な時間内に最適化できないか、最適化できる範囲を超えている。また、彼らの「メモリ内結合」という解決策も一般的だ。
私のDBクエリの経験則：
クエリがあなたにとって理解しにくいなら、プランナーにとっても理解しにくい。
デフォルトでは、小さく速くシンプルなクエリをパイプラインでつなぐこと。
- cweagans
投稿者は『エッセンシャル思考』も気に入るかもしれない。YAGNIと非常に合致していて、API設計以外のことも導いてくれる！
- drunkboxer
私も共有したい似たようなリストを持っている。カールのリストからいくつか載っていたが、おそらくそこからいくつか追加するだろう。
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... https://www.parsonsmatt.org/2017/10/11/type_safety_back_and_...
https://lwn.net/Articles/336262/
https://tomasp.net/blog/2015/library-frameworks/
https://ratfactor.com/cards/not-quite-the-same
https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...
- olives
マイクロサービス
グルグは、なぜ大きな頭脳が最も難しい問題であるシステムの適切な分割を引き受け、さらにネットワーク呼び出しを導入するのか不思議に思う
グルグには非常に混乱しているように思える
^ これは今年読んだ中で最も素晴らしく、最も面白い段落だ
- kristianp
オブジェクト関係インピーダンスミスマッチ[1]について聞けて嬉しい。その概念を聞くのは久しぶりだ。おそらく10年ぶりくらいだろう！ Dapper[2]が好きな理由は、自分のSQLを使わざるを得ないからだ。
編集：「lets」を「makes」に変更。
[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...