Blikiを読もう（４）

アジャイル Bliki

で、気付くとまた4日。せめて土日に1つくらいは見るようにしようよ。

コードがドキュメントだ

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CodeAsDocumentation

先ほどの「コードは重要なドキュメントだ」という原則だけど、「コードが"唯一の"ドキュメントだ」とは言ってない。

しっかり間違えてました。今は分かります（間違ってないよな……）。
コミュニケーションを円滑にするためのドキュメントはむしろ積極的に作るべきなんですよね。
憎むべきは「最新の状態でない」ドキュメント。
いくら量が多くても、最新の状態でなければ、非常に困るというか、どれを信じていいのか分からなくなって、結局コードしか頼るものがないという哀しい状態に。

  • 最新の状態に保てる程度のドキュメント（でもシステムを伝えるには十分であることが必要）
  • 読みやすいコード

が揃ったプロジェクトをお手本として見習えばいいのだけれど……って何でもかんでも他人に依存するなって？
読みやすいコードについては、本で勉強できるのかな？
※ あれ？ リファクタリングは本を買っていたような………。

まず『Code Complete』は読んどくべきだ。当然、『リファクタリング』も推薦しておこう ――結局、リファクタリングってのは、コードをクリアにするってことなんだ。『リファクタリング』の次は、当然『パターン指向リファクタリング入門』だ。

最新の状態に保てる程度のドキュメントは……まぁ今後みんなですったもんだしながら考えていくことにしよう。
とりあえず作ったドキュメントが最新でなくなったと分かった時点で、どこまでなら最新にしておけるのかをみんなで話し合ってみようか。

最後に。

プロのプログラマというのは、チームのために自分のスタイルを曲げる覚悟があるんだ。
たとえ三項演算子が好きでも、チームが分かりにくいと感じたなら、使わない。
自分スタイルのプログラミングは、個人プロジェクトでやればいい。

個人じゃなくってチームで開発しているんだから、チームの問題を解決するために譲歩するのは当たり前。
その辺を分かってなくてあれこれ言う人（俺もそんなところが多いなぁ）は、プロとは言えないのですね。
それは、アジャイルを無理やり導入しようとすることも一緒なわけで、注意しようね。