Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

プログラムに対する指摘の受け取りかたの分類

前提:

プログラムに対する指摘への回答が全て「仕様です」で返ってくる、という笑い話は前世紀からある。 ここで、実際にはどういった回答が考えられるか。

検討観点:

  • プログラムの設計時に検討対象に挙がっていた内容か?
  • 実現可能性はあるか?
  • 実際にプログラムへ実装したか?
  • 現在の挙動になっている(機能要件上の)理由はあるか?

といった軸を観点として分類してみる。

まとめ案:

新機能追加要望に対する回答を想定して分類してみた。

# 回答 検討対象に 実現可能性 実装 今の挙動にした理由
1 仕様 挙がってた あり した ある
2 不具合 挙がってた あり した ない
3 制限事項 挙がってた ありor未検討 してない ない
4 対応不可能 挙がってた なし してない -
5 スコープ外 挙げてなかった 未検討 してない -
  1. 仕様です:そうした方がいい(あるいは他のにしない方がいい)理由があって、現在の挙動になっています。
  2. 不具合です:そうした方がいいと思って、そのように実装したつもりが、そうなっていませんでした。
  3. 制限事項です:そうした方がいいのは分かってますが、工数やら期日やら自分たちの都合の関係で実装できていません。
  4. 対応不可能です:そうなってたらいいとは思いますが、原理的に・他のプログラムとの組み合わせ的に不可能です。
  5. スコープ外です:そもそも検討対象に挙がっていません・挙げていません。