書き直したい！

ある程度のプログラミングスキルを持っている人なら必ずぶち当たるこの衝動！なんだ、このクソッタレなコードは！直したい！まっとうな姿に矯正したい！エンジニアの道・人の道を叩き込んでやりたい！！！

boolean result = false;
...
return result = hoge.validate(data);

もうね、アホかと。resultへの代入になんの意味があるのかと。面白すぎるっての。

他にも直したいところ多くて困る。例えば、とあるメソッドのJavadocコメントがこう書かれているわけだ。

○○で××である場合にコールされる。

そんなもん、ロジック見ればわかるわ！！知りたいのは、コールされたこのメソッドがどういう動作をするのか、だ！！生成されたJavadocにこんなこと書いてあったってなんの役にも立たないだろうが、ボンクラが！

＃イベントハンドラやfinalize系のメソッドについては、この書き方でも良い。

コメントもまたダメである。

return; // 終了

だから見ればわかると。終了しているのは貴様の脳のほうだ。上司や先輩から「コメント書くべし」と教えられ、その意義を理解せずにただただ書けばよいと思っているに違いない。

コードはもちろんだが、コメントおよびJavadocコメントのひどさも何年たっても変わらない。コメントがカスでもプログラムは動くので、注意しないようだ。

現在、納品間近の製品の最終調整に参加していて、バグを直したりしている過程でこういうネタを得ているわけだが、このプロジェクトは他にもいろいろ変なことをやっていて、非常に良い反面教師になる。驚いたのは、CVSの扱い。

まず、ブランチを作らない。開発用のトランク以外に、例えば客先デモ用にいくらか特殊な改修を施したソースが必要になった場合、通常はそれ用にブランチを作って管理する。そして、両者に共通するバグがある場合、一方で改修して、その内容をもう一方にマージしたりする。これは、トランク（幹）から派生したブランチ（枝）、という関係があるからこそ可能な操作である。ところが、このプロジェクトではいちいち新しくモジュールを作っている。この場合、トランクとの関係が完全に切れてしまう。マージなんてとんでもない。さらに、無駄にモジュールが増えまくり、だいたいの場合モジュール名もいい加減なので管理に苦労する（module1とmodule_xyzがそれぞれどういう立場のモジュールで、どういう関係なのか理解できるわけもない）。

また、１つのCVSアカウントを複数人数で使いまわしている。一見意味不明なコードがあったので、これを書いた人をcvs annotateで特定して、実装理由を聞こうとしたのである。ところが、「このアカウントはいろんな人が使ってるから、実際に誰が書いたのかわからない」などと言われてしまい、追いかけられない。おそらく無意味なので消してしまいたいのだが、万が一ということがあるのでそのまま残した。こうしてコードがスパゲッティになっていく・・・。

あぁ、今年入社の新人たちがこんなマヌケな環境に毒されたらどうしよう。あっさりと迎合せずに、自分で勉強して、たくましく育っていってほしい。「なんかおかしいぞ、これ？」と思ったら、遠慮なく先輩方の言動を疑ってかかるべし。Believe your justice、だ。