コンテンツにスキップ

プログラマが知るべき97のこと/コードは生涯サポートするつもりで書く

提供:Wikisource

「すべてのプログラマが必ず知っておくべきこと、また、必ずすべきことは何ですか」と97人に尋ねたとしたら、きっと97通りの答えが返ってくるでしょう。97通りの答えを聞いて圧倒されてしまう人、威圧されてしまう人もいるはずです。どのアドバイスも素晴らしいはずです。守るべきと言われる原則は、どれも確かに守るべきと思えますし、紹介されるコツはどれも参考になります。どの話にも説得力があり、なるほど正しいと思えます。ただ、どれも良いとなると、まず何を自分に取り入れるべきか迷ってしまいます。一体何から始めればいいのでしょうか。さらに大事なことは、いわゆる「ベストプラクティス」を学び、ずっと守り続けることです。「ベストプラクティス」が完全に自分のものになり、守るのが当たり前になればしめたものですが、どうすればそうなるのでしょうか。

結局は気持ちの持ち方、さらに言えば、取り組む態度の問題ということになってしまうのだと思います。たとえば、同僚のプログラマやテスター、マネージャ、営業やマーケティングのスタッフ、エンドユーザといった人たちのことが念頭になければ、なかなかテスト駆動開発を採用しようとは思わないでしょうし、明解なコメントを書こうと心がけることもないでしょう気持ちの持ち方、取り組む態度を変えるには、実はちょっとしたコツがあります。それは、

いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。

ということです。それだけで、「良い製品を作らねば」という気になります。「生涯サポートしなくてはならない」と考えながら仕事をするようになれば、素晴らしいことが起きるでしょう。もし、これまでに書いたコードを本当にすべて生涯サポートしなくてはならないのだとしたら、たとえば、ずっと以前に書いたfooBarメソッドについて、いつ問い合わせを受けるかわからない、となったらどうでしょうか。以前に勤めていた会社、あるいは今勤めている会社から真夜中に電話がかかってきて、「どういう理由でこういうコードを書いたのか説明してくれ」と言われでも文句は言えないとしたら。そう考えれば、自然に、そんな問い合わせを受けないで済むようにしたい、と思うでしょう。そのために、技術力を少しずつでも高めようとし、変数名やメソッド名のつけ方にも注意するようになります。1ブロックが何百行にも及ぶコードを書いて放置する、ということもなくなるでしょう。デザインパターンについて学び、常により良いデザインパターンを探し、それを使うようになります。コメントもまめに書くようになり、テストも逐一実施するようになります。リファクタリングも頻繁に行うようになるでしょう。自分の書いたすべてのコードを生涯サポートするというのは、サポートするコードが時間が経つほど増えていくということを意味します。つまり、知識と知力、そして技術力を磨き、仕事の効率も上げていかないと対応しきれなくなってしまうことは明らかです。

これまでに書いてきたコードは、どれほど前のものであっても、好むと好まぎるとにかかわらず、必ず今の自分の仕事に影響を与えているのです。そのことは少し考えてみればわかるでしょう。コードを書くというのは、自分の知識や技術、取り組む姿勢、つまりプロ意識や責任感がどれほどのものか、それを他人がうかがい知るための手がかりを残すということです。コードを見れば、メソッドやクラス、モジュールの設計、コーディングを、担当した人がどのくらい楽しんでいたかもわかります。皆、書かれたコードを見て、書いた人がどういう人か評価するのです。その評価が常に良くないものであれば、誰もその人に重要な仕事を任せようとは思いません。つまり、良くないコードを書いていれば、キャリアアップのチャンスも減ってしまうということです。コードを1行書く度に、ユーザのこと、顧客のこと、そして自分のキャリアのことを考えるべきです。このコードは自分の今後の人生を決めるのだ、と思って書くべきでしょう。