『達人プログラマー』 - 故あって原書で読んでみました

別に英語で読んだからカッコいいとかそういうわけじゃなくて、ただ単に手元にあったのが原書だったというだけの話。Tip が全部英語だから、他人と「そうそう、あの Tip が…」って話すときに困るということに後から気がついた。バカだ。

The Pragmatic Programmer: From Journeyman to Master

「The Pragmatic Programmer」ってなもんだからプログラミングの話がメインなのは当然として、私が注目したのはドキュメントワークについての叡智。プログラマやマネージャとしてはものすごく優秀でお手本にしたいくらいなのに、ドキュメントワークについてはアバウト…っていう方は多い。そんな方は、ぜひ本書のドキュメントワークの側面を参考にして頂ければと思う。

ドキュメントは「言われたから作るもの」「決まりだから作るもの」「開発標準だから作るもの」「納品物だから作るもの」だと、ネガティブに捉えることしか出来ないエンジニアの何と多いことか。ドキュメントはコミュニケーションの一手段ってことを完全に忘れて、「面倒な仕事」だとしか考えていない。これだけコミュニケーションの重要性が声高に叫ばれている現在なのに、「コミュニケーションの質」や「コミュニケーションの効率性」に注意を払わない人があまりにも多すぎる。あちこちで喧伝されている「ドキュメントを作らずに済む」免罪符を手に入れたからって、ドキュメントを作らなくていいってわけじゃない。それが最大の効果を持つコミュニケーション手段であれば、良いドキュメントを作るのは当然のこと。

ドキュメントを作る上では、2 つの大事なコトがある。

• 読みやすいドキュメント(オンラインでも印刷後でも)
• メンテナンスがしやすいドキュメント

どちらも、プログラミングの観点からは当たり前のように言われている話。気がつかない人はいないと思うけど、「ドキュメント」を「ソースコード」に変えれば一目瞭然。しかしソースコードに対してはそのような姿勢で臨める人間が、どうしてドキュメントに対してはその姿勢を貫けないのか、それが私には分からない。

「6. Communicate!」の「Make It Look Good」は、明らかに前者について述べている。「There is no excuse for producing poor-looking printed documents.」なんて全エンジニアに叩き込みたいくらいだ。今はほんの少しの努力で、誰でも美しいドキュメントを作成出来る時代。もし貴方の組織にこのような事実に聡い人がいれば、貴方自身の努力は一切不要というくらいに。

ちなみに、私が気に入った Tip は以下の通り。

• 4: Don't live with broken windows.
• 11: DRY - Don’t repeat yourself.
• 14: There are no final decisions.
• 26: "select" isn’t broken.
• 37: Configure, Don’t integrate.
• 42: Separate View from Model.

たぶん、どれも当たり前のこと。しかしそれを愚直に、かつ自然体でこなせる人間こそ「達人プログラマー」と呼ばれるに値する人間なのだろう。

愚地独歩の

空手の基本の型全てを一日 1000 本、それを数十年続ける事ができるバカなら誰でもできる

ってのを思い出した。