「レガシーコードからの脱却」を読んで
読み終わりましたので簡単に感想を書きたいと思います。
読みやすい！
正直、私のような初学者は翻訳された本というだけでもとっつきにくい上、オライリー本は更に難しく思えてしまうのですが、
そんな私でも、途中で挫折することなくスラスラと読めたくらい、この本は「読みやすい」です。
レガシーコードをリファクタリングする手法が書かれてあるのか？は、ほぼNO！
リファクタリングについては触れられていますが、基本は「最初からCLEANなコードを書こうね！」という本です。
恐らく、常に情報を収集し、保守性や可読性を意識しているような人には物足りない内容なのではないかなと思います。
- オレオレルールが蔓延しておりコーティング規約が統一化されていない
- リリース直前になってバグが多発し炎上してしまう
- １つのメソッドに様々な振る舞いを詰め込んでいる
- テストカバレッジを意識していない
- カプセル化がよくわからない、面倒くさいから全部publicで書いちゃう
- ペアプログラミングのメリットって何？
- テスト駆動開発って何？
- ウォーターフォール開発ばっかりやってる
ような人は読んだほうが良いかもしれません。ちなみに私の現在のプロジェクトは上記フルコンボの役満です。ありがとうございます。
好きな言葉
あまり具体的に内容に触れるとアレなので、この本の中で私が好きな部分を抜粋していくつかご紹介します。
私たちの誰もがレガシーコードというグローバルな問題を生み出すのに一役買っている。ゆえに、私達はその問題を解決する責任がある。 p34
ルールを破り、新境地に達するためには、まずルールをマスターしなければいけないのだ。 p51
1年の開発サイクルで開発者が自分自身に大きなウソをつくのではなく、２周間のイテレーションの中で小さなウソをつくのである。 p81
私が「完了」と言うときの本当の意味は、「完了の完了の完了」のことだ。 p107
「常に誰かのメンターであれ。常に誰かのメンティーであれ」 p135
明日のベロシティのために今日品質を上げる p155
テストは特定のパラメータを用いてコードを実行する。つまりテストは具体的な要件である。 p182
今日のTODOリストを作るとき、なにをやるかは書くが、どうやってやるかを書くことはない。 p211
この業界では、レガシーコードを時限爆弾ではなく、地雷と見なす必要がある。 p226
私たちの時間と努力の半分以上は取り戻せるのだ p247
気になった方は是非読んでみて下さい。
