そこで見たもの

ログ6

向こうは思いのほか遠い

秋などない

ログ5

ルール7　失敗させない構造を作る 大事なんだけど難しいなぁ…場当たり的な対応をしがち 包括的な対応策があればいいんだけど言語仕様にだいぶ左右される この辺はルールデザインと繋がりそう 　社会規範作るよりはきっと楽

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

ルール4は一般化、ユースケースが出てから処理を統合すべきで、最初から一般化すると痛い目を見る。 ルール5は最適化、初期実装から最適化しても、コードが複雑になるだけで効果は不明。ある程度組み上がってからボトルネックを解消するのが良い。 結局のところ、「早まるな」ってことらしい。

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

サンプル7

あの場所

ログ4