プロジェクトリーダーは「技術的負債」より「工数」が大事・・・。
最近
手を入れたソースで過去の自分からのメッセージを読みました。
「今は納期優先でここまでが限界なので未来の人よろしく」っとw
その未来の人は当の本人だったりしますが(汗)
当時はその案件から外れる予定で短納期の修正が多かったのを覚えています。
じっくり考える猶予もなくとにかく動くものをリリースしろと。
今
リファクタリングをすると余計なことはしないでいいですと言われてしまうので・・・。
目の前によりよく出来るソースが転がってるのに手を出すなと言われるエンジニアの寂しさと言ったら。
そうは言われても結局面倒を見るのは未来の自分なので「ここはちょっと設計が面倒ですね」なんて言い訳をしながらひっそりとリファクタリングはするんですけどね。
コードの保守性を上げて文句を言われるのにはウンザリですがサラリーマンエンジニアなので仕方ありません。
そのままダメコードにダメコードを追加したら次回同じような改修が来たさいにざっくり1週間は掛かりそうです。
今、手を入れてキレイにしてあげることで次回の改修作業は1行追加するだけで良くなるのに・・・。
if(isHoge){
処理
}このHogeが二値比較ではなくどんどん増えていきそうなんです。
今回の依頼で、"hoge"、"fuga"、"それ以外"に変わったので、絶対に次も似たような追加作業が待っています。
ここでまた、「未来の人、ごめんなさい、納期重視でゴミコードを書いてます」とは書きたくないんです。
そのゴミコードをメンテするのが自分じゃなくてもです。
今回も
確かに短納期ではありますが、そこを何とかしてこそのエンジニア!
未来の自分のために今回は絶対にリファクタします。
せめて、関係する値はenumにまとめたい。
そうすればループで回そうがswitch文で判定しようが直書きよりはマシでしょう。
enumにすると言っても大したコードは書きません。
public enum Foo {
HOGE("hoge"),
FUGA("fuga");
private final String text;
private foo(String text) {
this.text = text;
}
public String getText() {
return text;
}
//emunのメンバーかどうかの判定はしたい
public static boolean isMember(String string) {
for (Foo foo : Foo.values()) {
if (foo.getText().equals(string)) {
return true;
}
}
return false;
}このenumを実際に使用する部分のコーディングを考えなければいけませんが、それが問題なんですよね。。。。
if(isHoge){
処理
}の部分だけであれば、
if (Foo.isMember(foo.getText())) {
処理
}としておけば値が増えても困りません。
だがしかし、そんなに甘いコードなんてあるわけがないんです。
あるあるですが既存コードが物凄く足を引っ張るんですね・・・。
次回の改修作業の時にenumの値変更だけで乗り切りるにはどう改修作業をしていくかが問題です。
たぶんですが、実現したとしても汚いソースコードが書きあがる予感しかしません・・・。
そこを何とかしなと負債の返済なんて見えてこないよー。
よし、やっぱり未来の自分に丸投げだ!!(未来の自分ごめんよー
そんな訳であまりに切なかったので投稿していましました。
どうしてもマネジメント層にはこの負債の返済って響かないんですよね・・・。
「動けばいいでしょ、何の問題があるの?」
「予算は無限じゃないんですよー!!、見積もりで蹴られても知りませんよ」っと言ってあげたい・・・。








ディスカッション
コメント一覧
まだ、コメントがありません