ロバート・C・マーチン(ポブおじさん）の[CleanCoder]を読んだ感想を書きます。
ああ・・・あのときこうすりゃよかったよ、みたいな
先入観では、プログラマとはなにかを悟った筆者が"プログラマとはこうあるべきである"という結論をズバズバといっていくものと思っていた（帰納的）。
実際は、ポブおじさんの失敗談がこれでもかと紹介されて、“プロならばこう振る舞う"という感じで語られていく。
個人的体験を元に，“こうだ"と語られる(演繹的)。
全体を通して、断片的なエッセイが書くテーマに対してまとめられたようになっている。
プログラミングの本だけれども、コードはほとんど登場しない。コードを作るときの思想が語られている。
そんな断片的で、個人的にこころに残ったフレーズを引用しながら感想を書きます。
個人的に印象に残ったこと
テストの必要性について
自動テストユニットって、どのくらいのコードを書けばいいの？その質問に答える必要があるのか？全部だ！ぜ・ん・ぶ。
(第1章 プロ意識)
この言い切りが、潔かった！ぜ・ん・ぶだ！
TDDは規律で、どんなに追い詰められているときでも規律を厳守することで、自分のペースを保つのだと説明されてる。なるほど・・・。
ソフトウェアのプロが抑えるべき最低限のこと
プログラマがおされるべき最低限のこととして、以下の視点を上げている。
- デザインパターン （Gof、POSA、など）
- 設計原則 （SOLIDの原則、コンポーネントの原則など）
- 方法論 （XP、アジャイル、ウォーターフォール、など）
- 規律 （TDD、オブジェクト思考、構造化設計、CI、ペアプロ、など）
- 成果物 （UML、DFD、状態遷移表、フローチャート、構造チャート、、ディシジョン・テーブルなど）
（第1章 プロ意識）
自分の場合は、知っているものもあれば、まだまだ知らないこともある。
プログラマの必須科目として、学び続けていきたい。
具体的には、今年はデザインパターンを勉強したい!
第２章「ノー」という
できないことに「ノー」ということについて、凄まじい体験談を引用しながら説明されている。
Is Good Code Impossible? | Rapture In Venice: iOS, Android Mobile Development Shop
こんな状況になっても、誰に責任があるのかといえば、“ノー"と言わなかった人に責任がある。プロのプログラマは、できないことには"ノー"という。
逆に"イエス"といったことは絶対にやり通す。そのため、安易な見積もりを元に"イエス"とは言ってはいけない。イエスの責任感が説かれている。
見積もりについて
見積もりに関するこんな視点も新鮮だった。
見積もりは数値ではない。見積もりは確率分布だ。
（第10章 見積もり)
工数は、楽観値、標準値、悲観値の３つの視点で考えることが大事だ。
自分の場合も、終わりますというのは標準値（楽観値？）を考えていたが、コレは３つの視点で考えることが必要だと思った。
練習について
日々の練習を通して、“型”を身につけることの重要性を解いている。
必要になった時に完全な動きが自動的にできるようになることが、最終的な目標である。
プログラミングの型というのは、プログラミングの問題を解くためのキーボードやマウスの動きの練習である。
解き方はすでにわかっている問題を解きながら身体の意思決定の練習をするのだ。
（第6章 練習)
型を身につける、キーバインドやホットキーの使い方に習熟するようにする。
いつも忘れないようにしたい。
個人的には、今年はTopCoderを頑張ろうと思っている。
TopCoder, Inc.TopCoder, Inc. | Home of the world’s largest development community
これは、アルゴリズムの勉強が第一の目的だ。
別の目的としては解けなかった同じ問題を繰り返して練習することで、その問題で使われているアルゴリズムを息をすうようにコーディングできるようにすることがある。
まとめ
断片的に、様々な発見がある。また時間を置いて読めば、別の発見が得られそうだ。