Python3.10と3.11の狭間で殺された日

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

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

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

ログ8

室井さんの映画(後編)を見た日 よかった、が、あれよかったのか最後… もったいないというかなんというか…

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

ルール10　複雑な処理はまとめる 当然と言う他ない…オブジェクト指向で解決したい問題だろうし… 見つからない条件が積み重なっていくステルスゲームの実装、の例が分かりやすい。 てか、CPU命令の三角関数ってバグってるんですか…

いつだって誰かが

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

いろんなプログラミング教則本の、 「わかりやすい命名をしろ」の教えを整理して比較してみたくなった日

ログ7