達人プログラマー 第2版 読書メモ
自分の感想なども織り交ぜています。
Easier To Change
ETC、変更が容易であること。良い設計は変更がしやすい。確かに。
責務が単一であったり、結合が最小であったり。後ろに触る人が触りやすいコード=変更が容易であるコード。
「他人が引き継ぎやすくて、意図が伝わりやすいコード」が自分の中でしっくりきました。
DRY原則はコードだけではない
一度作ったものを最実装したり、同じ目的のものを別々のエンジニアが違う実装をしてしまったりなど、あくまでもコードだけに寄った話ではないことがわかりました。
直行性
ある実装が別の実装に影響を及ぼさないことだと判断しました。
向きの違う別のベクトルだということ。新しいものや関数を実装する際の影響範囲を今一度考えよう。
見積もりに関する計算問題
データを物理的に持ち運びした時と、転送した時とでどっちが早いか?という問題。
まず前提を揃えられる
USBからPCへの転送時間は?
移動の速さは?
外部ストレージのビット数は?2^10がどれくらいあって...
転送速度は? などなど
その上で計算を行う。規模が大きくなればなるほどフェルミ推定のようになる感じがする。
まずは見積もる前に、具体的な前提、抽象的な前提を考えるのが良さそう。
バージョン管理の大切さの具体例
PCを壊したときに
ドットファイルやエディター、ローカルに直接インストールしていたデータをすぐ復活させられるか?という話
コードの修正の前にテストを失敗させること
ある機能を直す際なんて特に、テスト駆動で作った方が多分良さそう。
テストケースを洗い出せてないと、直せた気になっても結局解決できていなかったり、他の考慮漏れが発生する。
修正時こそ足りていないテストがないか?とか、そもそもテストが書いてあるか?という視点を持とう。
例外処理はメソッドの中でやる
本体のコードがエラーハンドリングで埋まる。コードの結合度が下がる。
後者に関しては、例外処理が染み出したmainの処理(もしくはその他の処理)の責務があやふやになる。
本当にそうか?これを示すには「表明」しておく
極端な話、1ヶ月が15日になる可能性だってある。それを考慮する必要は少ないかもしれないが、懸念事項に対して「そうはなりません、ならないようにしてあります」という実装をしておくのが良い。型定義とかもそのうちの一つだなと思った。
P159