Magnolia Tech

いつもコードのことばかり考えている人のために。

「ドメイン駆動設計入門」を買って、読んだ

先日開催されたObject Oriented Conferenceに象徴されるように、最近設計論の議論が盛んでですね。設計論と言えば、「エリック・エヴァンスのドメイン駆動設計」、いわゆるDDD本がよく取り上げられてきましたけど、なかなかヘビーな本だし、案外コードは全然出てこないので、読んだ上で「で、どうすればいいの?どんなコードを書けばいいの?」という疑問がわきます。

おなじくドメイン駆動設計の解説書である「実践ドメイン駆動設計」も、語られる順番がDDD本と変えることで併せて読むことで理解を深めることを意図していましたが、やはりコードの少なさは同じくらいでした。

ドメイン駆動設計入門」は、とにかく豊富なコード例が出てくるところが前述の2冊と異なるところです。特に一番わかりやすい「値オブジェクト」の詳細な解説はドメイン駆動設計入門の最初の一歩として非常に効果がわかりやすいですね。まずこの本を読んでから、DDD本や、実践本を読むのは良い入り方だと思います。


自分の中でこの本を読んでて思ったのはデータストアとの関わり方ですね。これまでアプリケーション構造に最も影響を与える存在がデータストアだったと思っていて、果たして本当にそのレイヤーを正しく抽象化して分離できるのか?その抽象化は正しいのか?という所はまだ答えがないですね。

SQLにたくさんのビジネス要求が詰まっているコードも多いですし、どこにドメイン知識を寄せていくのか?という時に、データストア固有のアクセス方法はまだ無視できるほどにはなっていないと思っていて、この辺の抽象化の考え方はまだまだ理想と現実があるなーって思いました。


とはいえ、ドメイン駆動設計は設計観点の一つの過ぎなくて、別に何か正解を示してくれる訳ではないので、ばんばんコードを書いて、「自分は何の課題を解決したいの?そのためにはどんな手法が良いとされているの?」というところは考えていくしかないんですけどね!そんなことを考えるきっかけとしても「ドメイン駆動設計入門」はおすすめです。


エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

実践ドメイン駆動設計

実践ドメイン駆動設計

MacBook Proを修理した

というわけで日曜日に修理に出して、翌金曜日に修理が完了したので、足かけ2週間もPCがまともに使えない状態で、いろいろな活動ができなかった…(そんな時に限って吉祥寺.pmを中止にするとかっていうイベントも発生してしまった)。

ディスプレイも交換になってしまったので、液晶フィルムの張り直しになったけど、これが結構手こずった。毎回なかなかうまくいかない…

それでもパワーサポートのフィルムは位置合わせがやりやすくておすすめです。

とにかくApple Careには必ず入っておこう!水濡れは2回まで定額で直してもらえるよ!

「リファクタリング第2版」を読んだ

初版、たぶん読んだはずだけど、全然覚えていないので第2版を購入。JavaScriptには慣れていないけど、特に読む上で支障は無かったです。

かなり分厚い本なので、最初から読むとけっこう挫折してしまうかも…特に大部分はリファクタリング作業のカタログ集なので、頭から読むにはちょっと適していない構成です。

ある程度リファクタリング的な作業を経験した人であれば過去にやったことの有る作業を拾い上げて、自分の暗黙知形式知にしていく読み方がお勧めですね。

まだリファクタリングを経験したことが無い人だったら、迷わず第10章から読むことをお勧めします。複雑で難解なコードは、複雑な条件式(ifとかswitchとか)が入り組んでいることが多いので、それをシンプルに読みやすく書き下す方法が有る、ということを学ぶためにもこの章の「条件記述の分解」「条件記述の統合」「ガード節による入れ子の条件記述の置き換え」はとても学びが多いですね。あと、「アサーションの導入」も最初に学んだ方がいい事項と言えるでしょう。

ポリモーフィズムによる条件記述の置き換え」は、複雑なコードを単機能に分解するには有益ですが、ちょっと改修範囲が大きくなりすぎますしね。

第10章以外は、導入するには影響範囲もそれなりに大きいものが多いので、関数に閉じて適用できる第10章がお勧めです。まずは小さいところから始めましょう。

あとは第3章の「コードの不吉な臭い」、続く第4章の「テストの構築」と続けて読むと理解が深まると思いました。

とにかくダメなコードを指して、なぜダメなのか?ということを理解するのが大事ですね。先人たちが必ずしも正しいわけではなく、たまたまそうなっただけなのに、それを鵜呑みにするのは良くなくて、歴史的な経緯に敬意を払いつつ、ダメなコードはダメ、という姿勢でいきたいですね。

ただ、「コレクションクラスのカプセル化」は、昨今のプログラミング言語におけるコレクションライブラリが非常に高機能になっている中、割とシンプルなコレクションクラスを想定して書かれているような印象でした。すべての操作をカプセル化することはできないですが、主に参照のために用意されているさまざまなメソッドを、単にコピーを返す、という方法だけで良いかは結構議論が分かれる気がします。

ざっと読み進めておいて、必要になった時、自分の経験と一致するようなトピックがあるときなどに読むと良いですね。

「レガシーコードからの脱出」を読んだ

「レガシーコードからの脱出」を読んだ

若干ウォーターフォールアジャイルの対立を煽り過ぎだな、と感じる前半戦(別にアジャイルにしたからといって成功するわけでもないし)と、散発的なテーマが並ぶ後半戦、なぜかやたらと詳細なテスト関係…と、正直これを読み込んだからといって新しい発見があるというより、冒頭のツイートでも書いたように、色々なテーマが詰まっているので、読書会などで自分の経験とか考えをまとめるきっかけにすると良いな、と思いました。

3日間くらいかけてメモを取りながら読んだところ、さまざまな過去の経験がよみがえってきたので、メモを取りながら疑問点とか、過去の振り返りを書き出しながら読むのがお勧めです。

「Design It!」を読んだ

副題にある通り「プログラマのためのアーキテクティング入門」ということで、どうやってシステムのアーキテクチャを設計していくか?という課題に対して向き合うための方法を示してくれる本です。

とはいえ、所謂アーキテクチャカタログ集ではないので、即効性の有る内容ではなく、ゼロベースでアーキテクチャを決めていくための思考のステップを示してくれる内容なので、具体的なアーキテクチャにつながる技術要素は、ここに示された内容を元に情報収集し、判断し、決めていくしかないですね。

第Ⅰ部 ソフトウェアアーキテクチャ入門
 1章 ソフトウェアアーキテクトになる
 2章 デザイン思考の基礎
第Ⅱ部 アーキテクチャ設計の基礎
 3章 デザイン戦略を立てる
 4章 ステークホルダーに共感する
 5章 アーキテクチャ上重要な要求を掘り下げる
 6章 アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)
 7章 パターンで土台を作る
 8章 意味のあるモデルで複雑さを扱う
 9章 アーキテクチャデザインスタジオを開く
 10章 設計判断を可視化する
 11章 アーキテクチャを記述する
 12章 アーキテクチャに通知表をつける
 13章 チームのアーキテクト力を強める
第Ⅲ部 アーキテクトの道具箱
 14章 問題理解のアクティビティ
 15章 潜在的な解決策を探るアクティビティ
 16章 設計をタンジブルにするアクティビティ
 17章 設計の選択肢を評価するアクティビティ

特に1章から4章まではマインドセット的な内容も多く、アーキテクチャ設計のステップを知りたい人はまずは5章の「アーキテクチャ上重要な要求を掘り下げる」から読むと良いでしょう。「制約」や「品質特性」など、必須の重要キーワードが出てきます。更に6章〜7章がまさに具体的なアーキテクチャを決めていくステップになっているので、最初は5章〜7章までをじっくり読むことをお勧めします。

8章から13章は、それをより良くするための手順や、視点ですし、14章以降はより具体的な手法になっています。このあたりは必要に応じて拾い読みすると良いですね。

アーキテクチャをタンジブルにする

この本を通じて「アーキテクチャをタンジブルにする」という印象的なキーワードが出てきます。「タンジブル(tangible)」は”触れられるようにする”という意味ですが、必ずしもアーキテクチャを図示することを意味していません。

「2.1.4 アーキテクチャをタンジブルにする」には以下のように書かれています。

アーキテクチャを図に描く、アーキテクチャをコードの中で生き生きと表現する、構造や品質特性を体験できるようなプロトタイプを構築する、アーキテクチャの一部がどう機能するかを示す簡単なモデルを作成する、関連するメタファーを作成する、システムの制御フローの一部を身振りで伝える、などだ。

必ずしもドキュメンテーションだけが方法ではなく、色々な手段が有ることを示しているのが良いですね。16章にはそのための具体的な手法が紹介されています。

おわりに

繰り返しますが、この本はアーキテクチャカタログではないので、これを読めばすぐにアーキテクチャデザインができるわけではないですし、特定のアーキテクチャを想定したものでもないので、技術的な情報収集はゼロからやっていく必要が有ります。

しかし、いにしえの”LAMP”とか、”まずはRails”、という時代ではなくなり、色々な選択肢が無限に有る中、ゼロベースで考える場面が多くなってきた現代ではこのような”思考のガイドライン”がますます重要になってきたと思います。

すべてのアーキテクチャ上の決定を細部までこの本に合わせてやっていると、今度は時間が足りなくなるような気もしますが、アーキテクチャ上の重要な意思決定を行う際には、このような原理原則に立ち返る瞬間はきっと必要だと思いました。とりあえずアーキテクトを目指す人は、一度流し読みをしておいて、いざという時に立ち返れるようにしておくと強力な武器になるのではないでしょうか。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

Design It!: From Programmer to Software Architect (The Pragmatic Programmers)

Design It!: From Programmer to Software Architect (The Pragmatic Programmers)

コードリファレンスと、クロージャと、map関数

このエントリはPerl Advent Calendar 2019の8日目の記事です。

7日目は@kfly8さんでした。

2019/12/8 追記: worthmineさんにコメントで、クロージャの定義が間違っているとご指摘頂きました。すっかり思い込みで誤ったことを書いてしまいました。ちゃんと原点に当たらないとダメですね。記事の内容が間違っているので、一度見直すためにクローズします。

ちゃんと25日までに書き直します!

HHKB Professional Type-Sを買った

長年初代のHHKB Professionalをメインで使っていて、それはそれでまったく壊れる気配がまったく無くて、買い換える必要は無いのだけど、別の環境で使っている、ちょっと前に買ったメカニカルキーボードがどうにも相性が悪く、使いづらかったので、思い切って購入。

最後までREALFORCE R2 「PFU Limited Edition」とどっちを買うか迷ったけど、結局サイズ感が慣れているので。

しかし、もっと早く買えば良かった。これまで使ってきたキーボードの中でこれに匹敵する打鍵感はたぶん無い。ADB時代のApple Keyboardが近い気もするけど、ここまで静音でもないし(というか、今では入手できないし)。

と言うわけで、テンキーやカーソルキー、ファンクションキーにそこまでこだわらない人(つまりvimユーザーか…)は、一つ持っておいて損は無いと思う。手入れしながら使えば平気で15年以上は使えてしまうので、コストパフォーマンスは素晴らしく良いし。