dry runできるバッチづくり

設計

dry run（ドライラン）で、データの書き換えをしないでバッチの動作確認をしたい！

どうする

例。
契約に対して状態ごとに値引きするバッチを考える。

初めて動かす時とかは

  • 割引処理対象者は誰か
  • いくら値引きするのか

などが正しく判定できているか、知りたくなると思う。
でも普通に動かすとデータが書き換わってしまう。

  • 永続化される直前の状態が知りたい
  • でも永続化はしてほしくない

→これを確認できるように、「ドライラン」できるメソッドを用意する。

イメージ

たとえばservice層でやることを以下の3つに分ける。
1. 各種リポジトリを呼んで、業務に必要なドメインを集める。
2. ドメインサービスを呼ぶ。ドメインサービスは1で集めたいろんなドメインを使って業務的な処理をする。
（ドメインサービスはドメイン層なので、リポジトリは原則呼ばない。）
3. データソース層呼ぶ。永続化。

DiscountApService.java

...
public void run(Id id) {
  // 1.ドメイン集める
  Engagement engagement = engagementRepository.find(id);
  DiscountInfo discountInfo = discountRepository.find(id);
  // 2.集めたドメインをサービスに渡す
  DiscountEvent event = DiscountService.judge(engagement, discountInfo);
  // 3. 処理結果を永続化する
  save(discountInfo, id);
  sendMail(discountInfo, id);
}

// ドライラン
public DiscountEvent dryRun(Id id) {
  // 1.ドメイン集める
  Engagement engagement = engagementRepository.find(id);
  DiscountInfo discountInfo = discountRepository.find(id);
  // 2.集めたドメインをサービスに渡す
  DiscountEvent event = DiscountService.judge(engagement, discountInfo);
  // x.永続化はしないで処理結果を返す
  return event;
}
...

こんなかんじのイメージ
1と2だけをやるメソッドをドライラン用に作っておけば、本番環境でもデータを書き換えず、安全に動作確認ができる。

参考

blog.isyumi.net

try catchするときはなんでもcatchしてはいけない

before

public boolean tryHoge() {
    try {
        // 例外が起きそうな処理; HogeExceptionかFugaExceptionが想定される
        return true;
    } catch (Exception e) {
        return false;
    }
    return false;
}

たとえばこのとき例外が起きそうな処理の中でNullPointerExceptionがあっても知らずにcatchしてしまう。

after

public boolean tryHoge() {
    try {
        // 例外が起きそうな処理; HogeExceptionかFugaExceptionが想定される
        return true;
    } catch (HogeException | FugaException e) {
        return false;
    }
    return false;
}

予想してない例外までcatchしてしまわないように、catchするものはなるべく少なくする。

コードが書けない問題

雑記

（ただ愚痴を書く）

モデルや設計をコードに落とせないのと
アルゴリズムができないのがあるっぽい

外部設計つくったぞー全体の構成考えたぞー
からすぐコード書いてるからだめなのかな？
設計をコードに落とせないのは過程が足りていない。
クラス図書けばいいのかな？明日はクラス図書こうかな

アルゴリズムできない問題 知ってた
元々できない 数学キライとおなじ気持ち
いつもprintしながら思い通りの結果になるまで勘で書いてる
ていうか動けばいいじゃん？ていう気持ちいまだにある
設計がきたないとイライラするけどコードはやっぱりよくわかんない、きれいなコードってなんだ
コードがきれいになる楽しさが腑に落ちない たしかに読みにくいのは嫌だけど…

設計は自分ならこう作るぞ〜って考えるのたのしいしきれいにできたらハッピーだし、人が違う考え方してたらそれを聞くのもおもしろいと思うけど、コード書く楽しさって集中してものつくってテスト通ったら満足 みたいな


自分のことだから実践しながら学ぶしかないだろうと思うんだけどそんな休みの日までコード書く熱心なひとでもないわけで……

画像をすり替えるjavascript

雑記

同期が珍しくjavascriptやって遊んでいたので。

$("img").hover(function(){
    $(this).attr('src', '任意の画像URL');
});

hoverした画像がぜんぶ同期の顔（社内チャットのアイコン）に変わるコードあげた。
同期の周りでウケた、のはいいけど盛り上がりすぎてウイルスとまで呼ばれたらしい。
人聞きが悪い！

コードが書けない時はまず日本語を書く

開発

設計できたけどこれをコードにどう書こう？ってなったとき、ユースケース記述を書いてみたら良いよと教えてもらった。

ユースケース記述ってなんぞ

参考にしたのはこのあたり
it-koala.com

いろいろ項目あって大変なので、アレンジして以下の項目を基準に書いてる。

実際書くとこういうかんじになる。今回はバッチ処理のイメージ。

  • ユースケース名：契約開始
  • 概要：申込済みユーザの契約開始処理をする
  • 処理対象：契約開始可能な申込済みユーザ
    • 前日までに申込がされている
    • 支払方法が確定している
  • 基本フロー：契約開始可能な申込に対して以下の処理をする
    • ユーザの状態を契約済みに遷移
    • 契約開始イベント作成
    • 課金開始イベント作成
    • 課金システムへ契約開始連携
  • 結果：
    • 契約済みユーザ
    • 契約開始イベント
    • 課金開始イベント

で、これをそのままコードにする。
処理対象の「契約開始可能な申込」のドメインを作って、条件判定のロジックを書く。
サービス作って、フローを順に書いていく。
テストのインプットは処理対象で、期待値は結果になる。

本当はドメインモデルからクラス図とかを書くほうが良いのかもしれないけど、ツールに引っ張られずに素直に考える手段として「日本語で書く」というのが結構しっくりきたので、しばらくやってみる。

設計資料とデザインレビュー

開発

デザインレビューにあたって、評価項目にBD、FDとか書いてあるけど、略語の意味すらわからなかったので調べて頭を整理する
おもに設計プロセスと品質担保について

デザインレビューの要項にこんなん書いてある

要求仕様をもとにBDする
BDをもとにFDする

これなん

BD = 基本設計
FD = 機能設計
とのこと。
システム開発各段階の用語について - 桂乃屋

それぞれ何書くの

外部設計と内部設計だったら

  • 外部設計：システムの外と関わる部分
  • 内部設計：その内側を書く

という違いなのはわかるけど、じゃあ基本設計と機能設計（と詳細設計）ってなにか。

基本/詳細設計って呼び方やめませんか - Qiita
システム設計の流れ - Qiita

  • 基本設計はユーザから見て理解できるような内容
  • 機能設計は基本設計の一部
    • 機能設計はロジック、DB、バッチの設計など、各モジュールの外部仕様（= API単位の外部設計っぽい）
  • 詳細設計はその中に閉じた部分のより詳細な設計=内部設計で良さそう

要求仕様をもとにBDする
BDをもとにFDする

は

input: 要求仕様 → output: 外部仕様書
input: 外部仕様書 → output: 内部設計資料

これをうちで作ってるもので言うと
要求仕様 = サービス仕様書
外部仕様書 =

  • コンポ図（外部システムとの関連を表現）
  • 外部システムのIFの項目と内部データ項目の紐付け
  • 非機能要件

内部設計資料 =

  • クラス図
  • シーケンス図 とか

ドメインモデル
ドメインは外部と話すための言葉だけど、モデルで書いてることは内部か…

テスト設計も

BD仕様書をもとにSTする
FD仕様書をもとにFTする

外部設計を担保するST
内部設計を担保するFT

STは外部システムとの結合を確認しなければいけない
というかそこの確認さえできてれば良いよね
結合する部分について各ユースケースに対応するin/outのデータが網羅できていればOKではないか

結局デザインレビューはなにをみるのか

サービス仕様→外部仕様書→内部設計
外部仕様書→ST
内部設計→FT
このロジックが飛んでいないか、抜け漏れがないかを見てもらえればよいのでは、と、おもいます。
（これはサービス仕様が頭に入っていて、内部設計を理解できる人に見てもらうのが良さそうですね）
結局ただのV字モデルのはなしっぽい うーん

なんか書く

雑記

ブログ復活

新年なので今年の抱負を考えていたのですが、今年はブログを書こうということになりました。
エンジニアなのでほんとうは技術系ブログをやると言いたいのですが、絶対に続かない自信があるので言いません。だから油断したらアイドルオタクのブログになるかもしれない。正直ちょっとありかも。
あなたは自分が書いた過去のブログ記事を読み返して悦に入る趣味を持っているだろうか。この記事めちゃくちゃ良いこと言ってるな……誰が書いたんだ……？自分だーーー！！！最高！！などと一人で騒ぎ立てる茶番を何度でもやれるメンタルを持っているだろうか。わたしは持っている。
わたしはわたしが書くブログのことがめちゃくちゃ好きなので、今年は自分が読んで楽しめるブログを書いて、年末くらいにまとめて読み返してハッピーな気持ちになりたいと思います。よろしくお願いします。

次の目標は次の記事を年内に書くことです。・ｘ・