RobertC.Martinのレビュー一覧

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

RobertC.Martin / 角征典

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

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

RobertC.Martin / 角征典

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

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

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

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

Clean Agile 基本に立ち戻れ

RobertC.Martin / 角征典 / 角谷信太郎

アジャイルのポエム。
本じゃなくても、Qiitaとかで読めれば良さそうな内容。
XPのプラクティスが重要。
デイリースクラムは、必須じゃないとか。
ペアプログラミングも常時やらなくても良いとか。
クラフトマンシップ、職人宣言とか。
Scrumで最初はガチガチの型に嵌めてやれとは少し趣が違った見解。

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

RobertC.Martin / 角征典

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


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

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


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

Clean Craftsmanship 規律、基準、倫理

RobertC.Martin / 角征典

中盤までのテストダブルの話や具体的なTDDの事例は記述が明確で分かりやすいが、博物館的が雰囲気もあり、ブランチは使わないのが好ましい、ミーティングの招待は辞退しよう、など固執すると危険そうな価値観も多く記述されている。

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

RobertC.Martin / 角征典

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

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

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

Clean Agile 基本に立ち戻れ

RobertC.Martin / 角征典 / 角谷信太郎

アジャイルに対してどういう思いで議論され、生み出されたのかを感じるできる本です
スクラムなどの実践的な手法の説明ではないので、そういう事を求めてる人には合わないと思います
一方で全体としてアジャイルとは何かを考えたい人には合う本ではないですしょうか