Robert C. Martin 『Clean Coder』

概要

友達に勧められたので読んでみた。

本書はプロのプログラマとは何かを定義する。今回は、 "プロは、" を主語で統一してサマる。

この本をオモレーオモレーと読んでいたら、親愛なるルームメイトから "人生に一度はそういう自己啓発本にハマりますよね" と言われた。確かに……これって自己啓発本か! 自己啓発本って、それと気付かずハマるものなのだな。コワ。

プロは責任をもつ

• プロは顧客のこと、雇用主のこと、マネージャーのこと、ビジネスのことを考える。
• プロは挙動のわからないものを QA (Quality Assurance) に渡したりしない。だからきっちりテストを作る。
• だけど間違いは避けられない。だからプロは謝罪を心がける。

"それ全部やるなら雇われじゃなくて幹部とかフリーランスじゃない?" って皮肉りたくなってしまった。が、それ全部やれて初めて、著者はプロと呼ぶということなんだろうな。まあ、 "お金もらってればプロ" なのではないという点はぼくも同意だよ。

プロはテストしやすいコードを作る

• プロはテストをする。
• テストには時間がかかるって? だからプロはテストを自動化する。
• どれくらいのコードをテストすればいいのかって? その質問に答える必要があるのか? 全部だ。
• テストしづらいコードもあるって? だからプロはテストしやすい設計をする。
• テストしやすい設計って何かって? プロは柔らかいコードでそれを実現する。
• 柔らかいコードとは、変更しやすいコードのこと。
• 変更はいつするのか? いつもだ。モジュールを目にしたら、構造の改善のような小さな軽めの変更をしよう。著者はこのことを "ボーイスカウトの規則" と呼んでいる。つまり、 "来たときよりもモジュールを美しく" というわけだ。
• 変更をしたら危険だって? それは触ったら壊れると思うからだろう? では触っても決して壊れないとしたらどうだろう? ボタンをクリックして90秒以内にすべてがうまくいったと分かるならどうだろう? それが自動ユニットテストだ。

"ボーイスカウトの規則" っていいね! "柔らかいコード" という表現も気に入った。

プロは自分の時間を使って学習と練習をする

• プロは継続的に学習しなければならない。だって、医学雑誌を購読しない医者にかかったことはあるだろうか? 現在の制度や判例を知らない税理士を雇ったことは? じゃあ、最新技術を知らない開発者を雇用する人がいるだろうか?
• プロは週40時間を雇用主のために使い、さらに20時間を自分のための学習に使う。そんなことはしたくないって? それでも良い。だがそれならプロとは言わないでもらいたい。
• プロは自分の道具と専門知識の手入れに自分の時間を使うものだ。自分のスキルを磨くのは雇用主の仕事ではない。きみの学習時間を見つけるのは雇用主の責任ではない。

"家族にお金を渡して、自分の学習時間を確保したいから給与を上げてくれ" と主張する人を知っている。100回読め。この節を。

プロは自分の限界を知っている

• プロは自分が効果的に働ける残業時間を知っている。時間を20%増やしたからといって、仕事が20%多くできることは確実にないことを知っている。残業すると数日間は使い物にならないこともわかっている。
• 1988年、著者はスウェットエクイティのために長時間働いていた。だが間違っていた。疲れているときにコードを書いてはいけない。あとで捨てるようなコードを無理やり書いても意味がない。

プロは見積もりとコミットメントを区別する

• コミットメントは確実なものである。
• 見積もりは予測であり、楽観値、標準値、悲観値で表される。
• 予測される作業期間は、 (楽観値 + 4 * 標準値 + 悲観値) / 6 で表される。
• 各値は、フライング・フィンガーや親和的見積もりによって算出する。
  • フライング・フィンガー: 全員同時に日数を指で出す。全員が合意できたら次へ進む。
  • 親和的見積もり: 見積もりをしていない作業を、机にランダムに置く。何も話さずカードを並べ替える。時間のかかる作業は右へ、かからない作業は左へ。次にカードとカードの間に線を引く。この線は日数、週数を表したもの。フィボナッチ数列で表現するのが一般的。
• プロがコミットメントをすることは少ないが、ビジネスが勝手に顧客とコミットメントをすることもある。そのときは、コミットメントを果たせるようにビジネスを助けなければならない。ただし、コミットメントを受け入れるわけではない。顧客との約束を果たす方法が見つからなかったら、約束をした本人が責任を果たさなければならない。

3つの値を出すというのは面白いね。

プロは一緒に働く

• プロは手伝いをお願いする。簡単に手伝ってもらえるのに、ひとりで行き詰まっているというのはプロではない。
• プロはお互いに助け合えるようにしておく。そもそもプログラミングはひとりの人間の能力を超えている。
• プロのチームでは、メンバーがモジュールをチェックアウトして、自由に変更できる。プロは他人がコードを触るのを気にしない。
• プロはペアを組む。それが問題解決のもっとも効率的な方法だからだ。
• プロは一緒に働く。ひとりでヘッドフォンをして端っこに座っていては、仕事なんかできない。
• プロはビジネスについて理解する時間を作る。ユーザに話を聞く、営業やマーケに問題点を聞く、マネージャーにチームの短期と長期の目標を聞く。自分の乗った船に注意を払うということだ。
• プロは受動的攻撃をしない。同意したと見せかけて、解決策に従事しない等の妨害行為をすることだ。同意したならば従事しなければならない。
• プロのチームは12人くらいで、ゲル状である。 (gelled には絆が強いという意味がある。)

プロは規律を守る

• 緊急時になれば、自分が何を信じているのかがわかる。
• 緊急時に普段の行動を変えるなら、その行動を信じていないということだ。
• 緊急時を切り抜ける唯一の方法は、うまくいくと分かっているものを信頼することだ。それが規律だ。

……その "規律" というのが、上述した項目である。 これらを正しいと信じいつでも実践するのが著者にとってのプロ意識である。

感想

こういう記事を書いていていつも思うけれども、箇条書きはわかりやすい一方で分量が増えてしまって肉厚の記事になってしまうな。これでも項目をなるべく減らしたのだが。

というわけで、みんなが良い感じになるようガンバり、ユニットテストをちゃんと作り、自分の時間で学習し、残業はなるべくせず、3つの値で見積もりし、コミュニケーションをとるのがプロってことね。……確かにこれを全部実践している奴は、どんだけ性格悪くてもよいビジネス・パートナーになれるような気がするな……。

よい自己啓発本でした。