2025-09-22

• [x] 10分読書
• [x] 技術記事を読む

10分読書

引き続き レガシーコード改善ガイド
P.80「実装の抽出」からP.371に飛ぶ

ネーミングは設計の中心である。優れたネーミングはシステムの理解を助け、作業を容易にする。しかし、貧弱なネーミングはシステムの理解を妨げ、後でシステムを扱うプログラマにつらい日々を送らせる

以前ちょっと悩んだのがreaded_atという既読フラグ。readの過去形はreadだけど日本人がパッと見てわかりやすいのはreadedな気がして指摘するかどうか迷った。あのとき結局どうしたんだっけかな。既読フラグが必要な案件って多分${NDA}だと思うけど

抽出したいメソッド群を調べ、それらがそのクラスにおいて、まとまった意味を持つpublicメソッド群になっていないかを考えてみる。もしそうであれば、それは新しいインターフェースに対する別の名前を示唆している可能性がある。

英語力が貧弱だと難しいのよねメソッド命名。

<愚痴>
メソッドもコミットも一言で説明できるのが大事と思うけど「バグ修正」の一言でクソデカコミットを投げつけられることもよくある。「一言」とはそういう意味ではないが、実際のところ具体的な粒度の物差しも存在しない気がする。
結局この辺りはルールを作っても守られない（守っていられない）ケース（炎上案件の納期間際とか）が多々あるわけでポストモーテム的に棚卸をするとかでやっていくのが良かろうと思う。たいていその機会は無いが

話は個人的な恨みつらみに逸れるが何か月か前に担当チケットで関わったメソッドが単一責任になっていなくて複数のAPIを順繰りに呼んでレスポンスを整形して返すやつで例外処理もされていないnull考慮もされていない正常ケースでしか動かないようなコードでゴミがよと思って2個だか3個だかのクラスに分けてnullチェックしてっていう感じでリファクタリングしたら数週間後にまた散らかされてて心が折れたりした。キライ。あの人（ソースを散らかした特定個人）キライ。
っていうかたぶんあれコピペ改変で書かれてるせいだと思うけどどれもこれもnullチェックしてないんだよなrubyだからnullじゃなくてnilだけど res = apiコール().data.hoge[0] みたいなことをあちこちでやっててapiコールが失敗したら500データが無かったら500で本当にひどいものだった。ほとんど常に炎上してたしレビューもまともに機能してなかった（忙しすぎたんだろうたぶん）しテストも無かったのでさもありなんという感じではあったが

あのプロジェクトとあのプロダクトをどうやって救えたかと考えるとあんまりやる気が出ない。忙しいからテストもしないしレビューもおざなりっつったらこっちでできることなんか無いです。バァカ。そしてその「ソースを散らかした特定個人」に「そんな丁寧にテストしなくて大丈夫ですよ」って言われた日にはうるせえよあんたのコードでエラー出てるんだよあんたはもうちょっとテストしろアホの気持ちになったりした。
</愚痴>

システムは壊れる前提で作る、ルールは破られる前提で作るが基本かなと思いました（感想）

技術記事を読む

毎日の判断は CLAUDE.md、深掘り学習は docs/rules/ ― カオスなドキュメントを最小構成で回してみた

カオスになるほどドキュメントが書かれる現場いいなー……