デグレとは？
基本アップグレードの反対、すなわち悪くなる方向に修正がかかったり、ひどくなったりすることです。
また、昔あった問題が再発するケースもデグレと呼んでました。この辺は文化の違いで呼び方が違うケースもあるので難しい部分ですが、やっぱり
修正したけど良くならないことをデグレと呼びます。
相変わらず本記事も殴り書きなので中身はあんまりありません、期待しないように
性能落ちもデグレに含まれます
例えば秒間1000tpsを確保しないといけないのに機能追加したことにより1000tpsを確保できなかった、、なーんていうのもデグレに入ります。
新機能いれたんだから仕方ないじゃん！悪くなってないじゃん
っていう人もいるかとおもいます。
が、要求性能を満たせない場合は事前にH/Wの強化なりしないといけません。
実際どれぐらい落ちるかなんていうのは事前検証と
経験が頼り
ですけどね。
で、なんで性能の話をしたかというと
仕様書に書かれている要件定義をちゃんと理解していない人が適当にパッチして要件を満たさないということは基本許されません。
顧客に事前に理解してもらわないと下手すると損害賠償問題に発展します。
もちろん例外もあります、被害拡大・セキュリティ的に緊急に対処しないといけない場合はパッチして、早急にH/W増強手配します。もしくは運用対処です。
が、少なくとも分かっている事は全て顧客と情報共有することが基本です。*1
もう核心部分にふれてるんですけど
なぜ起きるか？は、
要件・設計を理解していないからです。
それは業務設計であろうがモジュール設計であろうが同じです。
一般的にわかりやすいかと思ってプログラマと以下書いていますが、業務設計者やネットワーク設計者も同じです。
Aモジュールに修正したらどこまで影響範囲があるか知らずにAモジュールを作った人が修正したことによって利用している先で問題が発生するんです。
で、３流プログラマは、そんなんしらんわ！！起きた（言われた）問題を修正をしただけや！って言います。
2流プログラマは、こういう使われ方で、こういう事象が起きますがどうしますか？と問題を投げかけてきてくれます。最低限情報があれば対処できるので、プロなら最低限ここまでして欲しいです。
1流プログラマは、改修（修正）・追加すると、こういう問題がこういうケースで起きます。対処案はA,B,Cあります。
みたいにちゃんと要件や設計背景を理解した上で修正しようとします。
もちろん検証しないと分からない事がいっぱい
どこまで影響あるかなんて、実際動かしてみないと分からないことはたくさんあります、それは業務フロー*2であってもモジュールであってもです。
デグレチェック、定型業務チェック、基本機能チェックなどいろいろな呼び方はあるとおもいますが、一か所でも修正したら、関連する機能全てチェックするのが本来の姿です。
が、そんな時間もお金もかけられないのが現実、、紙の上でどこまで拾えるかが腕の見せ所になると思います。
履歴は重要です
なので、どこをどう直していったか、、、を把握しておくことは重要です。
最近ではTracなど管理ツールなどでソース上の履歴は把握している事が多くなってきましたが、ドキュメントと結びついていないケースが多々あります。
例えば、機能マトリックス的なパターン表のある部分が修正された場合、設計書が修正されていないと、次直す人が古い情報を見ていじると、、、
デグレます
そりゃそうですよね、そうかいているんですからなおしちゃいますよね(* ´艸｀)ｸｽｸｽ
わたしの経験上最後の方は、修正した場合ドキュメント修正していないとリリース不可というプロジェクトも増えてきましたが、リソース（資金、人）がある程度潤沢なプロジェクトのみでした。
最近のトレンドではどうなってるんですかね？教えてほしいものです。
バグやセキュリティに関する修正の場合
横展開、水平展開呼び方はいろいろですが津波のように襲ってきます。
どこかのソースのコピペが多いプロジェクトで、多人数だと、Aさんが出したバグを全てもモジュール（ソース）に適用しているか、確認するのがすごく大変です。
同じパターンでも、とあるケースでは問題ないというかバグ付きが仕様上正しい箇所とかもあります。
そうなると、機械的に同じコードを全部置換する（さすがに機械的にはしませんが）と
デグレます
理想はちゃんとオブジェクト指向とかになっていて、同じようなコードはほぼないことが理想ですが
世の中そんな甘くありません
例外パターン対処でコピペベースで違うモジュールができてたりします。
いやー大変ですね。
もうやりたくないです(* ´艸｀)ｸｽｸｽ
設計書やネットワーク設計している人も同じですよー
似たものコピーして値だけかえてたりすると大変ですよー
トライアンドエラーという逃げ言葉
最近はこの言葉で片付けられることが多くなってるきがします、とりあえず直しましょう。問題あればもどしたらいいですし、やってみよう。
はい、実験システムや検証環境ならそれもいいです。
ゲームでもまぁ、、課金にからんでなければゲームバランスってことで・・・
が、商用システムでおこしたら、顧客の先のエンドユーザがかんかんになります。
なので
やっちゃいけないんですよ！
例外的にやってみないとどうしてもわからない時だけ使う言葉ですよ！
っていうのを言いたい。
問題がありましたのでもどしました、ご迷惑おかけしました。ゆるしてちょ
みたいな感じで片付けられるケースが多いです。
なんなんですかねー
まとめ
適当に書きなぐってるだけなので中身はあまりありませんので、そんなんわかっとるわ！という人とちんぷんかんぷんな人にわかれそうですが、長い記事は嫌いなので
今回はこの辺で愚痴は終わりにしたいと思います。
