KENT BECK 2016年6月7日
オリジナル：https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414
達人プログラマを数年間見つづけて、彼らのワークフローにある共通するパターンを観察することができた。熟練の職人プログラマを数年間コーチし続けて、そのようなパターンが欠けていることを観察することができた。これらのパターンを導入することで何が起こるかを見てきた。(訳注：「達人→master」、「職人→journeyman」)
効率的なプログラマが貴重な時間を最大限に活用する方法がある。ここでのテーマは、頭脳をスケールすることである。職人は、一度にたくさんの問題を解決することで、より大きな問題を解決することを学ぶ。達人は、一度に少ない問題を解決することで、より大きな問題を解決することを学ぶ。小さな問題をまとめて解決するのではなく、問題を分割し、個々の解決方法を統合することに知恵がある。
-
スライスする。 大きなプロジェクトでは、それを薄いスライスに切り分け、自分のコンテキストに合うようにスライスを並べ直す。プロジェクトのスライスはいつだってうまくいくし、ニーズの変化に合わせてスライスを並べ直すこともできる。
-
一度に１つ。 効率を気にしすぎると、オーバーヘッドを減らすことに気を取られて、フィードバックサイクルを減らしてしまう。そうなると、デバッグ不可能な状況に陥って、結局はサイクルのオーバーヘッドが大きくなってしまう。
-
実行し、正しくし、速くする。 (「一度に一つ」、「スライス」、「容易な変更」の例) (訳注：順番が重要ということ。まず動くようにして、次に正しく動くようにして、最後に速く動くようにする。)
-
容易な変更。 厄介な変更に直面したとき、まずは問題を容易にし(警告：それは困難かもしれない)、それから容易な変更を行う。(たとえば、「スライス」、「一度に１つ」、「集中」、「隔離」といったことを行う。) これは「スライス」の例である。
-
集中。 いくつかの要素を変更しなければならないなら、まずコードを並べ直して、変更が１つの要素で済むようにする。
-
隔離。 ある要素の一部だけを変更する必要があるなら、その部分を切り出して、切り出した部分をまるごと変更する。
-
ベースラインの計測。 プロジェクトをはじめるときに、現状を計測してベースラインとする。我々のようなエンジニアは、本能的にいきなり直すことからはじめてしまう。しかし、ベースラインを計測しておくと、本当に直しているかどうかを実際に知ることができる。
-
コールショット。 コードを実行する前に、大声を上げて何が起こるかを正確に予測しておく。
-
具体的な仮説。 プログラムが間違った動きをするときは、変更する前に、何が間違っていると思うかを明確に述べておく。２つ以上の仮説があるときは、鑑別診断を行う。(訳注：鑑別診断とは「病気を診断するにあたり、その症状や検査の結果から可能性がある複数の病気を比較しながら、合理的に特定する診断のこと」。)
-
外来の詳細を取り除く。 バグを報告するときは、もっとも短い再現手順を見つける。バグを隔離するときは、もっとも短いテストケースを見つける。新しいAPIを使うときは、もっとも基本的な例からはじめる。「それに関しては重要ではありません」は、仮定が間違っていると高くつく。
- たとえば、モバイルでバグが見つかったら、それをcurlにまで縮小する。(訳注：curlというのは恐らくはツールのこと。 https://curl.haxx.se/)
-
複数のスケール。 異なるスケールを自由に行き来する。これは設計の問題であり、テスト時の問題ではない。これは人間の問題であり、技術の問題ではない [これは常に真なのでズルい]。
-
シンメトリー。 ほとんど同じものは、同じ部分とはっきり異なる部分に分けられる。
-
美学。 美を獲得するのは大変だが、無視するのは容易だ(たとえば、たくさんの機能を１つに詰め込めば混乱する)。
-
リズム。 時機を得るまで待ち、エネルギーを節約し、混乱を避ける。行動すべきときが来たら、一気呵成に行動する。
-
トレードオフ。 すべての決定は、トレードオフの問題である。より重要なのは、何をもとに決定すればいいかを知ることであり、今日取り上げる答え(あるいは昨日取り上げた答え)を知ることではない。
-
お楽しみリスト。 脱線気味のアイデアが浮かんだら、それをリストに書きとめておいて、仕事に素早く戻ること。一段落ついたらこのリストを開く。
-
アイデアを膨らませる。 アイデアは驚いた小鳥のようなものだ。小鳥を脅すと二度と寄ってこなくなる。アイデアが浮かんだら、それをちょっと膨らませる。できるだけすぐにアイデアを検証すべきだが、否定するときは自信のなさからではなく、データをもとに否定すること。
-
80/15/5。 時間の80%をローリスクで見返りの確かな仕事に費やす。時間の15%は、ハイリスクで見返りの大きな仕事に費やす。時間の5%は、見返りに関係なく、自分の心をくすぐられるものに費やす。次世代には80%の仕事について教える。誰か跡を引き継ぐ準備するときが来たら、15%の実験(あるいはより頻度は低いが、5%の実験)の１つが報われ、それが80%の仕事の１つになるだろう。その繰り返しだ。
このアウトラインには１つの流れがある。時間を管理することによってリスクを減らし学びを増やすことからはじまり、頭脳全体を使い注意深くリスクを取りアイデアを素早くトリアージすることで終わる。