Uncle BobがCTOなったら開発者にプロフェッショナルとして求めるもの

Clean Codeの著者でありアジャイル開発の第一人者であるRobert Martin (Uncle Bob)がプロフェッショナルなエンジニアとして大切なことは何かを語った動画が面白かったので要点をまとめた。

SCNA 2012: Robert Martin - The Reasonable Expectations of Your CTO on Vimeo

We will not ship shit

エンジニアとして最低な制作物を提供するな。我々を雇う人々は我々のコードを読めないし、何をしているのかもわからず良し悪しを測ることも難しい。彼らに出来ることは締め切りを提示することだ。我々エンジニアだけが何が出来上がるのかを知ることの出来る唯一の存在である。自分たちが作り届けるものにプライドを持て。

We will Always be Ready

開発が完了しdeploy可能になったときには準備万端であるべき。一ヶ月や二ヶ月deployを待ったり、QAが終わることを待つ必要なんて無いだろう。また、安定化の期間なんて必要とするべきではない。そもそも開発されたコードは最初から安定していなければいけないのだ(一週間くらいの猶予は許すけれど)。

Stable Productivity

プロジェクトの開始当初は早く、順調に開発が進むが終わり際は減速するなんてだめだ。プロジェクトが遅延し生産性が落ち、顧客は更なるプログラマの追加を要求するがそれによりコードの質はどんどん低下する。私は常に開発者の生産性が一定であることを期待している。これはおそらく、汚いコードを書くなということである。なぜなら汚いコードは生産性の定価を増長するからである。

Inexpensive Adaptability

顧客が変更を要求した時には余分なコストを払うこと無く容易に適応出来るべきである。”Software”はなぜソフトウェアを呼ばれるのか？ ”Soft”、つまり、変更が容易であることを期待されている。常にコードの変更が容易な状態に保つことは開発者の責任である。「新しい要求は私達の設計では適応出来ません。」なんていうクソみたいな言葉は聞きたくない。

Continuous Improvements

プロフェッショナルなら継続的はコードの質、プロセス、生産性の向上を行うべきである。

Fearless Competence

もしひどいコードを見つけたら自身の変更によりコードが壊れることを恐れること無く改善するべきである。プロフェッショナルならコードの変更に恐れを抱いてはならない。私の場合はテストを利用するが、他者には他者のやり方があるだろう。

Extreme Quality

汚いゴミを市場に出すな。素早い開発サイクルはゴミを作るためではない。可能な限り高い質のコードを維持できる開発スピードで開発は行われるべきである。

We will not dump on QA

QAはバグを見つけるためのものではない。実際のところQAではなにも見つからないべきである。QAはデバッガでもバグを見つけるための奴隷でもない。開発者は最高の質のコードを提供し続けるべきであり、コードが準備万端になるまでQAにdeployするべきではない。

Automation

マニュアルのテストなんてするな。ひどい量のマニュアルテストを抱えていたテスターがテスト予算を半減された時に「行うべきでないテストは何ですか？」と相談しに来たことがある (馬鹿げている)。システムは成長し続け、マニュアルテストの予算も大きくなり続ける。手遅れになる前にテストは自動化するべきである。

Nothing Fragile

「このコードを変更することで複数のバグが生まれるためコードの変更は行ってなならない」などということは聞きたくない。

We cover for each other

我々はチームである。時折プログラマが独立して開発をし誰も他人のコードに触れようとしないことがあるが、あるべき姿ではない。自分の書いたコードを仲間とシェアして欲しいしそれぞれカバー出来るべきである。スポーツでそれぞれのポジションが割り当てられていても状況に応じて柔軟にポジション変更をするのと同じである。プロフェッショナルとしてチームの1人が休暇で居なくなったからといってプロジェクトが止まるなどということはあってはならない。