ようやく最終章。週に１章ごと読んで約２ヶ月。ちょっとしんどいかったが、Kindleで単語をクリックすると勝手に出てくる辞書などに助けられながら最後まで辿り着いた。

So far in this book we've looked at pragmatic techniques that help an individual be a better programmer. Can these methods work for teams as well?The answer is a resounding "yes!" There are advantages to being a pragmatic individual, but these advantages are multiplied manyfold if the individual is working on a pragmatic team.

この本で紹介したpragmatic techniqueは個人だけでなくチームでも役立つ？もちろん答えはYes。この後に、割れ窓理論、DRY、直交性などが、それぞれチームでどう役立つのか落とし込んでいく。

At the dawn of the age of automobiles, the instructions for starting a Model-T Ford were more than two pages long. With modern cars, you just turn the key—the starting procedure is automatic and foolproof. A person following a list of instructions might flood the engine, but the automatic starter won't.Although computing is still an industry at the Model-T stage, we can't afford to go through two pages of instructions again and again for some common operation.

自動車産業の黎明期、T型フォードでエンジンをかけるためには２ページ以上の操作が必要だった。今のコンピュータもT型フォートと同じ段階だが、そんな余裕はない。ここからcronやmakefileの話が続くところは、ちょっと90年代。

You may decide to create a shell script to do some of the dirty work, but you still have to remember to run the script when needed.

シェルスクリプトを覚えてるのは大変だから、プロジェクト管理用のWebサイトなど立てる話につながる。そういえばRedmineの初版は2006年だ。当時のプログラマは何を使っていたのだろう。

最終章も結構なボリュームで、ほかにも引用したいことが多い。引用は３回までと決めてるが、今回だけオーバーして締めの言葉を引用する。

We want to see pride of ownership. "I wrote this, and I stand behind my work." Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a real professional.

さて、最後まで読み終わってもKindleの表示は71%だ。残り30%はAppendixとして情報源やExcerciseの回答が載っている。さすがに情報源は古いが、Quick Referenceは何度でも読み返したい。