試してみた

適当にH2databaseを使用した

BBBB_CODEテーブルがマスターテーブル,AAAAが対象のテーブルとしたらこんな感じで定義

    • BBBB_CODEテーブルの定義

CREATE TABLE BBBB_CODE(
BBBB_ID INT NOT NULL
,BBBB_CODE VARCHAR(20) NOT NULL
,BBBB_CODE_NAME VARCHAR(50) NOT NULL
,DESCRIPTION VARCHAR(50) NULL
,PRIMARY KEY (BBBB_ID)
);

    • BBBB_CODEにレコードをインサート

INSERT INTO BBBB_CODE(BBBB_ID , BBBB_CODE , BBBB_CODE_NAME )values(1,'0000','未入力');

    • AAAAテーブルの定義

CREATE TABLE AAAA(
AAAA_ID INT NOT NULL
,BBBB_ID INT NOT NULL DEFAULT (SELECT BBBB_ID FROM BBBB_CODE WHERE BBBB_CODE.BBBB_CODE_NAME = '未入力')
,DESCRIPTION VARCHAR(50) NULL
,PRIMARY KEY (AAAA_ID)
);


インサートしてみる

INSERT INTO AAAA (AAAA_ID)values(1);

で、中身を確認

select * FROM AAAA;
AAAA_ID BBBB_ID DESCRIPTION
1 1 null
(1 行, 2 ms)

入ってる

アノテーションはさ・・・

なので、アノテーション自体はこんな感じで定義。

interface @UsecaseGroup{
  Iユースケース value();
}

そしたら、コンパイルエラーになるのね・・・
インタフェイスは、メンバ・アノテーションに設定できないから。

使えない・・・

いいアイデアないですかねぇ・・・

そんな時にさ・・・

ユースケースを超えてセッション情報を破棄するような感じで処理を組みたいってことで、UsecaseGroupってアノテーションを作って指定させてみたの。それが、こんな感じ。

@UsecaseGroup(発注.仕入れ先を追加する)
public class 仕入れ先を追加するUsecase {
  public 登録Form 初期表示(){
    ・・・
  }
  public 登録済みForm 仕入れ先を追加する(){
    ・・・
  }
  ・・・

}

こんな風に書いていきたいのね

で、インタフェイスは実装できる。

そこで、イロイロ調べていたら、インタフェイスは実装できることが分かったので実装してみた。

public enum 発注 implements Iユースケース {
  仕入れ先を追加する, 仕入れる
}

おー、コンパイルエラーが消えた。

まず、enumは継承できないんだよねって話

こんな感じで、ユースケースenumとして管理したいと・・・

public enum 発注 extends Abstractユースケース {
  仕入れ先を追加する, 仕入れる
}
public enum 経理 extends Abstractユースケース {
  お金を支払う, お金を受け取る
}

当然、enumは継承できないから、コンパイルエラーになる。

レビュー

自分の置かれている場所の空気感が最近変わってきているので、文章に残しておいてみようと考えて、久しぶりにblogを更新してみます。それは自分を置いている場所のせいなのか、時代のせいなのかはわかりません。
おそらく、そのどちらもでしょう。

自信の無さ

ここ数年、自分に自信がありません。
自分のしている事に自信が持てないのです。ともかく、不安なのです。
何か自分のダメな点が分かれば不安も解消できるのかもしれませんが、どこがダメなのかも判りません。

これは、自分に対してだけではなく、他人に対しても同じです。すべての物が信用できないのです。

できるだけ多くのテストを早いタイミングでしたい。テストがNGであれば、ジャッジをして、必要なら早い段階で対策をしたい。その様に考えるようになっています。

ともかく、早いフィードバックが欲しいのです。

問題点

多人数参加のレビューで見直すなんて効率的ではない。大量の人数が参加するレビューでの、意味のない日本語向上の指摘など、反吐が出る。レビュー後に、レビュアーの言う、「すこしぐらい日本語として読めるドキュメントを書いてほしい」とかいう、愚痴もイライラする。低レベルだと思う。
はっきり言って、ドキュメント記述者の中には日本語弱者の人もいる。そんなの、査読をできる人が事前に、推敲してもいいんじゃない?そんなアイデアも出ないってことだよね。原因はうっかりではなくて、体制的な問題だよね。レビューイ個人に責任を押し付けて、瞬間的に楽をしているだけだよね。
レビューを楽に進めるのは、効率よくレビューして品質を上げること。日本語の些末なことを高い技術力を持った人が行って、問題点として上げられない。レビューイがウッカリしてたっていう原因にすること自体が、問題。そもそも、「レビュー」は言葉の意味は「見直し」だろ。

じゃあさ

レビューアーは、上段からレビューイを責めるんじゃなくて、もっとレビューによって品質をあげるのに邪魔になっていることに真剣に立ち向かってほしい。無責任だと思います。

レビューアーは、さぞかし経験を積んで、メカのようにミスをしない方々なのかもしれない。しかし、レビューイは人間的でミスをする人だと考える余裕をもって欲しい。日本語品質が悪くて、レビューアーが成果物を効率的にレビューできないなら、レビュー前に推敲を提案して欲しい。レビューという作業が、効率的に行われるように立ち向かってほしい。日本語弱いという記録は数字として現われてきていると思う。

一方でレビューイは、自分がレビューしてもらいたい部分をレビューしてもらえないなら、程度が低いことを認識すべきだ。レビュー対象物の日本語レベルが低く、技術的なレビューを受けられないドキュメントであると理解すべきだ。日本語レベルが低いから見直してほしい。技術的なレベルが低いから見直してほしい。それぞれを効率的に行えるように提案するべきだ。それが、結果的に短い期間の最適化にはつながる。

ボトムアップからは、こういうアプローチしかないのかもしれない。

ビィジョンに向けた戦略、戦術をみんなでとっていかないと、ダメなんじゃないかな。ダメなビジョン、戦略はあると思うけど、そんなレベルの問題を正攻法で攻めたり、責めても無駄で、正しいと思う方向にみんなが動かしていくために、どうしたらイイかを考えて動こうよという事。愚痴を言っていても、何も変わらない。
戦略のミスやビジョンのミスを正せる人は、正せばいいし、戦術のミスを正せる人は正せばいい。それすらできない人は、部分最適や、戦術ミスに気がつかせるにはどのように動くかを考えていったらいいと思う。