「エリック・エヴァンスのドメイン駆動設計」と「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」を読んだ

読み終えたんす

元々、Clean Architectureを読んだ後に読むぞ〜〜!と思っていた本として、エリック・エヴァンスのドメイン駆動設計を想定しており。
ってことでReal World HTTPの後に(発売日を迎えてホヤホヤのモダン・ソフトウェアエンジニアリングを間にはさみつつ)、週末を中心に読み進めてたら5/23-6/16・・・と1ヵ月弱、なかなか苦戦しながら読み終えた。*1

また、「まずこの本を読んで、多分難しくて理解度が低いだろうから、間を置かずに次はコレを読もう」と決めていたのが 「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」。

ひるがえってコチラは、昨日読み始めてサクサクと進み。今日には終わったので、とても読みやすかった印象。
「こんなに日本語の本を読むのが遅くて大丈夫なのか自分。。」と凹みかけていたので、リハビリではないけど、読める本はちゃんと読めるんだな良かった!とも思った。

ということで、一段落したので #phpgenba のエピソードを復習しながら読書メモをまとめてみる。*2 php-genba.shin1x1.com

読んで見る順番としては個人的にはこれで良かった

最初にDDD本を読んだよ

最近は「まず原典にあたる」のが正しいスタンスかな〜という風に感じており、それもあって"まずは1番難しそうな"本から取り掛かった。
ということで、「エリック・エヴァンスのドメイン駆動設計」だ(長いので、以下「DDD本」)。

恐らく、「原典」が最初にあり(もしくはターニングポイントとなるくらいの爆発力をもたらしており)、その後に出た「解説書」「攻略本」というのは、その著者の大いなる編集力によって情報が微分&クローズアップしているものでは?と思っている。

当然ながら、その様な後発本が出るのは「オリジナルが難解だから」という何よりの証左だとは思うし、初手でそこに当たるのは高コストだなという風に感じる。

なので、目的としては「理解して血肉とする」や「高解像度なインプットを得る」という風に設定せずに、「地図を広げる」というところを意識している。具体的な道筋やどこにどんな建物が立っているか?までを正しく理解できる事は望まず、「なにをどこまで取り扱っているか、どのくらい風呂敷が広がっているか」の感覚を得られればOK〜というもの。
重要な概念はその登場頻度によって「感じる」ことができるし、朧げでも話の流れを追ったり逆に1発で理解できる箇所もあるかも知れない。そうやって、頭の中に薄いINDEXを作るようなイメージ。
(ちなみに、これによって出来ることの1つとして「索引を眺めるだけでも目に入る単語が増える」し「気になったページを読みに帰ることが出来る」というものがある。何となく、1回とりあえずクリアしたRPGのような感覚がある。行きたい町に好き勝手に戻れたり、取り逃したアイテムを回収しにダンジョンに戻ったりね)

これが、自分が「まず1回は原典を読んでみよう」というモチベーションを持っている理由だ。

実際に、今まで何となく耳にしたような言葉たちは「単語の定義としては」レベルで言えば説明を得ることが出来た。
ドメインモデル、ユビキタス、境界づけられたコンテキスト、値オブジェクトやエンティティ、知識の蒸留・・・これらに「耳馴染み」が出来た。

読み切るのに相応の時間を費やしたことになる。
が、ここ最近は「インプットに掛ける時間・量を大事にしていこう」と決めているので、多少コストが高かろうと意味の有りそうな順番を求めて読む本を決めていこう・・というのが自分の中では重要。

次にDDD入門を読んだよ

(実はかなり最初に買ってたんですよ)

その一方で、追っかけて読んだ「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」(長いので、以下「DDD入門」)については、やはり「物足りなさ」を感じるかなというのは正直な所。

が、決して「だから良い本ではなかった」というものではなく、寧ろ目的を履き違えなければ「見事な本だった!!」という感想。

何が「物足りなかった」かといえば、「ちゃんと削ぎ落としてる」という部分だ。
DDD本の難しさの1つはその抽象さにあるように感じており、それは「組織の形とコミュニケーション、コミュニケーションと実装、アジャイル開発やイテレーション」というとても広大な範囲を扱っている事に良く現れているように思う。・・これをワンストップで解決しようという「DDD」のコンセプトはやっぱマジやべぇな、となるのだが。

一方で、DDD入門はこの「難しさ」に立ち向かった。自分の感覚では、極めて「コードに近い位置」に軸足を置きながら話してくれているのがこの本の「優しさ*3」だ。
DDD本は「どうモデリングしていくか」という点に常に脳みそのリソースを30%以上喰われている感覚があったが、DDD入門は基本的に「どういうコードになるのか」に終始しているのではないか。

本書中で「ボトムアップドメイン駆動設計」という概念に触れており、まさに「"具体"や"卑近"から、着実に一歩ずつ積み上げていく」という読書体験に近い。

本書のアプローチもまたボトムアップです。ドメイン駆動設計の構成する要素のうち、もっとも根底にあるものからひとつひとつ解説してきました。そして、その解説自体も、トップダウンにそれが何であるかを紹介するのではなく、必ずそこにある問題を提示し、紐解く作業を添えています。本書はドメイン駆動設計のパターンを伝えると同時に、その実践の手本として、新たな知識との向き合い方を伝えているのです。ある知識を得るために、前提となる知識が必要となることは多くあります。なるほど知識は連鎖するものです。ボトムアップに知識を積み上げていけば、必ずや理解へ到達することでしょう。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.5427-5432). Kindle 版.

あるいは、「はじめに」から引用すると「モデリングはいったんさておき」というスタンスだ。

そこで本書はモデリングについてはいったん棚上げにして、具体的なコードをベースにパターンを集中的に解説し、全体を通して最終的なコードを提示します。どこかへ行こうとするとき、目的地がわからないということはとても不安を覚えます。本書が提示するコードは明確な形をもった目的地としてあなたの道しるべになるものです。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.49-52). Kindle 版.

DDD入門はどんな本でした?

まずは「読みやすい」本だなぁ〜(ありがたい〜〜〜!!!!)という感想。
他方で、全く未学習の状態からこの一冊で「DDDは何かという肌感を掴めるか」というと少し不足があるかも知れない。

「なぜDDDをするのか」という部分、第1章で取り扱っている内容が「軽い」かも?と思ってしまった。・・・これはDDD本を先に読んだから、かも知れないけれど。
そういう意味では性急に「本題」に入ってしまっているのか?とも。それによって「抽象的でわけが分かりにくい話」を掻っ捌けているので、一冊の本としてのバランスは良いなぁ〜と感じているのだけど。
その辺りは、何か別の文献(web上に「DDD入門」みたいなものがあるかも知れない。探してみると。)で補ってからこの本に入る、という準備が出来るといいのかな〜

視点を変えて、「どういう人が読むといいか」「読むことでどういうことが期待できるか」という点。

前者については、自分のように「DDD本をとりあえず読んでは見たものの」もしくは「読もうとしたけど挫折した人」などはまさに。その他には、「DDDというものに向き合う必要が出てきている、が、いまいち理解できていない・・・」という人など。 難しい単語たちを優しく説明してくれてるのは間違いないので。

後者の方に関して言えば、「とりあえずDDDで書かれたコードを読めるようになる」というゴールが近いように思う。「自身が先導してDDDを導入したり土台のデザインをする訳ではないが、チームとしてDDDを採用しているメンバー」などはドンピシャなのではないだろうか。明日から働きやすくなるんじゃない・・・?って気がする。

例えば目次を見てみると、この本が「いかに具体的・現場的な問題を取り扱っているか」という意志が匂ってくるのではないか。
特に端的に顕れている(と感じる)前半部分の章立てを引用する。

  1. ドメイン駆動設計とは
  2. システム固有の値を表現する「値オブジェクト」
  3. ライフサイクルのあるオブジェクト「エンティティ」
  4. 不自然さを解決する「ドメインサービス」
  5. データにまつわる処理を分離する「リポジトリ
  6. ユースケースを実現する「アプリケーションサービス」
  7. 柔軟性をもたらす依存関係のコントロール

すごくないですか、「モデリング」や「コミュニケーション」から焦点を外したDDDの解説は、こんなにも足早に実装的な話に入れる・・・・DDD本だと「値オブジェクト」「エンティティ」を主題として取り扱うのは、第2部:第5章「ソフトウェアで表現されたモデル」まで時間を要しているというのに!

このアプローチの違いから、「自分自身が率先してDDDをやっていくという立場」には不足でも「DDDを採用している現場のいちメンバー」に薦めるには充分に有用性があるな〜と感じる次第。ゼロからデザインをするのは厳しかったとしても、他の人のコードを読みとったりソコに乗っかってコードを書いたりはできそう、という印象。

良い塩梅だったなぁ〜〜〜と思った。

読了後に読んだ筆者の「あとがき」を見ると「どういう本か」は伝わってくる気がする。

nrslib.com

あとはなんだろう、コードがC#だけどソコは自分的には全く問題なかった。
変に擬似コードを使うよりは(実世界のコードだし)洗練されているから良いし、本書に出てくるサンプル程度であれば言語の癖みたいなのも感じることはなく「オブジェクト指向だと大体こういう雰囲気じゃんね」というノリで読めたという感じ。

DDD本は難しかったネ^^

読むのに骨が折れた!読みにくくない??そうでもないのかな・・

やはりDDDに関しての肌感みたいなのを持っていない状態で挑戦するには強敵だな、と。
とはいえ、これで世の中にあるドメインが〜とかユビキタス言語って〜みたいな議論に付いていける土壌を耕せたと思えば、非常に価値があるコストだったと感じている。スタート地点に立てたはず・・・

もちろん、全くわからない!!何もわからない!!と終始叫びながら900ページ弱を読んだわけではないので、新しい知識もそれなりに入ってきたつもり。

  • 今まで「ドメインモデルを隔離するって一体なに??」という状態だったのが、言わんとしている事が分かった気がする
    • Clean Architecture(もとい、フレームワークやインフラ層を「些細なこと」として扱うような態度)での「本当に守りたいものは何か」を記述していくとこうなるのか、という感じ
    • これらについては、徹底的な(実装パターンとしての)DDDを採用しなかったとしても、着眼点として持っておくことは出来そうに感じた
      • 例えば仕様の隔離や誰がどんな責務を持つか、制御の流れをどうするか?など
      • DDDというかOOPで達成されるべきことについて、自分の中での練度が上がったかも知れない(勘違いの可能性もある^^)
  • 先行して概念だけ(何となく)知っていた「ユビキタス言語」、それ自体とても便利そうなもの〜という認識だったが、「ここまで徹底的にやるのか」といった感じで、確かにそうすると抜群に効果が出そうだな・・・という気がした
    • 例えば何かのIssueやPRのdescriptionを埋める時、もしくはインラインコメントを書いたりレビューをしたりする際の思考態度が変わる
  • アナリシスパターン is 何・・・
    • これはまた何か本を読んで知識を蓄えた方が良いのだろうか
    • もしくは、これに限らず「どう分析してモデリングしていくか」みたいな技法は知りたいと感じる。アナリスト的な機能なのかな、と思うが。
      • それらを無くして「どういう風にしたら良い設計たり得るか」については語れないのでは、、、、、という気がした
  • しなやかな設計 はメチャクチャ良い概念、好きぃって思った

↓ 好きだなぁと思った箇所。リファクタについて

  1. 困った時のリファクタリングをする際に、原因がコアドメインかコアと補助的要素との関係を含むものかどうかを調べる。そうであれば、歯を食いしばって、まずそれを修正すること。
  2. 自由にリファクタリングする余裕がある場合、最初に集中すべきなのは、コアドメインのより適切な括り出し、コアの隔離の改善、補助的なサブドメインから不純物を取り除くことによる汎用サブドメイン化である。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.8807-8810). Kindle 版.

(DDDに限らず)往々にして、「リファクタをすべきか、そのままでいいか」「どうしたら成功するか」みたいなのは判断が難しい所。
カッとなってやった!!!という時にコードを書く瞬発力は上がると思っているが、気分駆動でやった問題は精度の面でブレが怖い。「時間取ってリファクタしてみたけど結局なにも良くなってないじゃん」というのは良くあるし、「よく出来ると思ったけど挫折した」も同等かソレ以上にあること。
なので「何故やるべきか」の尺度はあるに越したこと無いよね〜!と感じる。

アーキテクチャは方針」であるのだから、設計思想やパターンに密接に関わっているDDDの目指すものが、自ずと「リファクタリングかくあるべき」と語り始めるのはとても自然なことだなぁと感じる。

この後どうする?

まだまだ「薄く広く、全体的なINDEXを作ってみた状態」だと思っている。なので、この後には「脳みそのシナプスをつなげる」「より具体-抽象を結びつけながら、自身の持つ解像度を上げていく」ことが必要だという感じ。
とはいえ、概念的な部分についてはDDD本が一通り抑えてくれているだろうな・・という信頼はあるので、あとは「馴染んでいく」という部分だ。

DDD本が難しかったのは「もう少し具体例・実践例を知りたい」という所があり、あと「会計がさも分かりやすそうな例として取り上げられてるけどあんまり馴染みがなくて・・」「流通もゴメンナサイ・・・」という気がしたので、より実践的な話に触れてみたいと感じている。

ということで、これを読んで見る。

実践ドメイン駆動設計

実践ドメイン駆動設計

高いなぁ買うの日和ってたんだけど。2冊読み終わった勢いでポチったので・・・・・

なんとなく「1度読んだ本」はその後も行き来してパラパラと開きやすい気がするので、実践DDDを読みながらリファレンスとしてエリック・エヴァンス先生にもお話を伺いに行こうかな。

あとは、少し自分でも手を動かしてみたいよな〜。MVC&ActiveRecordなFWとも組み合わせられるかな?
CakePHP4を用いてDDDの実践、みたいなのをやってみたい気はする。

例えばshin1x1さんのサンプルを見た時、とても「cake的じゃない」と感じた記憶があるのだが、今見たらもう少し深く理解できそうかも知れない。
(とはいえ、今のところはやっぱり「折角cakeでやる旨味」みたいなものが薄そうかな〜という印象は持っている。コレが喰わず嫌いでしかないのか?は確かめてみたい。)

github.com

あとでよむ

少し復習してみましょう、くらいのノリで読みたい nrslib.com

*1:別のこの間の週末を全てこの一冊に費やしていたわけではなく、並行して読み進めている本があったり、趣味コードを書いたり諸々もあったんですよ!!という言い訳

*2:当日は会場で聞いていたが、壁の裏から漏れ聞こえてくるうずらさんの存在感が凄かったのを思い出す度に笑ってしまう

*3:「易」ではなくて

CakePHPのアップデートなどを眺めてる

Slackだったりメールだったりで、CakePHPの更新情報を適当に眺めてたりするのですが。

↓メールはこんな感じ f:id:o0h:20200612150628p:plain

観測してるのは、cakephp/cakephp, cakephp/app, friendsofcake/awesome-cakephp 辺りです。
タイトル見て気になったものとかはチラっと見に行ったりしています

で、折角ボーッと眺めてるなら簡単なメモとか気になったこととか書いてみていくのも良いかな?と思いました。

必要なのは

  1. 情報収集をやってほしい
  2. 拾った情報にリアクションしやすくしたい

というところなので、

  • 1については
    • 対象レポジトリのRSSフィードの購読をしてくれて
    • 個別のPR単位で「新着情報」「既に何か書いた」みたいなステータス管理できて
  • 2については
    • ポチ〜っとPRを押したら対象情報を取り込んでくれた記事作成が出来て
    • マークダウンとかの手軽に書ける感じ

みたいな事が出来ればよさそ〜って思い。

CakePHPアプリケーションを何か(ちゃんと使うやつ)ほしいな、と思ったのでサクッと作るのが良いかなーなんて気がした。

やろうかな〜

やったこと・書いたもの{2020,05}

OSS

github.com

cakephp/appには初めてのPR作成(多分)。
最近はエイゴ・テキスト・コミュニケーションを完全にDeepLに委託し始めた、煩わしさが減った。
(そもそも、抽象的な実装とか設計のblueprint的な話なんかじゃなければ、英文の内容あまり気にしなくていいよな〜という気はしていますOSS活動において。)

github.com see also: Connehito/cake-sentryのCakePHP4対応を終えた - 大好き!にちようび

勉強会・LT

その他

「モダン・ソフトウェアエンジニアリング」を読んだ

たまたま代休を取っていた5/29に発売だよ〜という事に気付いて嬉しかったので、積ん読消化順を差し込んで読んだ。
書籍のタイトルと翻訳者の名前を見て即買いした次第。

  • どんな本でしたか?
  • こんな人に良いんじゃない?
  • 読後の感想
  • 内容に関するメモ
  • まとめ
続きを読む

「発見」される文化と人工的なルールについてのメモ

連続でツイートを飛ばそうかと思ったけど書いてる内に止めたやつ。
少しだけ編集して 最終的に色々と足した感じで、ブログに残しておく


① ‪例えばコーディング規約とかの「比較的ありふれている」と言われるようなプラクティス(各論的な方法)ですら合意を得て導入するのは簡単じゃないので、考え方はバラバラでも良いけど考えている事は揃えたいよね〜的な‬

②‪ 自分の場合はそういうの入れる時はまず「憲章」から設けるようにしているし、実際に前職で新規レポジトリ作った時は「前段」を入れたりした‬(当時は、今ほど深く考えていなかったけれど)
コーディング規約 for small team 2018 - 大好き!にちようび

③‪ こういう「行動を縛るルール」は、道標として機能していれば良く、逆にプラクティスレベルで「どうした方が良いか」の認識がチームで揃っていれば本来的には不要なはず〜って思うと必要悪な感じはする。‬

④‪ コーディング規約だと具体的・卑近的すぎて「それが無いほうが理想」というのを想像し難ければ、例えばcode of couduct。アレとかは、「もし無くても皆が求められるような理性的な行動をするならば」という前提で、本当は存在しなくても良いのでは?と。‬

⑤‪ こういった「無くても良いのに有るものを減らす」というのが文化の力なんだろうな〜って思う。‬
‪もちろん、他の側面では、自分たちを内省して「発見」されたものを言語化して記述して、理想への眼差しを他人同士の見ているもの揃える〜という、文化に対する補佐的な機能が「明文化すること」にはある‬

⑥ ‪最近事あるごとに「やり方を上から与えられると歪むのではないか」「どうやって、草の根で文化の力を育むか」みたいな事を考えてたけど、多分こういう事なんだろうなー。決まりがあって人が動く、というのが楽しいかどうか・・下手すると権威だけがそこに残るのではないか・・‬


と、ここまでがtwの下書きから引っ張ってきたもの。
折角ブログに場を移したので、もうちょいグダグダと書く。

<>

「文化が〜〜」みたいな概念が最近は結構お気に入りで、これはfukabori.fmのエピソードを聞いてハッとしたのがきっかけ。

25. 日本企業を辞めてカーネギーメロン大学へ入学し、Nianticで働くまで w/ noralife | fukabori.fmの30分辺りから。 ↓該当部分の書き起こし

文化っていうのは行動に現れるものである。 要するに、何かを言わなきゃ何かができない・・例えば、すごいわかりやすい各論の話ですけど、会議をした時にその議事録が残っているとか、アジェンダが用意された上で会議に臨んでいる。みたいな行動があったとして、言わなきゃできないんだったらそれは文化じゃないですよね。 何も言わないのにアジェンダが会議に用意されていて、Googleカレンダーに貼ってあって、会議が終わるとアジェンダに議事録のメモが書き起こされて、全員が見れるようになっている。それを、いちいち誰にも言わなくても、全員がそういう行動を起こせるっていうのが、文化として根付いている。そういう行動様式、行動をとりましょうねっていうことだと思うんですけど。

この時に「小さなチーム、大きな仕事」が言及されているのだけど、該当部分を引用するとこんな事が書かれている。

文化はつくるものではない

即席でつくった文化は人工的だ。ミッション・ステートメント、宣言、ルールからなるビッグバンみたいなものだ。わざとらしくて、醜く、見せかけだけだ。即席の文化は絵の具のようなもので、本物の文化は緑青のようなものだ。 文化はつくるものではない。自然に発達するものである。だからこそ新しい会社には独自の文化がないのである。文化とは普段の振舞いの副産物だ。わかち合いを奨励している会社では、それが文化に組み込まれる。信頼を重視すれば、それが組み入れられる。もし、顧客を大事にしているなら、それが文化になる。 文化とは方針ではない。社内のサッカー盤や、社員の信頼を深める研修、クリスマスパーティーやピクニックでもない。それらはただの物や行事で、文化とは程遠い。スローガンでもない。文化とは行動であり、言葉ではない。 無理に文化をつくろうと考えないことだ。上等のスコッチのように、熟成には時間がかかるのだ。

ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事 働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.1604-1615). Kindle 版.

この「文化とは行動であり、言葉ではない」という部分。 恐らく、自然と過ごす中で育まれ(熟成)、発見され、強化されていくものなんだろうな〜って気がする。

その途中で「それを守るために言語化していくことも必要になってくるタイミングがある」というのも先述のpodcastの中で触れられていて、直近の例でいうとnote社についての発信にそれを感じた。

これなどは、「元々みんながそうしていた事」であって、何も「生み出した」りしていないというのがポイントだな〜と。
何もない所に、人工的に作った何かを根付かせようというのは違うはずだ。

冒頭の「コーディング規約」については、実際問題としては「いやいや文化とかそういう類いじゃないでしょ、生産性に絡む類の規律でしょ」という見方もできそう。ただ、ちゃんと「文化」による支援を得て成立できるといいよねぇ。。。というのが、個人的な感情としてはある。
そして、そういう狙いの場合は殊更「トップダウンで決める」というのがとても難しいのじゃないかなぁ〜とも感じるところ。不可能とは言わない。強力なリーダーシップやカリスマがあれば、寧ろ迅速で効果的に導くこともできそう。

「組織のルール」と「組織の文化」が一致していると強いよねぇ〜という話でもあり。
先日、社内で「変えるのは簡単でトップ(CTOやマネージャー)に言えばそれをイエスやノーにすることは可能。なので、意思決定をしたいならCTOを巻き込むのが早い」という意見や「(トップから落とすのではなく)草の根的にやって、そこから大きなムーブメントが生まれることを期待したい」という意見が交わされるような議論を目にした。
コレなどはまさに、最終的なゴール=組織の理想状態を考える上で「決まり事を作る」という手段にどういう段階で手を出すか?といった見方の相違なのではないかなーと感じる。

恐らくナラティブの概念を補助線にすると問題の構造が見えやすい気がする。

組織の中でベテラン的な存在や(意思決定ツリーの)トップラインに近い位置にいる人などは「規律を作ってから動かす」というアプローチを採用しがちなのかもな?と考えている。彼らは比較的、「組織は理想を持って動くもの」というのを(ともすれば無自覚に)抱いている可能性が高いからだ。なぜなら、組織を「作ってきた側」にあるから。
他方で、若手や ボトム側の人間は、組織やその理想と個々人の気持ちよさだったり納得感というものは「一致していない」のが前提に感じている可能性が高いのではないだろうか。

「ルールがあれば上手くいく(そうなるように頑張ろう)」と思っている人と「ルールなんてファックだ、心で合意できないものが価値を生めるか」と思っている人がいれば、そりゃ対立するよねって気がする。*1

「文化」というのが問いで「ルール」というのが答えだとしたら、やはり文化の方がしなやかで強い組織を育むものと思っている。
自発的に、自他に問い続けることができるチームは、本質への追求を原動力に動けるし理想のための変化を恐れないんだろうな〜と。
カルチャーに導かれて一個にまとまる状態・・・


話が逸れかけましたが、まぁなんというか「気持ちよく働きてぇな〜それが出来ていないって時には何を観察したらいいかね?」という徒然でした。

*1:言うまでもなく私は「気持ちよくやりたいから」後者でいたい、という立場。ただし難易度上がるし時間のかかる道ではあるというのは承知。「動けばいいや」なら前者でいいが、エンジニアって呼ばれる職業やってんだから内部品質の重要性は分かってるでしょ・・?

connehito/cake-sentryのCakePHP4対応を終えた

遅ればせながらリリースしました🎉

packagist.org

connehito/cake-sentryというのは、前職時代に開発していてその後もメンテナに入れてもらっているOSSです。
半年ほど前に、メジャーバージョンアップをどうにか終えました。
daisuki.nichiyoubi.land

この時は「Sentry SDKがリデザインされたので新しいのを使うようにしようよ」だったのですが、1ヵ月ほど後に今度は「CakePHPが新しいメジャーバージョンを出したよ」ということで、それの対応をやらねばやらねば・・・・と今に至ったわけでございます。

どうしたの

cake4はおろかcake3ですら触っていない状況になってしまっていたので、どうにもこうにも腰が重く。*1
そうこうしている間にコミュニティの方々からPRをもらったので、よしコレを基礎としてリリースまで持っていくぞ!!!という気持ちがやっと湧いてきたのでございます。

3つ目のPRである#34をもらった時点で「大まかには動くじゃろ」というのが確認できて、またPRに書いてもらった説明から「どんな感じに変わったの?」が読み取りやすかったので、こらが大変背中を押してくれるような結果になりました。
わかりやすいPR大事だな〜〜〜〜!

ついでに

久しぶりに全体的にコードを眺めてみる〜という行動になったので、いくつか気になった点を修正したりもしています。

その中でコードカバレッジが100%になったりもしました。ソレ自体はあんま意味のある数字とも思っていないけど、まぁ折角ならキリの良い数にしておいた方が気持ちいいじゃんね!!くらいの。そもそも「あと何行かくらいだし、100%にしておこ」という軽い気持ちで手を出したら「実際にはそこに到達しない(手前でエラーになっている)」という箇所が炙り出せたので、良かったなぁという気持ちです。

他には、久々に全体的に見返していて「名付けが一貫性無いかもな・・・?」と感じた部分をシンプルにしたり、といった事をしています。

デモ環境を用意しておいて良かったね

今回の改修に関して改めて感じましたが、「そのプラグインを動かすために必要な環境を一緒に梱包しておく」のは、やはり良いですね〜。
CakeSentryでいうとtest_app という形でdocker-composeと動作デモ用URLを混ぜてありますが、コレのおかげで、開発に際して必要なことに集中できた感じがあります。

cake-sentry/tests/test_app at master · Connehito/cake-sentry · GitHub

コレやってなかったらもっと億劫だっただろうなと・・・・・・

折角Dockerfileもあることですし、Sentry側の変更等への追従を保証すべく、E2EっぽいものをCI上で回したいなぁという野望も抱いていたりします。
「web/cliでエラーを起こして→Sentry側に登録エラーを問い合わせて→登録されるべき形で今のエラーが登録されているか」みたいな。
これをスケジュール設定して動かしておけたら良さそうな感じするんですよねぇ。

おわりに

作ったものを使ってくれている人がいるのは有り難いなぁ〜〜というのを改めて感じた次第。
PRくれた人に対してどこまで直しをお願いしようかな・・?というのは割と悩ましく感じたけれど、早め早めでマージしつつ気になった所は自分で直す!!くらいの温度感が良さそう〜というのを今回の流れの中で感じました。業務コードだったり相手が同僚だったりした場合とは別だな、と。
折角関わってくれた人に対して敬意を表したいぜ〜〜〜!の気持ちと、少しずつでも前進させていくやり方をとりたいな〜という気持ちと。

今後もメンテちゃんとやっていくぞ〜〜

*1:cake3使っていれば多分cake4移行やろうぜ!!というモチベーションで動かしているだろうにな、とも思いつつ。