2014/04/20 このエントリーをはてなブックマークに追加 はてなブックマーク - 数の暴力かスタンドプレーか?プログラマーのただしさとは何か (人日と引き換えに)

数の暴力かスタンドプレーか?プログラマーのただしさとは何か (人日と引き換えに)



システムには共通部品というものが必ず存在する。
共通で使う、ということ。
それはつまり影響範囲が大きい。
共通部品を直したのに(ここ重要)、各業務で不具合が大量発生したら。。。
あなたなら何が正しいと思いますか。




これは、実際にSIの現場であったお話です。







 前提


・フェーズは単体試験
・共通部品には不具合がある(部品の仕様を満たしていない)
・不具合を直すと、その修正により各業務に不具合が出てしまう
・共通部品にも業務部品にも不具合があるが、システム上は問題なく動いている



 不具合を発見した日


その共通部品というのは、オブジェクトのコピーを行い、移し変える機能を持つモジュールだった。
インプットのオブジェクトに対して、指定されたクラスのオブジェクトに値を移し変えるというもの。
同一プロパティ名同士が紐付いて、コピーが行われる。

この部品について、僕はある条件の場合に
値の移しかえが上手くいってないことに気づいた。

僕は不具合をすぐに直し、コミットした。
アウトプットのオブジェクトの値が変わるから、
もしかすると業務で障害が出るかもしれないな。
とは思ったが、設計、製造、テストまでキッチリやっていれば
そこまで影響はないだろう(数ヵ所におさまるだろう)と考えていた。

その日は何も問題は起きず、そのまま僕は帰った。


 翌日


やはり、業務で不具合が発生した。
しかも、それは僕の予想よりもはるかに影響範囲の
大きいものだった。

様々なところでシステム障害が発生し、
問題となっていた。

これは正直、予想外だった。



無論、原因は僕の改修である。
でも、僕は間違ったものを直しただけなのである。




 結果


結果的に各業務で不具合を修正する工数がとれないことが問題視され、
共通部品は部品仕様を満たさないままの状態で利用されることとなった。
つまり、ソースは差し戻しである。



 まとめ


共通部品の振る舞いが変わったことにより、
障害が多方面で発生した訳だが、
問題の本質を考えるとなかなか根深い。

・部品仕様を理解しないまま利用されている

・部品の不具合を前提として正常な動作をしている
→つまり、モジュールの変更や拡張が出来ない

・細かな入力値のチェックがテストで行われていない
→ブラックボックス観点は満たされていたのだろうが、ホワイトボックス観点が薄かったと思われる。
でなければ、もっと早くこの不具合は発見されていただろう

・モジュールや業務としての正しさが保証されない
→共通部品はもちろん、危ない挙動のまま動くことになってしまう。
システムとしては潜在バグの発見の遅れにつながるのではないかな。
まぁ、どこかですくい上げられれば、問題ないんだが。

・多数が間違っているため共通部品が直せないという数の暴力
→いや、言い過ぎか。それだけ責任持って直さないとだめなんだよね。



「システム的に正しい動きをしている」というのと、「モジュールとして正しい」というのは別の話である。




ユーザーとしては一見して問題がないように見えるのだが、
モジュールの不具合を隠蔽し利用し続けることは
将来的なシステムの負債を潜在させていることになる。

最近流行りの「技術的負債」(クソコード)というやつである。

業務実装は部品の不具合に依存し、
簡単に崩れてしまうものであるから、
共通部品を作成する際や修正する際は
常にその影響範囲を意識しなければならない。
つまり、僕が安易に直しすぎたなーって所は感じています。
直すなら、製造入る前だよな。
共通部品なんてのは、本来、製造入る前に出揃ってないとだめだし、
製造入ってからもちょこちょこいじってたからな。。。こわいこわい



一方で、業務実装としては、どこまで共通部品に依存し、
各業務の「横軸」で見たときに修正、保守がしやすいか
ということを考えなければならない。
(つまるところAOPです)


正直、不具合に気づくのが遅すぎたのかなぁというのはある。
だから、ウォータフォールは嫌だというか、難しいというか。
いや、これに関してはウォータフォールのせいじゃないな。

なんにせよ、色々遅すぎた。


皆さんの仕事場でも、こういうことはありますか?
何かを誤魔化す感覚に僕はとても情けなくなってしまいます。
もっと自分の力をつける必要があるなと感じるのです。



まとまり無いですが、こんなところで。










2 件のコメント:

  1. よくありますね。
    外部のツールやパッケージなどでドキュメントに詳細な記述が無いもの(時にはあっても)などは、利用者は結果主義で使っていくので
    、製品仕様が間違っていたとしても簡単に直すことはできないですね(NULLの取り扱いなどでよくある)。
    互換パラメータのオンパレードになる場合もあります。

    返信削除
    返信
    1. >Unknownさん

      >(NULLの取り扱いなどでよくある)
      >互換パラメータのオンパレード
      おっしゃるとおりです。
      結果主義になっちゃうんですよねー。。

      削除