ルール19 一気に更新するな これは脳に収まる〜にもあった　更新前後のコードを同居させて、少しずつ入れ替える 更新後のコードに欠陥があっても発見しやすいし、確実に改善できる 急激な変更による劇的な改善を望みがちだが、大きな変化は体に悪い… あとひたすらメモリの話ししてる

ルール21 目の前の雑事から逃げない ちょっとめんどくさくて、やりたくないなと思うことから逃げるな 逃げ続けても積み上がるだけで解決されないから あー耳が痛い そして読了 終始喋り口調な文体ですが、慣れれば普通 ゲーム開発者だからなぁ、とは思うものの 今後の参考にはできそう

ルール14 簡単な問題を複雑に解くな、難しい問題は複雑に解いてもいいけど、単純に解ければ偉大だ。 偉大になりたい。 ルール15 小さい問題を放置するな。その修正で影響が出ないようなら積極的に直せ（ただしアスパラを間違って抜くな）

ルールズオブの3つ目：適切な名前をつけろ 何度目だろ…この手の本だと絶対出てくる 名前から機能が分かりやすく、命名規則が一貫していれば認知負荷が下がる 著者はガチガチの命名規則を定めたし、ほとんどのコードを自社開発して命名規則がブレないようにした、らしい

ルール20 計算して行動しろ とりあえず、なんとなく、で行動するんじゃなくて、 どれぐらい改善が見込めるかを考えてからにしろ、という話。 改善でなくなる時間と、改善にかかる時間が五分五分ならやめとけ ※ただし色んな人が使うなら別 動かせない制約から考えるのも良い　なるほど

ルール8：要らないコードは残すな 動かさなくなったコードを後生大事に残しても、不具合の種にしかならないのでさっさと消せという話だった。 当たり前ではあるけど、この事象においてメソッド単位の自動テストは役に立たない　っていうのは面白い

ルール11 抜本的な解決をするのは、それによって2倍以上良くなるときだけ。 土台からの解決をしたい理由が、単に新しい技術を取り入れたいだったらやめとけ。 一方で、絶対に改善するのに小手先だけの対応だけなのも悪い。 結局はバランスの問題かなぁ

ルール17　複雑な問題のほうが解決しやすいこともある 何がいいたいか結局よく分からなかった。 複雑な問題はむしろ世界ですでに解決されている事が多くて、再利用できればすぐ解決できる、的なことなのかなぁ… この章も例が具体的すぎて何が何だか…

えーと、ルール16か、「JSON形式の設定ファイルを読み込む」を実装する長い例が大部分 主題としては、「方法じゃなくて問題から考える」みたいなこと。 簡単に実現できる解決策よりは、問題に合った解決策を選んだ方が良い。 にしても例が長い…読み飛ばしたけど

ルール13 問題は原因を修正し、原因は状態から遠ざける マンネリだなぁ 純粋関数が良い、ステートレスが良い　もよく出てくる主張 具体例も載ってるし、状態を保たざるを得ない場面の話も載ってるし、丁寧ではあるんだけど面白みはない

【プログラマー向けチクチク言葉】 オライリー読みのオライリー知らず…

ルール6　コードレビュー 1. バグをなくすため 2. 知識を共有するため 3. 見られていいコードを書くようになるため これを対面で実施しているらしい。効果はありそうだけど面倒だな… 雇用契約の上で、レビュー依頼はいつでも受け付けることが明記されてるのはすごい

ルール12　チーム内共通のルールを作り、徹底して遵守する コーディング規約を定める当たり前の理由だと思う。バラバラのルールで動くメンバーに実装させてたまるか。 つくづく、システム開発の組織構造はほぼ政治体制に思える。 紀元前からやってることをなに新しいことのように言ってるんだ。

ルールズオブの2つ目読んだ テスト駆動開発にやや否定的なスタンスだったので、脳に収まる〜と相反するかと焦った この本の著者がゲームプログラマであることがこの違いの原因っぽい コーディングテクニック本を100冊読んだ〜的なことできそう でもビジネス書より競合はしないかも