プログラマの仕事はプログラムを読むことである

ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。

古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。

保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。

Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。（プログラマにとってのReduce/Reuse/Recycleってか。閑話休題）

このプログラムの保守のコストというのはプログラムの規模に比例する。大規模なソフトウェアであればあるほど保守コストの比重が高まっていく。新機能を追加するとしても、既にあるアーキテクチャにすり合わせるために、それを詳細に精密に理解する必要がある。

優れたプログラマはコードを書きっぱなしにしない。そのソフトウェアが使われている限り常にコードを読み改良していく。自分のコードであれ誰かが書いたコードであり、それを読み理解し改良する。

商用ソフトウェアの開発現場のベストプラクティスでは、コードはチームによって常にレビューされる。開発プロセスの中にしっかりレビューが組み込まれている。シニアプログラマの主な仕事はジュニアプログラマや同僚のコードをひたすらレビューすることである。書きっぱなしというのはありえない。もちろんOSSの世界では優しい独裁者の主な仕事はコードを書くことではなくレビューして、そのコードを受け入れるかリジェクトするか決定することである。

プログラマの基礎体力に対するコメントで

プログラマはプログラムを書くのが直接的な作業であって、
読む作業は、役に立つとはいえ、本業に対して間接的なものになります。
「基礎体力」のような大仰な物言いをして、直接関わりのない作業の能力を挙げられても、違和感を感じるだけです。

というのをいただいた。コメントありがとうございます。

もし、「プログラマを書くのが直接的な作業であって」と認識しているのであれば、それは、そーゆースタイルの現場というのがないとは言わないが、ベストプラクティスから程遠いと断言したい。わたしはそのようなスタイルは、古典的なウォーターフォールモデルで、要求定義、外部設計、詳細設計、コーディング、テスト、統合テスト、運用、保守、みたいな各フェーズを別々の人たちがやっているイメージをする。つまり、コーディングをするいわゆるプログラマと詳細設計、外部設計、要求定義をする人たちが見事なまでにばらばらというプロセスである。

「渡された仕様書を実装するサラリーマンプログラマ」の悲哀　にあるイメージである。優れたプログラマというのは要求定義から設計、コーディング、テストまでのプロセスに主体的に関わるのである。優れたソフトウェアはそのように作られるとわたしは思う。

プログラマとして生きて行くつもりなら、「渡された仕様書を実装するだけのサラリーマンプログラマ」よりは遥か上を目指すべき。そうでないなら、他の仕事を探した方が良い。自分のキャリアパスを見つけ出す責任を持つのは、会社でも上司でもなく、自分自身なのだから。(上述）

まあ、わたしの世界が狭いのかもしれないが、わたしの直接間接に出会った優れたプログラマは皆コードを良く読むプログラマであった。そしてコードを読むことによってどんどん成長している。

Comments

[投稿： mtabe]

お世話になってます
田部＠ATXです。
この文章を読んで共感できる方と仕事ができれば幸せだなぁ～と思いますｗ