■ - @kyanny's blog

「良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)」を読んだ。4/21に買った本のなかで一番最初に読み終わった（一番薄かった）

全体的に、浅く広くという印象を受けた。知っている、意識していると感じる内容が多かった。おれは中級プログラマくらいの立ち位置かなーと思いつつ読んだ。

良いコードが書けるようになるためには自分の手を動かしてコードを書く実践が必要
部分的なプログラムしか書けないのでは開発者としてまずい、一人である程度のプログラムを作りきれてからがスタート
Acronym Finder というサイトは知らなかった。短縮語検索サイト
名前に迷ったときは Google Code Search で検索してオープンソースソフトウェアで使われているかどうか調べる
クラス名がうまく思いつかないときは、クラスの役割をちゃんと理解しきれてないサイン
自分が知らない表現・概念は、自分の中から簡単には生まれない
- だからこそ他人の書いた良質なコードを読んだり良書を読んだりして、学び続ける必要と意義があるわけだ
自分が知らないまったく新しい概念の名前が突然ひらめくことはめったにない。名前の引き出しを少しずつ増やしていくことでネーミングセンスが鍛えられ、良い名前づけができるようになる
スコープ = 見える範囲 = 使える範囲 = 依存する範囲 = 保守性に影響を与える範囲
- 使えるということは依存するということ
メソッドの引数は必要最小限のもの、依存性の低いコード
コード分割の戦略、トップダウンとボトムアップ
- テスト駆動開発がトップダウンに分類されてるのは違和感がある。ユニットテストが書ける最小単位のコードから実装していくのだからボトムアップでは？
トップダウンは難しい
コードを何手か先まで読めないと「何を書いていいかわからない」
外部に対して副作用があるメソッド
コードの重複をまとめるサービス層
あるクラスのオブジェクトに強い関心をもつコードオブジェクト自体に持たせる
計算量
- 例だとかなりざっくりした感じで説明している。かたやアルゴリズムの本とかだと O(n) とか数学っぽい表記でやたら難しそうに説明されていて、いまだに計算量って概念的なものなのか明確な単位があるようなものなのかわからない
ユニットテストのフレームワークの例として Perl の Test::Simple が紹介されていたが、さすがに Test::More を書いておくべきではないかと思った。標準モジュールなのだし
抽象化をしたあとで、その抽象化がどれくらい開発に貢献したかを振り返ると良い。繰り返すことでセンスが磨かれる
メタプログラミング統合開発環境の GUI 操作によるコード自動生成もメタプログラミング
リフレクション API でクラス名の文字列から動的に Class 型のオブジェクトを取得し...
- リフレクションってそういうことだったのか。 Perl や Ruby では日常的にやっていることだ（メソッドを変数の値から取得して動的にディスパッチするとか）