放埒
う〜ん、ファイルが多い。多すぎる。.java の数だけで 8700 以上。
クリーンビルドするだけで大仕事だ。サブシステム単位でチェック
とクリーンとビルドができるけど、漠然ともっと便利にしたいなぁ。
しかしまぁよくここまで書き散らかしたものだよなぁ。あちこちに
コピペされているものがいっぱいあるし。纏めよう整理しようって
何で思わないんだろう。これ今後何年、一体誰が保守するんだか…
振り返ってみると、開発当初はコードの検査・診断を行うツールに
関して知識も少なかったし、危機感も淡かった。こんな惨状になる
なんて想像できなかったんだな。認めたくはないが、失敗だった。
この失敗が次の何かに活きればいいんだが、個人レベルの価値観の
押し付けという風に受け取られてしまって採用されず、同じ失敗を
何度も繰り返す社風なのが残念。…変えていきたい。自分も会社も。
危険なコードがそこらじゅう残存してるのは間違いないでしょう、
ってことで Action の子クラスに限って、final でないフィールド
を持っているクラスの一覧を作成するっちゅう物体を書いてみた。
…MaxPermSize でオチた。FreeBSD 上でやったので JavaVM は例の
アレではないものの、所詮由来は同じ Sun なわけで、落ちる時の
断末魔までそっくりそのままだったので、思わず笑ってしまった。
6 Comments:
ウチもいっぱいありますね。
反省。。。
えっ、危険なコードがたくさんあるんですか?
チェックして、危険じゃなければ放置でいいですよ。
Javaなお仕事してるんですな。私は仕事はほぼ全部C++ですよ。どこかにRubyな仕事が落ちていないものか。
整理しようってなんで思わないんだろうと思うコードにはしばしば遭遇しますね。どういう考え方をしているのか、本気で知りたいです。
> こじまさん
C++ だと 「Java を汚く書く」よりももっと激しく汚く書くことが可能なので、
…
…
…ご愁傷様です… orz
いま見てるコードは確かにC++だからこそ激しく汚い部分があるものの、こいつらにJavaを与えても大差ないコードがアウトプットされるんだろうなと思います。まあ、読み手(直し手)にとっての複雑度はある程度下がるとはおもうけど。
「激しく汚いコードを読み解くスキルも重要」と最近おもいまつ...。
> 読み解くスキルも重要
まったく同意ですよ...
特に保守フェーズに入っちゃってるソースの場合、重要さが増すんですよね。
そこそこ時間かけてせっかく読み解いたからって言っても、
読みやすく加工しなおしたものを気軽に commit できなくなってしまう。
そんな流れになってしまうと、保守・改造に臨むメンバが全員「解読」工程で詰まっちゃう。
みんなが止まってるぶんも工数積めればいいんですがね…
Post a Comment
<< Home