誤った共通化 - 日々常々
前に書いた キョウミタコード と同系列のネタです。 「コードは共通化するべきである」 これ自体に真っ向から全否定することはまーないかなと思います。例えばこんな感じで処理A1-3から処理Bを呼ぶのパターンはよくあります。 コードの共通化。いいですねー。同じような処理をまとめておくとメンテコストがぐぐっと下がる気がします。これをしなきゃ、どんどんコピペされたメソッドが増えていくことでしょう。同じような処理はまとめていくことは重要です。 ところでこの図を見てください。 ……わかります？一度処理をまとめているにもかかわらず、まとめた処理がまた枝分かれしています。それもまとめる前と同じ単位で。コードで書くとこうなります。 class A { void method1() { B.method(1); } void method2() { B.method(2); } void method3() {
Defineアレルギー
baristaはDefineアレルギーである。新しいプロジェクトに参画して、既存モジュールの中にDefine.javaを発見した瞬間、全身に発疹ができる。これはbarista体内のDefineに対するIgE抗体が肥満細胞を活性化、ヒスタミン，ロイトコリエンなどの化学伝達物質が体内に放出されるためである。酷い場合にはアナフィラキシーショックを引き起こし、血圧の低下と上気道の浮腫による呼吸困難に苦しむ羽目になる。この場合、エピネフリン（アドレナリン）の皮下注がfirst aidだ。ここで静注を行なってはいけない。不整脈の原因になることがあるからだ。緊急時には気管挿管を行ない....しつこいですか？ 抗ヒスタミン剤を服用しつつ説明するが、C言語における.hファイルの感覚でpublic static finalな定数値を定義しまくった、巨大なDefineクラスを作ってはならない。これは有名なアン
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
