止まらないバグとコメントの嵐
開発環境の構築をするためにVMware Serverを導入して、2年ほど経った。
「効率化」が嫌いなのに、VMware Serverで開発環境を構築して、コピペでできる開発環境で構築時間を短縮することで、新プロジェクトに取り掛かる際の効率化(時間短縮)になればと思ったのだ。ライセンスはかかるため開発コストの圧縮まではできなかったが……。
ただ、たまにどこに何が入っているか分からなくなった時、効率化したつもりが非効率的になっている気がして、げんなりする。結局は運用まで検討しなければ、効率化にはならないのですね。目先の対応はいけません。
<重なるバグ>
僕は、いつもと同じように、MSプロジェクトに書かれた自分のスケジュールを確認して、コーディング作業に入っていた。
いつもと同じ、変わらない作業。変わらない日常。
ただ、電話が鳴りやまない……。
リンリンリンリンリンリンリンリン!!!!!!
朝一番で発覚したユーザーからの電話によるバグ報告で、僕の同期はデバッグ作業に集中していた。
当時はリリースすれば、バグ発生の状態が続いたことがあった。ぷよぷよで言えば5連鎖、6連鎖。パッケージソフトとして展開していたので、1つのバグ報告で多くのクレームが舞い込む。
原因としては、バージョンアップによって既存機能がおかしくなる(いままでと違う動きなど)というバグだ。今も昔も多いバグだと思うが、特に基幹システムのバージョンアップでは多いような気がしている。
正直にいうと、同じ個所の修正を僕がやっていれば彼と同じようにバグを出していた確信があった。僕は運が良かっただけだ……。心の中でものすごく悲しかった。自分の仕事もあって手伝えなかったが、必死にデバッグしている彼を見て、僕は心が痛かった……。
僕の同期はとっても素直ないい子だった。もう何年も付き合っている彼女のことを大切にしている。僕としてはあまり見たことのない純粋な子だったのだ。通常だったら助けたいなんて思いもしない僕だけど、彼に対しては違っていた。
ただ、すぐに僕も後を追うことになったので、お互い「慰め合い」「励まし合い」「助け合う」ことでなんとかプログラマを続けていた。彼がいなければ、バグに過敏になりすぎて、人間不信に陥るところだった。
2年目にはずいぶんベテラン風になってしまい。中途採用の人に2年目だといったら驚かれたのを覚えている。
「え!! ○○さん、まだ2年目なんですか」彼女はその1週間後に会社を辞めた。
それでも、徹夜とかはなかったので、いい会社だったと思う。今考えると環境に甘えていた。
その後に労働基準局が入り、残業でもめたので、次期リーダー候補となる人も、そのいざこざでやめてしまった。
僕たちは、とにかく作ることをだけを目標にされ、社内ミーティングも禁止になった。
どんどん頼る人がいなくなり、残業問題で社内でのミーティングもできなくなり、全体で話し合う機会もないまま、時間だけが過ぎていった。
ある時、バグ発生数を数えることをやめてしまった僕たちに上司が切れた。
「なんなんだ、このバグは、どうにかならんのか!!」
地獄のような会議を終えて。みんな顔が疲れていた。
長年改修を続けているパッケージソフトなのでどうしても、改修を入れた場合に、予想外の動きをする個所がある。すべてを把握してプログラムする必要があったが、工数2~3日では結局そこまでできなかったというのが、当時の僕の本音である。
そんな中、開発チームでミーティングを実施した。みんな真剣な顔で悩んでいた。そんな静寂の中突然マネージャが口を開いた。
「開発をやめればいいんだ」
みんなも、
「そうだ、そうだ、やめればいいんだ」「ナイスアイデア!!」
みんな変なテンションでした……。
<コメントの嵐>
そんなことが、解決策じゃないってみんな知ってたけど……みんな病んでいたのだ。
そこで立ち止まれないので、バグに対して、みんなで考えた対策を実施していこうという話になった。
まず最初に実施したのが、コメント規約の変更。僕はこれには反対だった。マネージャも反対していたような気がする。
修正前のソースをそのままコメントアウトしてDEL、追加はADD、修正はMODとしてコメントを残していく。かつ修正番号を振ることで、バグ発生時にすぐに修正個所が発見できるという話だった。ただ、この対応以降、猛烈にソースが読みにくくなった。
最初の修正でバグが発覚して、対応者が検索ですぐに問題を見つけれたのがいけなかったんだろう。もう、なんだか「すぐに対応できるぜ!!」という勢いになってしまったのだ。
もう2、3カ月したらコメントの嵐ですよ。
何年もやっている僕がソースを読むのがつらいのに、新人はどうするんだよと僕は思った。当時Teamsourceでソース管理していたので、そっちで修正個所を見ればいいのだ。
この対策では、バグを見つける効率を上げるために取った対策が、後々のソースコードの複雑さにつながった。ソースはシンプルできれいな方がいい。それまでも心の中で感じていたことだが、確信した瞬間だった。
コメント
Selene.Net
終わらないバグ修正。
覚えがありますね。
バグを直しても直してもバグが出る、
寧ろ仕様自身がバグだったり。
作り直した記憶があります。
simple is best.
まさにその通りですね。
シンプルな構造にするのは私にはまだまだ難しいです。
tatsuki
そうですねよ、難しいと思ですよね。機能付け加えるのにはみんな寛大ですが、シンプルにする為に機能削ることには臆病ですからな。
僕にも難しいです。