日々の破片

_ ぴちょんくん

使っていた空気清浄器（静電気で塵をくっつけるタイプのやつ。別名しゅーしゅー先生2号）が、とうとう壊れてしまったので、ビックカメラにV3を買いに出かけた。

いやぁ、ぴちょんくんが、いるいる。おかげで子供が喜んじゃって、なるほど、エアコンだのって家族で買いに来ることもあるだろうし、その場合、価格的な問題がなければ、子供が喜ぶのを買ってしまうってことは十分にありそうだ。ネーミングも、絵もいい感じだし。くーに似てる気もしないでもないけど。

というわけで、空気清浄器（というより機だな、こんだのは）はダイキンのになってしまった。でも、店頭ではぴちょんくんのシールが貼ってあったのに、商品自体には同梱されてないのか。ちょっとがっかりかも。

#最初ぴちょんくんで行こうとしたら、オヤジ社員達から、快適健康号とかにしろ！ と強い圧力がかかってどうしたというような良くある苦労話をどっかで読んだんだが（紙かWebかもわからん）、ここにはすんなり企画が通ったと書いてあるなぁ。

_ 速度、可読性、保守性

　以下のうーんざりするようなコード片を目にした場合、どう対処できるか？ （テーブルには手が出せないものとする）

stmt.setInt(1, a.getA1());
stmt.setInt(2, a.getA2());
...
stmt.setInt(120, a.getA120());
stmt.executeUpdate();

良く、aで示されるクラスを作ったもんだと思わなくも無いが、それにしてもこんなの120行も書いていて、何か変だと思わないのか？ と訊けば、良くぞ訊いてくださったとばかりに、最近のエディタはちゃんとしたマクロがありますから問題ありません、と平然と答えたりして。ほーそうか。それにしても良く120個もゲッタを持ったビーンを作ったものだなぁ。と言うと、最近の統合環境では……あぁ、君は黙っていてくれたまえ。 120個もゲッタがある、しかも120個もインスタンス変数があるのなら、例えば、こういう手法は考えつかんのか？

class A {
  private Map map;
  public int get(String key) { return ((Integer)map.get(key)).intValue(); }
  ...
}
....
String[] keys = { "A1", "A2" ... };
...
for (int i = 0; i < keys.length; i++) {
  stmt.setInt(i + 1, a.get(keys[i]));
}
...

で、これにどういう意味があるんですか？ Integerのインスタンスをかます分だけ効率も悪いし、GCの頻度が増すのでストレステストになるということですか？ −それは一理あるが、今、問題にしているのは、この1000行もあるアホウなメソッドをどうにかしろ、ということなんだ。でも、まあ、mapを使うのはこの場合、意味なさすぎだな。それじゃ

class A {
  private int[] vals;
  public int get(int idx) { return vals[idx]; }
  public int size() { return vals.length; }
}
...
for (int i = 0, n = a.size(); i < n; i++) {
  stmt.setInt(i + 1, a.get(i));
}

ならどうだ？ −でも、これだと、たとえばインデックス32がAのどのような属性かさーぱりわからないんですが。やっぱり、ちゃんとゲッタを定義したほうがいいと思います。−面倒なヤツだな。じゃあ、これならどうだ？

class A {
  private int[] vals;
  public int get(int index) { return vals[index]; }
  public int size() { return vals.length; }
  ...
  public int getA32() { return vals[32]; }
  ...
}

あのぁ、ここにvals[32]というマジックナンバーがあるんですけど。マジックナンバーは書いてはいけないということも知らないんですか？ 私なら

class A {
  private int[] vals;
  ...
  static final int A1 = 0;
  ...
  static final int A32 = 31;
  ...
  public int getA32() { return vals[A32]; }
  ...
}

としますが、何か？ −なるほどねぇ。そういうふうにプログラムを記述してれば、そりゃ、テストプログラムを作ったり、リファクタリングする暇は無いだろうねぇ。
#でも、結局、更新対象カラム数が多ければ多いほど致命的に遅くなることが判明して、

StringBuffer s = new StringBuffer("update ... set ");
for (int i = 0; i < a.size(); i++) {
  if (a.get(i) != 0) {
    s.append("A").append(i + 1).append("=A").append(i + 1).append("+?,");
  }
}
...
int col = 1;
for (int i = 0; i < a.size(); i++) {
  if (a.get(i) != 0) {
    stmt.setInt(col++, a.get(i));
  }
}
...

となったりして。