Clean Coder プロフェッショナルプログラマへの道

RobertC.Martin / 角征典

ソフトウェアのプロとは？ プロの行動とは？ 衝突・厳しいスケジュール・理不尽なマネージャにどう対応すべきか？ いつ・どのようなときに「ノー」と言うべきか？ プロはプレッシャーにどう対応するのか？

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: ドワンゴ
• 掲載誌・レーベル: アスキードワンゴ
• 電子版発売日: 2018年08月01日
• コンテンツ形式: EPUB
• サイズ(目安): 4MB

[ブクログ · ★★★★★]

自分の印象は、エンジニア向けのビジネス書。

人によってはストイック／スパルタ的に思う箇所はあると思いますが、わたしは書いてある内容の方に共感する世代かなと思います。

[ブクログ · ★★★★☆]

全然良い本なんだけど、初心者には序盤が共感出来ず、中堅はClean Agileの方を読めば良いかなという感じ

[ブクログ · ★★★★☆]

ボブおじさんの長年のエンジニアとしての経験から、「プロのプログラマーであれば、こう振る舞うべし」と教えてくれる本。
子供が生まれて自分の働き方が大きく変わって早数年。いい意味で自分の働き方を見つめ直す良い機会になりました。

[ブクログ · ★★★★☆]

最初は読みにくいなぁと思っていた。
ただ、「２章の「ノー」と言う」につい食いつきました。

プロフェッショナルというのはどういうことか？という話なのですが、自分も含め、どれだけプロではないことをしていたのかと反省しました。
責任を持って、出来ないことを言うことが大事であること、コミュニケーションをとって、相手が何を望んでいるかを把握すること。その望みをかなえる為に、別の提案で出来ないかを考えること。

その他、プロが見積もりを立てる時、予定完了時間と分散を使った確立的な見積もりを提出することが多い。不確実性があるから、当たり前のことですね。

今まで、やってみますと言って、残業して必死に対応したものの、あまり役に立たなかった、使われなかったことが多々あるなぁ。もう、そんなのは止めよう。

[ブクログ · ★★★☆☆]

【プロ意識】
■責任を取る
■第一に危害を加えてはいけない
・機能に危害を加えてはいけない
　QAは何も見つけてはいけない
　動作することを「把握しなければ」いけない
　自動QA
・構造に危害を加えてはいけない
　本物のプロは、構造を犠牲にして機能を届けるのはバカのやることだと思っている。コードの柔軟性はその構造にかかっている。構造が不安定ならば未来も不安定になる。
　あらゆるソフトウェアプロジェクトの基本的な前提として、ソフトウェアは変更しやすいというものがある。構造に柔軟性がなくなり、この前提が崩れてしまえば、業界全体の経済モデルが根底から覆されてしまう。
　つまり、ソフトウェアは適切なコストで変更できなければいけない。
…
　すべてはテストに通じる。コードのほぼ100％を網羅する自動テストスイートがあり、思いついたらすぐに実行できるのであれば、コードを変更するのは怖くない。どうすればコードの変更が怖くないと証明できるのだろうか？それは、常に変更すればいいのである。
■労働倫理
・自分の専門分野を知る
※すべてのソフトウェアのプロが備えるべき最低限のこと
▶デザインパターン：GOFの24のパターンについて説明できる。POSAのパターンを実際に使える知識がある。
▶設計原則：SOLID原則を知っている。コンポーネントの原則を熟知している。
▶方法論：XP・スクラム・リーン・カンパン・ウォーターフォール・構造化分析・構造化設計を理解している。
▶規律：TDD・オブジェクト指向設計・構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している。
▶成果物：UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・ディシジョンテーブルの使い方を知っている。
・継続的学習
・練習
・協力
・指導
■ドメインを知る
■雇用主や顧客に対して親身になる
■謙虚


■TDDの3原則
1. 失敗するユニットテストを書くまでプロダクションコードを書いてはいけない。
2．テストを失敗させる目的以外でユニットテストを書いてはいけない。なお、コンパイルできないのも失敗に含まれる。
3．失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはいけない。

■TDDの利点
・確実性
・欠陥混入率
・勇気
・ドキュメント
・設計
　TDDの3原則に従ってテストを書こうとするとジレンマに陥る。下がり甘きたコードのことはすでに頭にある。だが、まだコードがないので、先にユニットテストを失敗させろと3原則に書いてある!これはつまり、これから書くコードを先にテストしろということだ。
　コードをテストする上で問題となるのは、コードを分離しなければいけない点だ。例えば、他の関数を呼び出している関数をテストするのは難しい。テストを書くには、その関数を他から切り離す方法を探さなければいけない。言い換えれば、テストファーストをするには、優れた設計について考えなければいけないということだ。
　テストを先に書かなければ、複数の関数をテストのできない大きな塊に詰め込んでしまうことになる。あとからテストを書くとなると、大きな塊全体の入出力のテストならできるだろうが、個別の関数をテストするのは難しい。
　つまり、3原則に従ってテストを先に書けば、うまく疎結合した設計ができるようになる。優れた設計に導いてくれるツールを採用しないプロがいるだろうか?
「テストなんかあとで書けるよ」と言うかもしれない。だが、それは違う。あとで書くことはできないのだ。本当に。あとで書けるテストも少しはあるだろう。注意深く計測していけば、あとでカバレッジ率を高めることもできるだろう。だが、あとで書いたテストは防御なのだ。先に書くテストは攻撃である。あとで書くテストは、コードを書いた人や問題の解決方法を知っている人が書くものだ。こうしたテストは、先に書くテストほど鋭いものではない。


■早すぎる詳細化
　ビジネスもプログラマも「早すぎる詳細化」の罠に陥りがちだ。ビジネスは、プロジェクトを承認する前に、これから手に入れるものを正確に知りたいと思う。開発者は、プロジェクト見積もる前に、これから開発するものを正確に知りたいと思う。どちらもできるはずのないことを詳細化しようとして、コストを無駄にしているのだ。
・不確定性原理
　問題は、紙に書かれたものと実際に動くシステムが違うことだ。仕様どおりに実装されたシステムを見ると、ビジネスは自分の欲しかったものじゃないと言う。要求が実際に動いているのを見ると、もっとよいアイデアが浮かんでくる。そして、それは目の前にあるものじゃない。これには、観察者効果(あるいは不確定性原理)が影響している。動いている機能をビジネスに見せると、新しい情報を与えたことになる。そして、その新しい情報は、システムの見方に影響を与える。つまり、要求を詳細化していくと、開発中のシステムとかけ離れていくのだ。
・見積もりの不安
見積もりの不安
　開発者も詳細化の罠に陥ることがある。システムをもっと正確に見積もらなければいけないと思っているのだ。だが、正確に見積もることなどできない。
　まず、完全な情報を持っていても、見積もりにはバラツキがでる。次に、不確定性原理によっさて、早すぎる詳細化は無効にされている。要求は変化するので、詳細化は現実的ではないのだ。
　プロの開発者は、精度の低い要求からでも見積もりは可能であり、見積もるべきであることを理解している。また、見積もりは見積もりであることもわかっている。見積もりには必ずエラーバー(誤差範囲)を設けて、ビジネスにその不確実性を理解してもらっている。

[ブクログ · ★★★☆☆]

第一章から三章までが凄く大事な事が書いてあると思った。
プロのエンジニアとして、どのように責任を持つのか、仲間とどうコミユニケーションを取っていくべきなのか、について著者の経験談を元に詳しく書かれていた。

エンジニアのインターン1年目の自分としては、働く中で核となる考え方を得ることができ良かった！

(四章目以降は、知っている事が多いようにも思えた)