閲覧数：318 views
あなたが今、読んでいるカテゴリー：
Web制作、IT
ソフトウェアに不具合(バグ)はつきもの。納期が近づいてきたら
「バグ改修の為に明日も残業…明日も休日出勤…もう拙者、働きたくないでござる！」
と、デスマーチに追われるエンジニアが沢山いらっしゃるのではないでしょうか？
出典：働きたくないでござるとは (ハタラキタクナイデゴザルとは) [単語記事] – ニコニコ大百科
できれば不具合の発生は最小限に抑えたいものです。早く仕事を終わらせてお家でビールでも飲みたい方へ、6年半ソフトウェア開発に携わっていた筆者からのアドバイスです。
余計な機能は実装しない
大規模プロジェクトであれば実装前に外部仕様がきっちりと決まっており、勝手な判断で実装する事はまずないといっていいでしょう。しかし小規模プロジェクトの場合は外部仕様が実装後に後付けで行われてしまうところが存在するのも現状です。(脳内仕様のところもあります)
管理者が決めたことであるのであればまだしも、実装者の判断によって外部仕様が決まってしまうパターンが無きにしも非ずです。
「僕(わたし)的にはこの機能があったらいいなと思うし追加しちゃえ！！」
これは絶対にやってはいけません。まずこのように考えた方は
- その機能に対してのテストが必要なこと、それによって人件費がかかることを考えていない
- デグレが発生する可能性がある事を考慮していない
方です。プログラムを書くのが楽しくなってきたプログラマの初心者にありがちな傾向です。趣味ならそれでいいですが、仕事として開発を行うのであれば別です。お金が絡んでくる、ユーザーの信頼度を損ねかねないという観点から勝手な判断で機能を付け加えるべきではありません。
この章のまとめ
仕様が最優先です。機能を提案することは大事ですが仕様にないことを実装したいのであれば、まずは上流工程の方へ相談してください。
バグは必ずしも改修するものではない
初めに断っておくとまずバグが一つも存在しないソフトウェアなどこの世に存在しません。
プロジェクトが初期段階であれば改修しても問題ありません。これは改修してください。ですが、納期が近づいてからバグを勝手な判断で改修するのは間違っています。改修したコードが様々な機能に影響する可能性が考えられます。最悪、デグレが発生し余計な工数とお客様の信頼を損ねます。重大なエラー(フリーズ系、確実に必要な機能が正常に動作しない)であれば改修は必須ですが、バグの再現方法が極めてレアなケースや、普通に使う分に関してかなりどうでもいいバグはリリース間近になってくると改修しないケースもあります。
この章のまとめ
納期間近になってからの不具合改修は、影響範囲と改修にかかる工数を判断してからとなります。勝手に判断して改修しては絶対にいけません。まずは上流工程の方へ報告してください。
むやみにモジュールをアップデートしない
保守、運用の話になりますが、
- バグ改修が行われた
- 新しい機能が追加された
といってモジュール(プラグインなり、ライブラリなり)を何でもかんでもアップデートすべきではありません。アップデートが必要な時というのは
- バグ改修された内容が仕様に存在する機能の動作に関係している時
- 新しい機能を実装する為に、追加された機能が必要な時
に行うものです。モジュールをアップデートした時にかかる影響範囲は
- 新しい機能が追加されたことにより、別の不具合が埋め込まている可能性がある
- 新しい機能と他のモジュールが競合して、正常に動作しなくなることがある
という点です。ここを抑えておかないとデグレが発生する原因になります。変な話と思われるかもしれませんが
「モジュールAとモジュールBの不具合のおかげで、なんとか正常に動作している」
ということは意外とあるものなのです。
この章のまとめ
現行の仕様に必要ない機能の追加や、バグ改修された内容が現行の動作に関係ない場合、モジュールのアップデートは必要ありません。本当に必要な時にアップデートしてください。
さいごに
いかがでしたでしょうか。
この内容を徹底すれば、少なくとも不具合の数は減り、お家でゆっくりできる時間が増えるかとは思います。これから、プログラマ、システムエンジニアのエキスパートになりたい方の参考になれば幸いです。それでわ、また。
