ダダ漏れ日記

（Java+Eclipseが前提） 保守不能ソースに絶望 しても、それに立ち向かわなくてはいけない時、 解読可能な状態に修正したいのだが、 リスクを取らずに定型的に行えることがある。 １）変数とメソッドのスコープを必要最低限にしてみる。 protectedや無印になっている変数をprivateにしてみたり、 内部からしか呼ばれていないくせにpublicなメソッドをprivateにしてみたり。 無駄なSetterだったり。 すると、実は使ってない変数やメソッドが浮かび上がってくるので、それらを思い切って削除する。 削除まで行かなくとも、外部から操作される可能性を絞る事ができる。 ２）privateで一回しか呼ばれないようなメソッドは展開してしまう。 ３）privateで数回呼ばれているけど、数行しかないメソッドは思い切って展開してしまう。 ４）２，３をしたことによって判明した無駄なエラーチェックや重複している処理を省く。 メソッドにわかれているが故に無駄なnullチェックをしている場合がある。 ５）Beanを使っている場合、そのSetterが消せないかどうか検討する。 この場合、BeanとはSetterとGetterをpublicで装備しているクラスを指す。 例えばInputStreamからBeanを作成するような場合、Setterを消して、Beanにファクトリメソッドを作成するのが有効。それだけで、外部から操作される可能性を消すことができる。 ６）直感的に判りにくいクラス名や変数名は、Eclipseのリファクタリング機能でおもいっきり判りやすい名前に変える。 ローマ字だっていいじゃないか。"銘柄"を示すクラスを"Meigara"としてみるとか。 ７）無駄に使い回されているローカル変数は、中カッコを駆使する等して、いちいち宣言しなおすようにする。 アセンブラのレジスタじゃないんだから変数を無駄に使いまわすのはやめようぜ。 これにより、ロジックの切れ目が判りやすくなる。 ８）メンバにする必要のない変数は、メンバから外しローカル変数とする。 ９）パッケージがかなり細かく分かれている場合、特にinterfaceとかlistenerとかで分...

人が作ったプログラムソースをここ5年ほどよく見るようになったが、 最近見ているソースがずば抜け過ぎているために、 それを表現する言葉をずっと探していたのだが、ようやく見つけた。 それが、「保守不能ソース」という言葉だ。 世の中のプログラムソースには二種類ある。 「保守可能ソース」と「保守不能ソース」だ。 で、得てして世の中は「保守不能ソース」を生み出してしまうわけだが、 なんと言ったらよいか、今の気持ちはそんな世の中に絶望した気持ちだ。 などということを考えていたら、テレビで修理に携わる職人たちを紹介していた。 そういえばソフトウェアの修理屋って職業を聞いたことはないが、 人のソースを解析してバグを修正するのは間違いなく修理屋のやる仕事だし、 今、自分がやっていることは、間違いなくその類なのだが。 修理専門のソフトウェア技術者ってのもありなのか、を想像してみた時に、 年がら年中、次から次へと、毎日向かい合うであろうそのソースの、 たぶん多くを占めているのは「保守不能ソース」だろう、ということを ・・・想像してみただけなのに吐き気がしてくる。。

開発において問題解決に臨む時、 忘れてはならない言葉ってのがあることに気づいたので 忘れないうちにメモ。 ・仮説 ・切り分け ・境界線 まあ、自分としては普段無意識にやってるので、 当たり前的なんだけども、改めて定義するのも 大切かな、と。

中規模システムの保守を行っている同僚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よ、キミの憤りは正当だ。ご愁傷さま！（爆笑）

自分はもしかしたらソースコードにコメントをすごく入れるほうかもしれない。 それは、アセンブラをやってたせいもあると思う。 アセンブラは解読が困難なので、コメントを書かなかっただけでなく、 コメントの出来が悪いだけで、昨日作った自分のソースですら 何をやっているのかよくわからない状況に陥ってしまう。 「明日の自分は他人」という格言まで編み出したくらいだ。 （自分としては名言だと思う。やや字足らずだが） しかし、最近コメントをロクに書かない人も増えているような気がして、 もしかしたら自分が特殊なのか？特殊ならまだしも時代遅れの OLDプログラマーだったらどうしよう、等と心配してしまう。 コメントを書かない人のなかで、 「メソッド名や変数名でカバーしてるから」という人もいたが、 その人のメソッド名と変数名は死ぬほど長く、もはや、 コメントの問題とは別に可読性が非常に悪かった。 （開いた瞬間見る気が失せるソース…） 自分の場合、コードを書いた後、俺レビューしながら、 コメントを整理するので、単純にコメントを書くというより、 もはやコーディングの一部なんだけど、 世の中の流れ的にはどうなんでしょう。 ワタクシが時代遅れじゃなければそれで良いんだけどね。。