SE徒然日誌

私がソースの修正を行う場合、かなりの確率でソースの整理が入ります。

• 定義のみの変数の削除。
  
• もはや元に戻せない修正前のソースのコメントの削除。
  
• 仕様変更等で絶対に入らなくなっている分岐等の不要な処理の削除。
  
• 同一処理の関数化。
  
• 変数名の統一化。
  
• 関数名を分かりやすくする。･･･

今回、上よりストップが入りました。

「お客さんに納品したソースはお客さんのものだから勝手に直しちゃいけない。」


確かに一理あるでしょう。
じゃぁ、バグ修正やパフォーマンス改善で一々お客さんに断りいれてるかっていうと「いれてない」です。(お客さんところで運用支援＋要望による仕様変更を行っているという環境なので)

もちろん画面のデザインを変える等のインターフェース部分を初めとする「使った上での変化」は仮にバグであっても断りを入れてます。どう考えたって直した方がよいなぁと思う箇所であっても了解を得なければ絶対に直しません。

「リファクタリング」の場合はどうでしょう？
動作は全く変わりません。むしろ今後の仕様変化に対しても柔軟に対応できるようになります。唯一の欠点はデグレが発生するリスクを伴うところです。

ソースをコアで見いて初期導入の今だからこそできるのであって、このタイミングを逃したらアンタッチャブル領域に突入です。


「今直さないと今後ソースいじれない」っておどしたら簡単に折れました。

･･･要するに、デグレがやなんだって。
ここの所、修正リリース後にちょくちょく動作不備があって、お客さんに文句言われたからが本音の気がします。

ぶっちゃけ、リファクタリングするしないに関わらず、リリース直後に若干の動作不備は覚悟してもらわないと。(もちろん、これは、こっちの都合であって、不具合が発生したらお客さんには謝ります)
その代わり常駐してるんだから障害をすぐに直せる大勢をとってるんだよ。システムがストップするようなでかい不具合なら問題だけど、ちっちゃな不具合で上がおたおたされちゃーやりにくいっすよ。

「ちゃんとテストしろ」って言われたって、私が要件聞いて提案して直してテストしてリリースしてんだから、発想漏れがあったらそもそもテストパターンが想定されてないんだから無理だろ。
ちゃんと他の人にもテストしてもらってって言ったって私が想定されるパターンも説明するんだから抜けはあるって。人任せにしないで取り仕切ってるあなたが本当に取り仕切って個人プレーから団体プレーに変えていってくれなきゃ。
(と、言いつつも、SEはチームプレー(野球？)じゃなくてスタンドプレーの集合体(サッカー？)だと思っています。)


確かに見た目変わらなくても改造していることには変わりないので、お客さんに了解とって勝手に今後もいじり倒します。

どーせ、保守も私がやるんだし。自分のいじったソースについては妥協したくないから。