このため、後からバグが見つかった場合、問題の箇所を作ったプログラマがプロジェクトに残っていない、ということがよくある。そんなときには、残っている他のメンバーが修正を行うことになる。
バグを生むプログラムには、作り方がマズいものが多い。そんなプログラムの修正を任せられたプログラマは不幸である。「なんでこんな作り方をしてるんだ!」などと、悪態をつきながら対応することになるだろう。
しかし、本当に不幸なのは、問題のプログラムを作った本人である。
彼は既にプロジェクトを抜けてしまっているので、自分の書いたプログラムに問題があったことすら知らない。つまり、反省の機会も改善の機会も与えられないのである。
人間は過ちをしながら成長していく。特に、プログラマという職業には、そういった側面が強い。自分の過ちを知ることができないということは、彼にとって、大きな損失である。
また、そのような「作り逃げ」のような仕事しか与えてもらえなければ、仕事に対する責任感も育たないだろう。
プロジェクトを去った人間に、不具合のひとつひとつを通知せよ、とまでは言わない。しかし、あまりにも問題が多く出るようであれば(そして、彼が自社の社員であるならば)、管理者は何か手を打ったほうがよいだろう。再教育するとか、サポートする人間を付けるといったことである。
さもなくば、彼の行くところ、延々とバグが発生し続けることになるだろう。
■関連記事
・プログラマの出向事情
課題・仕様・設計―不幸なシステム開発を救うシンプルな法則
posted with amazlet
on 06.05.07
酒匂 寛
インプレスネットビジネスカンパニー (2003/11)
売り上げランキング: 83,247
インプレスネットビジネスカンパニー (2003/11)
売り上げランキング: 83,247
おすすめ度の平均:
課題・仕様・設計の3つの視点と成果物を解説課題を正しく理解しないと
プログラムの育てかた 現場で使えるリファクタリング入門
posted with amazlet
on 06.05.07
長谷川 裕一 斎川 博史
ソフトバンククリエイティブ (2005/02/01)
売り上げランキング: 176,298
ソフトバンククリエイティブ (2005/02/01)
売り上げランキング: 176,298
おすすめ度の平均:
リファクタリングについて楽しく学べる入門書として最適
初心者向けなのに初心者には見せられない・・・