TWBMT

技術的な記事や覚書について書いていきます。その内、自作サイトとかに技術記事をまとめたい。

RDRA 2.0 ハンドブックを読んでみた。

3連休にRDRA 2.0 ハンドブック を読んだのでさくっと感想を。

結論的にはとても読んで良かったな〜と思っている。

RDRA 2.0 とは

著者の神崎善司さんが考案されたリレーションシップ駆動要求分析(Relationship Driven Requirement Analysis )という要求分析・要件定義を行う為の手法のこと。

要求・ステークホルダーを起点に複数のダイアグラムを作成して作っていくことで、開発に必要な概念やユースケースを洗い出していくことが出来る。

一番の大きな特徴は、全てのダイアグラムと構成要素の関係性が明示されている・できること、かな。

詳しい解説をしてしまうと本を買う意味が薄れてしまうどころか著作権とかアレだと思うので詳細については割愛。
(キーワード検索で引っかかる情報にあんまり良いものがなかったので、もし興味があれば800円でこの本を買ってしまったほうが良いかも。)

読んだ感想

出てくる知識や考え方がDDDやモデリングの考え方に似ていて、1〜2日でサクッと読むことが出来た。
そもそも要件定義のプロセスや洗い出すべきことを構造化したものが RDRA だと思うし、DDD もモデリングもシステム化する対象をどう構造化して落とし込もうかということだと思うので、やりたいこともやり方も似通ってくるんだろうと思った。

ちなみに、こちらの動画で実際にRDRAで作成したダイアグラムと実際の実装を紐付けて開発している事例が発表されている。
RDRA で洗い出した業務・ユースケースや情報・状態の関係をそのまま

業務 > ドメイン境界  
ユースケース > ユースケースサービス  
情報・状態 > ドメインモデルなど  

の様にパッケージングやクラス構成などに対応させて開発しているとのこと。

「あ〜、これこれ、こういうイメージ〜!実際に実装に対してマッピング出来るんだ!」と感動したので、本書と合わせて是非この動画もオススメしたい。
RDRA は実装に踏み込みすぎない様に意識されているので、実際には実装との乖離は発生すると思うが、良い感じに開発できるイメージが湧いた。

www.youtube.com

  • 要件定義の全体像を学べた。

(本書が本来意図したことではないと思うけど)書き出してしまうと当たり前の、

「要求 > 業務 > 業務フロー > ユースケース > 関連するデータモデル」

の様な要件定義全体の構造と各概念の関係性を俯瞰して体系的に学ぶことができた。
これが出来るのは要求を基に必要な情報を洗い出すプロセスが構造化された RDRA だからこそな気がする。

元々、要件定義プロセスについて体系的に学んだことがなかったので、これだけでも読む価値があったと思う。読んで良かったな〜。

  • (語弊があるが)自分でも出来そうだと思った。

本の中に書いていることをまとめると、大まかに以下のようなことが書いてある。

// 詳細を抜き出した状態の読書メモ

# RDRA の説明
- RDRA 全体のプロセスの説明、ダイアグラム間の関係

# 各ダイアグラムの説明
- {各ダイアグラム}
  - 概要
    - {ダイアグラムの概要}
  - 目的
    - {ダイアグラムで要求分析・要件定義上で合意・確認したいこと}
  - ダイアグラムの詳細
    - 構成要素
      - {ダイアグラムを構成する要素}
    - ゴール
      - 書くべきこと
        - {ダイアグラムに書くべきこと}
      - 書きたくないこと
        - {ダイアグラムに書きたくないこと、書かなくても良いこと}
    - 作り方
        - {実際の HOW の部分}
# RDRA の精度を上げるには
- 整合性、網羅性、妥当性を担保する方法

こうして一覧してみると、プロセス全体が構造化されているが故に「書くべきこと・考えるべきこと・正当性の検証方法」まで一通り定義してくれていると思う。
なので、大前提として細部にセンスや専門知識・練度が必要だけど「この軸に沿って考えていけば、そうそう外れたことはしなさそうだな〜」とも思ったし、「これならできそうだし、やってみたいな〜」と思えた。
機会があればやってみたい。

  • 自分のねらいは間違ってなかったっぽい。 「キレイなコード、キレイなアーキテクチャはそもそもドメインから産まれる」とアタリをつけて、モデリングや要件定義や何らか業務知識に繋がる本を読み進めているけど、間違ってなかったな〜と思えたし、改めてそうだなぁと気づけた。
    引き続き、頑張ろ〜。

まとめ

読んで良かった。

お求めやすい価格(kindle版:800円)且つモデリングアーキテクチャ周りの知識があるとすんなりと受け入れられるので、興味ある方にはオススメですね。

未経験から4年目に至るまでに読んだ本・やったことをまとめてみた

自分が未経験の頃から今までの間に読んだ本を列挙してみました。

いわば、自分がエンジニアになるまでにやってきたことの足跡の様な感じです。

「これからエンジニアやっていくぜ!」って方と出会って「やっていこうぜ!!」って話すことが多いのですが、そういった人向けの参考になればなと。 ここに載せた本は全部、自分がコードを書ける様になったり、作業の質が上がったりしたキッカケの本です。

バックボーン

文系卒で心理学・社会学系を触っていました(学んだとは口が裂けても言えない。)
比較的、数学が好きだったので元々の適正や素養自体はあったかもしれませんが、プログラミング経験は皆無です。

ただ、エンジニアになるとは微塵の「み」も思ってませんでした。

未経験期

prog-8.com

progate でコードを書くのに慣れつつ、ITパスポートを勉強して良い感じにIT系の言葉を知るっていう感じでしたね。

仕事でお供したことがある方が「新人はまず言葉に慣れることが大事」と教えてくださっていて、今振り返ると丁度それを独学でやっていたのかなと思いました。 たまたまですが、今振り返るとわりとスジの良い入り方でしたね。

progate も IT パスポートも「これで〇〇が出来るようになりました!!」ということは無いけど、最初に取り組んでいたからこそ色々なことに抵抗無く取り組むことが出来たので、もしもこれからエンジニア興味あるかもって人は触れてみると良いかもしれません。

1年目

懐かしの研修期間。

angular.io

しこたまインプレス社にお世話になりましたね。 研修受けて、ガガガッと Java について勉強して、java silver 取って〜みたいな感じでした。

とにもかくにもプログラミング言語が書けるように〜〜!!って感じ。

「常識として知っておきたいプログラムのしくみ」は当時お金がなかったので図書館で勉強できる本を探そうと思って手に取った本でした。

僕はどうにも配列や文字列の振る舞いが理解できなくて詰まっていたのですが、この本を通してメモリレベルの話の概要を知ることでようやく理解する事が出来たので読んで良かったと思っています。

本にコーヒーこぼして、図書館に新品買って返したところまで良い思い出。

後は Angular と出会ったのもこの時期ですね。 大事なことは全て Angular から学びました。バイブルですね。

2~3年目

2年目はあんまり本呼んでなくて、ひたすら Angular 周りの記事やフロントエンドのアーキテクチャについて調べてました。 しこたま lacolaco さんや 奥野さんのスライドを読み漁ったりなんだり。

ただ、その少ない読んだ本の中でもかなり重要なのはプリンシプルオブプログラミングとTDDの本ですね。 特にTDDを知ってから本当にコードの書き方・考え方・仕事の仕方が変わりました。
個人的なおすすめ度で言うと、ナンバーワンかもしれない。

TDD は一つのスキル・コーディングスタイルだと思うので、コーディングに悩む人は一度手にとって見ると良いと思っています。 TDDに限らず xxxx駆動開発系のワードは開発プロセス全体の事の様に思われがちかもしれないけど、実際はシステム開発する上での一つの方法論・スキルだと思っていて、日頃の仕事に活かせる考え方や技術がいくつもあるのでハマってみるとおすすめです。

4 年目

これは直近読んだ本の羅列ですね。。。笑

little-hands.booth.pm

DDD 関係の本ばっかりですね。

DDD をやってみたい!!というよりは自分にとって一番興味が持てて且つ有用な知識のありそうな分野だったので、ガッツリ読みまくっていこうかなとスタイル。

(僕もわかっていないので観測範囲の認識ですが)DDD 界隈をウォッチしていると色々ありますが、そもそも根幹にある「ドメインに目を向けてよう」っていうことはソフトウェア開発における一番普遍的なことなので触ってみると良いかなぁと思っています。 なので、値オブジェクトやエンティティは開発の How の部分で、実際に適用するかどうかはケースバイケースだと思います。

とにもかくにも、興味駆動でガンガン読んで、その中で普遍的なことや応用の効く考え方をたくさん読んでいけたら良いなと。

その他

話の流れ的にここに持ってきたのですが、フロントエンドエンジニアとして、もちろんこの辺も読んでました。 デザインの4原則あたりの知識は、最低限の教養として押さえると良いことだと思っています。

後、この辺の本とかも。 意味がわかって実践できるようになりつつあるのが最近なので大変恥ずかしいですが、それでも当時読んで自分の行動改善が進んだので一応ご紹介。

まとめ:振り返りとこれから

改めて振り返ると今の自分がどう出来上がってきたのかが俯瞰出来て良いですね。 まだまだ道半ばなのですが、こうやって振り返ると色々勉強したし、スタート地点からはだいぶ遠いところに来たな〜〜〜

ネットワーク・サーバー・インフラ周りは知識薄いし、アルゴリズムも激弱で課題だらけっすけど、興味持てるところで強み持っていきたいかなぁ。

この記事が何らか道標や参考になればな〜とか、話のネタになればな〜と思いつつ、今後も頑張っていきたいですね。

『事業分析・データ設計のためのモデル作成技術入門』を読んだ感想

『事業分析・データ設計のためのモデル作成技術入門』を読み終わった。

元々、フロントエンド・小規模のアプリ開発からエンジニアキャリアをスタートして今日に至るので、どうにも「モデリング」の様なレイヤーの話に疎く、衝動買い基礎的な知識を学ぶ為に購入。

結論から言うと、自分から読みたいと思うぐらいに面白い内容で、非常に読んで良かったと感じている。

デファクトスタンダードなやり方ではないのは承知だが)
数学の理論や手続きに則って「誰がやっても同じモデル図が出来る方法論・技術」がまとまっていた。

以下、簡単な感想をつらつらと。

徹頭徹尾、数学の話だった。

本の中ではいわゆる Entity という言葉が出てこなく、全て集合や元など数学に基づいた考えに基づいてモデル分析をしていく手法がまとめられていた。

大まかには以下の通りの様な話が展開されている。

  • 事業上登場する事柄は全てモノ(事態・事物)として扱う
  • 事業活動は5種類に分類され、それに対応する5種類の管理業務がある
  • 管理業務上、管理したい事柄には必ず識別子が存在する
  • その識別子ごとに正規化したモノを作り、Event(日付を基に並べることができるもの)Resource(辞書的な規則に則って並べられるモノ)に分類する
  • それぞれのモノの関係を基に文法・論理規則に当てはめて成り立つかどうかを関係論理に基づいて図式化していく(合わせて、実務に合わせた知識・補足がされている)

完全に定義・概念・計算方式が確立されていてモデルの作成にエンジニアの解釈が必要無く、誰がやっても同じモデル図になるとのことだった。
また、曰く出来上がったモデル図はそのまま DB 設計に置き換えても動くとのこと
(INDEX ONLY, ADD ONLY で DB 作成する。著者の経験+観測範囲ではパフォーマンス問題に出会ったことがないらしい。)

これだけ聞くと魔法の様な話だが、実際にその関係式が充足されるのか否かを判断・判定する必要があるから完全に属人性が排除される訳ではない。実際の業務知識が無いと正しい図は作れない。 それに補助資料も多いので相応のコストもかかる印象だった。

ただ、この本に書いてある知識・考え方は普遍的なものだと思うし、直接この方法で分析・設計を行わずとも役に立つ知識だったなぁと思う。 (迷惑かからない小規模アプリを作ることがあれば、試してみたいなと思う。)

「構文論が先で意味論が後」

上記の数学の話と被るが、書籍の中で繰り返される「構文論が先で意味論が後」という話が凄く印象的だった。

まず「文法・論理規則・関係(関数)として正しいか否か 」が常にあり、「真とされる値が本当に充足されるかどうか。」は後から判断する、という話。

例えば、R(受注, 発注) の関係は支払い請求、R(発注、受注)は先払い、R(受注, 発注) も R(発注、受注)も論理的には成り立つけど事業上存在するかは別な話だよね、という感じ。

本当に知識ゼロと言っていいぐらいの身としては、これぐらい形式だった手法を学べるのはありがたいなぁと思った。

事実:情報は1:N、情報:モデルはN:1

数学の写像の話に基づいた説明をされて「なるほど」となった。

1:N 関係は関数(写像)にできないけど、N:1関係は関数に直せる、という話。

今よりももっと何も知らなかった頃は「Entityって実体だよな、実体を1:1に表す、、、訳ではないけど、どう解釈すれば良いんだ?」という疑問が絶えなかったので、ようやく一番論理的な理解が得られた。

そもそも「Entity は ID を基に同一性を判断できるオブジェクト」って定義でもあると思うので、改めて全然とんちんかんな疑問を抱いていたなぁとも気づいたり。

総じて自分は相性が良かったし、相性が良さそうな人にはオススメ

繰り返しになるが、DB の設計手法として使うかは別として、モデリングや事業分析の為の普遍的な考え方・基礎知識を学べる書籍として本当に良かった。
色々とモデリングに対する誤解が解けたり、正しい知識が得られたと思う。
もう一週ぐらい読み直して、自分に定着させたい。

また、相性が良くない人は全然受け付けないと思うが、相性の良さそうな人は凄くしっくりくると思うので是非オススメしたい。
ところどころ、数学や哲学、ないしはコッド先生の話など歴史の話題が多かったり、今の手法にたどり着くまでの悩みなどもあるが、その辺りの癖を掴むと非常に読みやすいと思うのでご興味ある方はご参考までにどうぞ。

Container / Presentational Pattern について

Container / Presentational パターンはコンポーネント設計や責務分担を考える時に役立つデザインパターンだと思います。
フロントエンド始めたての方なんかは是非学んで欲しいパターンだなぁと。

なので、最初に自分が理解する為に呼んだ記事や勘所等をまとめたいと思います。

Container / Presentational パターンとは

概要

コンポーネントを以下の2種類に分類して実装するパターンのこと

  1. Container Component
    振る舞いに関する関心を集めたコンポーネント

  2. Presentational Component
    見た目に関する関心を集めたコンポーネント

...と言われても、こういう概念はサンプルコードが無いと意味がわからないと思います。
なので、イメージを掴みやすいように参考例を作成してみました。

サンプルコード

個人的に一番わかり易い事例はモーダルダイアログだと思います。

仮に「外部APIから取得したデータを表示する」「送信ボタンを押した際にAPIへ何らかの値を送信する」 という処理を持ったモーダルダイアログがあるとします。
その時、もしもモーダルダイアログに全ての処理を実装すると以下の様になってしまいます。

const ModalDIalogComponent = () => {
  const [content, setContent] = useState();
  useEffect(() => {
    /*
      外部APIから表示する値を取得する
      const val: any = "何らかの値";
      setContent(val)
     */
  },[])
  const onSubmit = useCallback(() => {
    /*
     * APIの送信処理など
     */
  },[])

  return (
    <div  className={"モーダルダイアログに関するCSSクラス"}>
      <span>
        {props.content}
      </span>
      <button onClick={onSubmit}>送信</button>
    </div>
  )
}

かなりツッコミどころのある事例ですが、これが「見た目に関するロジックと振る舞いに関するロジックが混在している状態」です。

今、このコンポーネントには「モーダルダイアログのスタイリング」「データを取得する処理」「APIを送信する処理」などが記述されています。
API を送信する処理は見た目に関係ありませんし、データを取得する処理自体は直接見た目に関係しているわけではありません。

なので、このコンポーネントから見た目に関するロジック以外を取り出し、親コンポーネントに処理を委譲してみます。

type Props = {
  content: string;
  onSubmit: () => void;
}
const ModalDIalogComponent = (props:Props) => {
  return (
    <div className={"モーダルダイアログに関するCSSクラス"}>
      <span>
        {props.content}
      </span>
      <button onClick={props.onSubmit}>送信</button>
    </div>
  )
}

const PageComponent = () => {
  const [content, setContent] = useState();
  useEffect(() => {
    /*
      APIやLocalStorageから表示する値を取得する
      const val: any = "何らかの値";
      setContent(val)
     */
  },[])
  const onSubmit = useCallback(() => {
    /*
     * APIの送信処理など
     */
  },[])

  return (
    < ModalDIalogComponent content={content} onSubmit={onSubmit}></ModalDIalogComponent>
  )
}

モーダルダイアログ側のコンポーネントは親コンポーネントから受け取った値を表示し、受け取ったコールバック関数を実行するだけのコンポーネントになりました。

元の状態の場合、別な API から値を取得したくなった時、類似のコンポーネントを作るか、モーダルダイアログを拡張する必要があります。
しかし、親コンポーネントから受け取る props に応じて振る舞いを変更できる様にすることで、そのまま再利用することが出来るようになりました。

こうして「見た目に関するロジック」「振る舞いに関するロジック」の観点でコンポーネントを分割するパターンをContainer / Presentational パターンと言います。

理解する為の勘所

僕がこのパターンを理解する為に必要だった勘所が2個ありまして、それぞれまとめていきます。

Pure Container よりも Pure Presentational を意識する

完全にロジックしか持たないピュアな Container Component よりも 完全に見た目に関するロジックしか持たないピュアな Presentational Component を目指してみると理解が捗ると思います。

二分割する一方のみに注視した方がわかりやすいですし、ロジックの複雑さ的にも Presentational 側の方がわかりやすいです。

なので、最初は大きい粒度でコンポーネントを作り「ここ共通化出来るかもな〜」「流石にコンポーネントが大きくなってきたな〜」と感じ始めた時にコンポーネントを切り分けていく内に、自然と Container / Presentational な関係になります。

また、最初からキレイに分割することは難度が高い上に、早過ぎる最適化になりやすく、無駄にもなりかねません。
デザインや仕様が固まりきっていない内は無理にチャレンジしないほうが得策かなぁと思います。

とどのつまり「責務分担」

そもそも「見た目と振る舞いに関する関心をわけること」とはすなわち「責務分担を考えること」ということです。
このパターンの名付け親の Dun 氏も「Reactを長くやっているのであればおそらく既に発見していることでしょう」と述べています。
なので、恐らく多くの開発者がコンポーネントを分割するにあたって責務を考えた時に自然に辿り着く様なことだと思います。

というわけで、そもそもそのコンポーネントが行うべき処理や責任範囲を考えて分類してみよう、という観点でもう一度見つめ直してみるとしっくり来ると思います。

で、何が嬉しいの?

ざっくり箇条書きにすると、

  • 可読性の向上
  • テスト容易性の向上
  • Storybook の導入のしやすさ
  • etc...

といった感じかなぁと思います。

とどのつまり「責務を考えよう」というお話なので、コーディングスキルの向上やテスト容易性の向上に繋がるのかなぁと。 後は、特に Storybook なんかを使いたい時は、チームの共通認識として持っておかないと破綻しかねないかなぁと思います。

あとがき

というわけで、Container / Presentational Pattern についてまとめました。
少し古いかもしれませんが、自分の理解の言語化+ちょこちょこReact教えて!みたいな話されるので説明用の資料になれば良いなぁという感じですね。

後、書いていて思ったことですが、フロントエンドに入門して一番興味が湧くことの一つがコンポーネントの分け方だと思うので、そこに責務分担を絡めて学べたらゆくゆくの成長に繋がったりするのかなぁと。
なので、やっぱり基本的な考え方として抑えておくことは今からでも結構、有用なのかなぁと思います。

余談:初出

Redux 作者の Dan Abramov 氏の記事が初出です。(調べる限りは間違いないはず。)

medium.com

著者本人は「Hooks の登場によって必ずしもこのパターンが最適ではなくなった。コードベースで自然だとわかった時は便利なパターンではある。」(意訳)としています。
また、記事の締めで「このパターンを dogma (教義) としないで」とも述べていて、この2つのコンポーネントは必ずキレイに分かれるものではなく、分割が難しい場合もあるとつけくわえています。

参考リンク

コンテナ・プレゼンテーションパターン|フロントエンドのデザインパターン

Container/Presentational Pattern

【覚書】お試しでスクショ自動化+ diff 比較(簡易VRT)をやってみた

目的

  • ビジュアルリグレッションテストに興味があった。
  • お試しでスクショ自動化と diff 比較をやってみたので振り返りと覚書をまとめる。

やったこと

  1. pupetter でローカルホストにアクセスしてスクショを撮る。
  2. lookSame で取ったスクショを比較する。
  3. 出来栄えを見て喜ぶ。

使用したライブラリ

puppeteer

Google 製のヘッドレス Chrome を操作するライブラリ。
類似ツールの Cypress 等との違いは、Google 製且つCDP (Chrome DevTools Protocol) 準拠の為、Chromeとの親和性が高いことが特徴。

github.com

looks-same

パット見使いやすそうだった為、採用。
github.com

わかったこと

  • 一度経験すればサクッと作れる様になりそう。
    • 実装量は少ない。かけた時間のほとんどが記法の調査だった。
    • もしも知識ゼロで作る場合、ハマりどころは「スクショしたい画面の描画を待つためにスリープ処理が必要」ぐらい。
    • 何か簡単なツールを作りたい時の心理的な抵抗感って数時間で済むような学習コストで減るんだなぁと体感。素振り大事。
  • もしも実運用する時に考慮することは以下の事が懸念事項かも。
    • スクショデータの管理と正解データの更新方法。
    • 差分検知をどれだけ厳密にするか。何故か puppettier のスクショにピクセル単位のズレが出る時があり、厳密にしすぎると落ち易すぎる印象。
    • どこまで画面を操作するか。操作数が増える = テストが壊れるリスクの増加 or メンテコストの増加。

ハマったこと

  • スクショ結果が不安定 同じ画面を同じ状態でスクショしていたにも関わらず、若干の差分やズレが発生した。 おそらく自身の端末の性能(最近、メモリの圧迫によって動作不安定。。)に起因していると思われる。

さじ加減が難しいが、looks-same が許容する差分の閾値を調整してOKということにして対応した。

次にやりたいこと

実装メモ・サンプルコード

コードのイメージを記載しました。 思ったよりも実装量が少ないことが伝われば良いなと。

トグルにまとめました。

スクショ自動化

実装したコードの一部。
puppeteer を起動して、ログインして、画面遷移してスクショするだけ。
全体で約100行ぐらいで、そんなに時間がかからなかった。

const main = async () => {
  const { page, browser } = await initPuppeteer();

  await login(page, {
    loginUrl: LOGIN_URL,
    username: USER_NAME,
    password: PASSWORD,
  });
  await screenShotPages(page);
  await browser.close();
};

const screenShotPages: (page: puppeteer.Page) => Promise<void> = async (
  page: puppeteer.Page
) => {
  for (const path of PATHS) {
    const url = `http://localhost:4200/${path.path}`;
    await page.goto(url);
    await sleep(12_000);
    await screenShot(page);
  }
};

diff 作成

実装したコードの一部。全体では大体120~150行ぐらい。
ファイルパスを渡すだけで比較・比較結果の画像を作成してくれる。
ファイル移動やディレクトリの存在チェックの方がよっぽど面倒だった。

// reference と current にファイルパスを渡すだけで比較してくれる。
function checkDiff(
  reference: string,
  current: string
): Promise<LooksSameResult> {
  return new Promise((resolve, reject) => {
    looksSame(
      reference,
      current,
      {
        tolerance,
      },
      (error, result) => {
        resolve(result);
      }
    );
  });
}

【はじめてのIT勉強会】「テストがキッカケで成長した」というLTをしてみた。

先日のはじめてのIT勉強会のLTで発表した内容をブログにしたものです。

この記事で書くこと

  • はじめてのIT勉強会でLTしてきた感想
  • 久しぶりのオフライン勉強会の感想

発表スライド

発表用のイラストなどを少し減らしています。

LT の意図

  • プログラマーとしてのコードの悩みが減った自分の体験をシェアしたい。
  • 文卒・未経験の人が成長する一つのケースとしてシェアしたい。

自分の実体験

コードが書ける様になると「どう書けばよいか」「何を正しいのか」に悩むことになるものだと思います。
特に自分の場合「何が正しいコードであるか判断する基準」を作れなくて、実装の手が止まることが多かったですね。

色々試してみていてRealworld Example (様々なフレームワークで実装されているサンプルアプリ)AWS Amplify の npm ライブラリの実装をかいつまんで読んでは自分なりの実装パターンを身に着けたりしていったのですが、
グッとレベル感が上がったのはテストコードを学んで実践した時でした。

(逆にあんまり考えてない時は成長していなかったですね。その分は伸びしろということにしましょう。)

「テストしやすさ」にはベストプラクティスが詰まっていて、テストしやすいコードには一定の正しさが存在しています。
なので、テストコードと向き合ったことが一つ壁を破れたキッカケだったと思いますし、それを今回は一つの体験談としてシェア出来ればなぁという次第でした。
テストコードを書ける職場で無くとも是非、調べてみてください。

若手・中堅の人のモチベや成長の一助になれば幸いだなぁと思います。
質とスピードは比例しますし、良いコードを書けることには価値があると思うので、やっていきましょう。

余談

「好きな話させてもらうし1000円払ったろ!!」と思って有料枠で申し込みました。
元のスライドの大枠を作りリハをした所、序盤の序の部分で5分をオーバーし、30分くらいかかりそうだと判明しました。
宇宙猫になりましたね。 f:id:TWBMT:20220323235002p:plain

という訳で、その分のネタはこれからブログで書いていこうと思っています。
もし良かったら読んでください。

ソフトウェアデザイン 2022年3月号の「そろそろはじめるテスト駆動開発」を読んでみた。

ポッドキャストを聴き、そのままの勢いで Software Design 2022年3月号 を購入し、読んでみました。

第1章はポッドキャスト t_wada さんのブログにもある通り、
「自動テスト・テストファーストテスト駆動開発」x「利点・注意点」
の6象限についてまとめてある非常に内容のギュッと詰まった記事でした。

第2,3章にはJest を用いた環境構築・TDDの手法などがまとめられておりました。 テストの種類・考え方・現場で実践する為のコツについても触れられていて、こちらも濃密。 (Jest 書きたい。。)

今、自分にとって「やりたいこと、興味あること、必要なこと」が自動テストの領域だったので、より詳しく言語化出来て良かったなぁと思いました。
総じて、非常に学びが多かったので、買って良かったなぁと思いました。

感想・気づき・学んだこと

雑誌本編の話や具体的な知識には触れないので、雑誌やポッドキャストを是非聴いてみてください。
無料公開のポッドキャストの内容の範囲での個人的な気づきの一部だけ。

自動テスト・テストファースト・TDD にまつわる認識のズレ
t_wada さんが執筆動機にもあげているそれぞれの言葉の定義について。

実際に僕も人と話す時に認識がズレてたことがあったので、しっかり言葉の意味を揃えられた方が良いなぁ。

ちなみに、個人的にTDDは「コード書く前にはちゃんと設計や仕様を考えた方が良いよね」ということを体感できるから凄く良いと思ってます。
テストを書くに限らず、それがしっかり出来ている時はPRが通るし、それがしっかり出来ていない時はPRが通らない。

テストとソフトウェアの変更容易性について
ポッドキャストで登場する「Testing」「Cheking」っていう概念は、ソフトウェア開発に自動テストが必須な理由を言語化する為に必要な言葉だなぁと思いましたね。

後、これはどちらかというとDDDの文脈からの気付きなのですが、
理想的に言えば最初から「変わらない重要な処理」を見つけモジュール化して、「常に検証可能な状態」に置くことが出来れば良いのかなぁと。
ドメインモデリングはそういった状態を目指す為の設計手法という解釈ですね。

自動テストの質について
より質の高い自動テストを回そうとするとチームの問題に発展する、と思い至りましたね。 知り合いが、設計の話がチームビルディングの話になり、チームビルディングの話が組織論の話になる、言っていたけど、ここが入り口なのかと。。笑

他にも様々学びや知識・気づきがありましたね。

知らなかった語彙

まとめ

ラーメン食べながらポッドキャスト聴いたのが購入のキッカケだったので、ラーメンを食べて良かったなぁと思いました。
これからもこまめにラーメンを食べたいと思います。

それはそれとして、
以前参加した TDDBC に参加して TDD に触れたことが自分のコードが良くなるキッカケ、コードへの悩みを解決するヒントが得られた機会でした。 なので、同じ様に悩んでいる人は是非、TDD に触れてみてくれたら良いなぁと思います。