痛いソース・オブ・ザ・イヤー
中規模システムの保守を行っている同僚Mが頭を抱えていたのを見かけた。
面倒なので無視しようと思ったが、かわいそうなので話を聞いてあげた。
彼曰く、
あるenumに定義を追加したところ、全体的に動作がおかしくなった。
そのenumは、Webサイトのページの識別子で50個ほど定義がある。
仕方ないのでそれを使用している他のソースを調べてみたところ、
enumをわざわざ配列化し、それのインデックスを用いて値を指定していた。
以下のようなソースだ。
※本物は、Itai.values()がメソッド化されていたり(それも痛い)複雑極まりない作りになっている
で、追加した定義はenumの途中だったので、インデックスがずれてしまい、バグってしまった。
これを直すには、ずれたインデックス指定をすべて+1しなくてはいけないが、
そもそも色々と納得できない!
間違いない。
今年見た中で最も痛いソースだ!
このソースを書いた人が誰かは知らないが、痛い・オブ・ザ・イヤーを進呈しよう
同僚Mよ、キミの憤りは正当だ。ご愁傷さま!(爆笑)
面倒なので無視しようと思ったが、かわいそうなので話を聞いてあげた。
彼曰く、
あるenumに定義を追加したところ、全体的に動作がおかしくなった。
そのenumは、Webサイトのページの識別子で50個ほど定義がある。
仕方ないのでそれを使用している他のソースを調べてみたところ、
enumをわざわざ配列化し、それのインデックスを用いて値を指定していた。
以下のようなソースだ。
enum Itai {
A,
B,
C,
};
・
・
if( ... ) {
return Itai.values()[0];
} else if( ... ) {
return Itai.values()[1];
} else {
return Itai.values()[2];
}
※本物は、Itai.values()がメソッド化されていたり(それも痛い)複雑極まりない作りになっている
で、追加した定義はenumの途中だったので、インデックスがずれてしまい、バグってしまった。
これを直すには、ずれたインデックス指定をすべて+1しなくてはいけないが、
そもそも色々と納得できない!
間違いない。
今年見た中で最も痛いソースだ!
このソースを書いた人が誰かは知らないが、痛い・オブ・ザ・イヤーを進呈しよう
同僚Mよ、キミの憤りは正当だ。ご愁傷さま!(爆笑)
コメント
コメントを投稿