TAMALOG

プログラミングがあれば遠いところへ行けます。プログラムと人の共生を記録します。

2020/06/25 今日の学び

転職して25日目。

最近体力が落ちていて、残業ができないようになってしまった。大した作業をしていないのに、19:00過ぎるとがんばったなぁと一息ついてしまう。

ここ1-2年は「お金」に執着するようになり、副業や起業について調べている。この本は、Kindle Unlimited にあったため読んでみた。

www.amazon.co.jp

「さまざまな本を読んでその内容を私見と合わせて Kindle 出版としてアウトプットしてお金を稼ごう」という一文で要約できる。分量も短く、長めなブログ記事程度の本に仕上がっている。 「Kindle はページがめくられることで報酬が入ってくる」という点は、初めて知ったので時間の分の見返りはあった。 epubで出版できるらしいので、僕が書いたKubernetes本に表紙をつけて出版してみようかと思った。

お金が入ってくるなら、やってみてもいいかなと揺らいでいる。 そもそも僕はアウトプットが少なくなっており、深いインプットができていない自覚がある。

「売れる本を、誰かのためになる本を作る」というモチベーションであれば、より一層深い理解に取り組めるんじゃないかと思っている。

2020/06/24 今日の学び

今日の学び

転職して24日目。今日は、この本を読んだ。

www.amazon.co.jp

「あなたの人生を見返して強みを見つけ、週末を使って安全に起業しよう」という本。50代に向けて書かれていたが、テクニックで学びは多かった。自分の人生を年表として書いてみる試みは実際にやってみて気付きが多かった。昔はゲームプログラマになりたかったことを思い出した。

DDD実践の現場の増田さんの話をまとめてみた

BPStudy#141〜DDD(Domain Driven Design)実践の現場 (2019/05/29 19:30〜) を聴講したときに、増田さんの発表がとても勉強になったのでまとめてみます。

簡単なこの記事のまとめ

  • DDDは「ソフトウェアの変更を安全に楽にする」ことが目的。振り切っている
  • DDDは、反復プロセスであって設計して終わりではない
  • 勉強には、増田さんの本を読んだあとに、エヴァンス本がおすすめ。ほかには教材(GitHubのコード)などが用意してあり誰でも参照できる
  • エヴァンス本は読みづらいが、コツがわかれば読みやすい

増田さんの資料

ドメイン駆動設計の正しい歩き方

DDDの目的

  • 進化するソフトウェアを手に入れる
  • 現実世界の変更に追従するソフトウェア
  • 動くだけではないソフトウェア
  • ソフトウェアの変更を安全に楽にする

もちろん、進化する必要のないソフトウェアもある。そういうものには不向き

ドメイン駆動設計の考え方

ソフトウェアの複雑さはビジネス活動の複雑さに由来する。ビジネス活動ではなく、 ビジネスルールがソフトウェアを作るときに影響してくる。

  • ビジネスルールとは、ビジネスの活動を駆動し、制約する約束事のこと。ビジネスをうまく回する制約のことだったり、ビジネス上の約束事だったりする。
  • ドメインロジック: ビジネスルールをコードで表現したもの

ビジネスルールをよく理解してモデリングするためには、ビジネス活動を継続的に学ぶ必要がある。ただし、コアとなるビジネス活動を見つけ出し、集中すること。闇雲にやり続けてはいけない。

DDDを実践するための問い

以下の問いを、DDD導入時だけでなく 継続的に問い続けること が重要

  • コアドメインに集中しているか
  • ビジネスを深く洞察しているか
  • ドメイン層を独立させているか
  • モデルと実装を密に結合しているか
  • システム間の秩序の改善を続けているか

脱線しがちなパターン

ビジネス活動から目をそらす
テクニカルな問題に対してとかに発生しがち。
全体を均質にカバーしようとする
すべてを値オブジェクトにしたくなってきたりするが、すべてそうするのは悪手。あくまでも本質を見出しそこを徹底的に改善していく
ビジネスを表面的にとらえて理解した気になる
表面的に捉えてからが本番なので油断してはいけない
ドメイン層に入出力の関心事を持ち込む
画面やテーブル単位で考えてコードを書くのは間違い。それは本質的になっていない。画面やテーブルがなくてもドメインモデルは育てられるし、テストだってできる
モデルと実装を切り離す
「実装がきれいになるから」などの理由でモデルと実装を切り離してはいけない。ソフトウェア変更時に苦しむことになるし、きれいになった気になるだけ。
システム間を力づくで連携させる
「相手方のインターフェースに合わせればいいや」となりがち。ビジネスにおける本来の連携を考えつづけ、改善し続けられるか？相手のシステムならこういうドメインモデルにしたほうがいいんじゃないか？と試行錯誤すること。

事例研究: ホテルの予約アプリケーション

  • DDDハンズオンでよく使っている
  • ほかのドメインを無視して(コアドメインを見つける)、料金計算を独立させる。それだけでテストできるように作っていく
  • DDDは、現実のビジネスルールから、モデリング、実装まで段階を踏んで終わりではない。何度も繰り返して改善するもの
  • ずっと紙とにらめっこしてしまうのは間違っている。コードに起こしてみて妥当性を確認する。何を軸にするにするか決めきれなくても、候補をすべてのパターンをコードに起こす
  • 上手く回るとコミュニケーションロスも減る

ビジネスを深く洞察するための問い

  • 中核となる料金ルールはなぜそうなっているか
  • 周辺の料金ルールはどういう意味か
  • 周りのシステムにどういう情報を渡すか。仕入れの管理ツールとの連携はどうあるべきか？

現場に導入するポイント

  • 想定読者の要件をクリアする(要件クリアは結構シビアだが、クリアするためのおすすめ書籍がある)
  • 28ページの抜粋版を読む
  • エヴァンス本をちゃんと読む(即効薬ではないが、じわじわ効いてくる)
    • この本は読みづらい。 読み方にはコツがある。

教材

増田さんの意見

エヴァンス本を読むコツ

  • 紙を読んだほうがいい。流れがつかみやすい
  • 検索したいときは電子版が役立つ
  • 増田さんは、電子版と紙両方、それぞれ邦訳と原著を持っている(計4冊)
  • 実践で役立つテクニックは3部、4部にある

エヴァンスの文章スタイルに慣れる

章、セクションに共通して以下の流れがある。 無視して良い箇所があるので、見極めて読むと非常に読みやすい

  • 体験談: わけのわからない話が始まる。あとで読んでやっと理解できるため、最初は無視して良い
  • 設計課題と考えの説明: ようやく設計の考え方の説明。ここをじっくり読む
  • 他の事項との関連性の説明: 話が発散しがちなので一旦無視してよい

質問への回答

ドメインエキスパートが説明が下手だった場合どうするか？

  • ドメインエキスパートが説明が下手だった場合、「間違った具体例」を持っていく。そうすると喋ってくれる
  • ビジネスルールについては、バックオフィスの方が一番詳しい場合がある。「期日を過ぎたらどうなるんですか？」などの境界値となるケースに答えられるのは経理だったりする
  • スタートアップなどでエキスパートがいない場合、みんなで考えるしかない

ブログツールを移行したい

アウトプットしたいなぁという思いがあるものの、アウトプットするプラットフォームどうしたらいいんだろ？と先に考えてしまって、今、ブログツールを移行したいという漠然とした思いを抱えている。

エンジニアらしく、GitHubでNetifyとHugoを使ってやる個人ブログ作成してもいいかなと思ったり、書くことに集中できるMediumもいいなと思ったりしてまだ決まっていない。

Elmにはまっている

ElmはTEAさえ分かってしまえば、シンプルにかける。

ただ、モデル設計に頭を使う。 `type` なのか `type alias ` なのか。まだ慣れていないので迷いがちだ。

 

副作用がTEAに任せられるのがとても気持ちいい。elm/coreのライブラリは必要最低限を備えているように思えるので、環境構築に戸惑いがちなフロントエンドはしばらくElmに任せようと思う。

WACATE2日目の感想

WACATE 2018 夏に参加しています。WACATE最終日が終わったので2日目の感想を書きます。

tamanobi.hatenablog.com

おいしいカレー

毎年恒例らしい。

きれいな景色

目的

単体テストだけでなく、より上流のテストについて学ぶために参加しました。

概要

以下の内容をやりました。テストケースを作成するワークがとても大変で、頭が疲れました。招待講演に関しては別の記事にまとめる予定

  • ワーク
  • ワーク振り返り
  • 招待講演「原因結果グラフとWACATEが僕に教えてくれたこと」

ワーク

ワークの内容自体は単純で、仕様書からテストケースを作りなさいというものです。

  • A4 1枚の仕様書(今回は稟議書承認システム)
    • 仕様書の曖昧な部分はチーム内で合意すること
  • 1チームあたり5人あるいは6人
  • 制限時間は2.5時間
  • ゴールは「テストケースを作ること」

僕のチームは、最終的にはテスト手順を9通り作りました。稟議書の状態遷移だけです。 本当は、アクティビティ図からのテストケースを1つでも起こしたかった。

感想

UMLの有用性がわかった

UMLがテストケースを作るためにここまで有用だと思いませんでした。でも、僕が使いこなすにはまだまだ時間がかかりそうです。 適切な粒度を見出さないとうまくモデリングできないから。人によって粒度がさまざまでした。僕はかなり細かくなってしまってモデルが複雑になることが多かったです。

プログラミングをする上で、この粒度は非常に細かくなります。でも、ブラックボックステストでは粒度は荒くなります。

UML(モデリング)は何のためか

システムをモデリングすると、さまざまな観点で議論しやすいと感じました。UMLには、ユースケース図、アクティビティ図、シーケンス図、ステートマシン図などありますが複数の図を使えば、その数分だけの観点で議論できます。

以上の点で、1日目の講義で、アクティビティ図、シーケンス図、ステートマシン図の3つを学べたことに強く感謝しています。

テストがうまいとは

「テストがうまいとは何か」という疑問をもって参加しましたが、ワークを介して仮説ができました。「システムを自在な粒度と観点でみられること」だろうと思っています。

ユーザーから見たらシステムがどうみえるか？稟議書の状態はどう変化するのか？システムと連動するときは？さまざまな粒度と観点で見ることがテストにおいて重要だと思います。

テストエンジニアリングとは

ワークや交流を通じて確信したことが2つあります。

  • テストは上流から入り込まないといけない
  • すべてのテストを網羅することはできない

テストは上流から

テストエンジニアリングとは、テストケースを単に作成するだけではなく、ときには仕様を決めたり、曖昧性を排除したり、テストしやすいような結合度を考えたり、ユーザーのことを考えて機能を決めたり、幅広い範囲だと思います。

すべてのテストを網羅することはできない

ワークの時間切れを体験して、テストケースをすべて網羅することはできないと確信しました。僕のチームは、ステートマシン図から0スイッチカバレッジが100%になるようにテストケースを作成しましたが、これが複数の状態変化をカバーする1スイッチカバレッジや2スイッチカバレッジを100%満たすようにケースを作成した場合、テストケースは膨大になります。

現実的に網羅できないのであれば、最もカバーしなければならない点を定めてケースを決定する必要があります。

コミュニケーション

テストエンジニアのみなさんは、人当たりがめちゃくちゃ良かったです。人との折衝が多いからでしょうか？あるいは、他人は自分とは異なる観点を持っていて自らの学びにつながる可能性を知っているからでしょうか？

こんなに暖かく素直なコミュニティは見たことがなかったです。

東京に来てから、「優しい振りをした損得重視のコミュニティ」しか見たことがなかった。それこそ、悪質なネットワークビジネスのような(ネットワークビジネスのすべてが悪いわけではありません）。

まとめ

  • テストコミュニティは、初心者に開けていて、明るくて、前向きで、おもしろおかしい
  • テストについて知らなくても、テストに興味があれば、ぜひWACATEに参加して欲しい
  • WACATE 2018夏は上流工程を知らない自分にとって、とんでもなく学びになった

余談

このWACATE 2018夏で知った手法を会社に持ち帰って、活かそうとするのは良い心意気だと思いました。 だけど、僕がこのWACATEで理解したのは、「何が問題か」「どこが重要か」見極めることです。

勇み足にならないために、ゆっくりと問題と向き合って、そのとき適切な手法で解決しよう。