書評『A Philosophy of Software Design』:古典的かつ本質的な設計論

ここ数日で読んだ下記の本。非常に感銘受けたので書評を書く

A Philosophy of Software Design

著者はスタンフォードで教えているが、元実務家らしい。大学のコースの内容を本にしたものという。研究領域は比較的低レイヤっぽい。題名は訳すと「あるソフトウェア設計の哲学」

総評

ソフトウェア設計を複雑性（complexity） を減じるためのものだ、という基本的な考えのもと、非常に実践的なアイデアが学生のよくある間違いや好ましい例とともに記述されている。UNIXの設計を良いものと主張する場合が多い。間違いの例などは自分もやっていたな、と思うものもあり、かなり考えさせられる。数年教えてきた内容を使っているので、伝え方がうまい。

基本的なアイデアは古典的なものであり、目新しいというより原点回帰の設計論。当初はビジネスアプリケーションの設計には微妙かな、と思ったが、むしろ大事と思った。

アジャイルの罪

いくつかの議論は、いわゆるあちらのアジャイルのグルたち（アンクル・ボブやケント・ベック）と違うことを主張している。例えば、Unit Testには肯定的だが、TDDは設計を疎かにする恐れあり、として否定的だ。また、「クラスは小さくすべし」というアンクル・ボブの勧めに対して、「小さく分けすぎるな」という。

何も考えずにアジャイルで機能中心にガンガン作るってのをやると良い設計にならない/技術的負債がたまるって認識がそろそろ一般化してきていると思われる。その対策としてDDDなんかが注目されているのだと思うけど、この本に書かれているような基本的な哲学を抜かしてそこに向かうとなかなか厳しいことになると思われる。

こうした短期的な機能中心のプログラミングを著者は戦術的プログラミングと呼び、より長期の良い設計を探究しながら行うプログラミングを戦略的プログラミングと呼んでいる。TDDや機能中心のアジャイルは戦術的プログラミングを助長するという。

私見としてはプラクティスの提唱者たちは本書における基本的な考え方を身につけているから害はないのだろう。

抽象化というプログラミングと設計の核心

著者はインクリメンタルな開発には賛同するけど、それは機能（feature）単位ではなく、抽象単位であるべきだという。モデル単位と言い換えてもいいと思う。

「インクリメンタルに開発する」というのは一般的にはいいアイデアだ。だが、開発の増分というのは、機能ではなく、抽象であるべきだ。もちろん、機能によって抽象が必要とされるまで考えることを延期するのはいい。だが、ひとたび、抽象が必要とされれば、適切に設計するのに時間の投資を惜しんではならない。

TDDが設計を阻害するメカニズムとして次のように述べている。

テスト駆動開発は過度にインクリメンタルだ。...抽象化が必要になったならば、その抽象をバラバラに作り出すことをしてはならない。抽象は全体を一度に設計しなければならない。（もしくは、ある程度核となる機能のまとまりを提供できるだけの大きさは必要だろう）

ある程度一般的なモジュール（somewhat general-purpose fashon）

著者がいう抽象化のための実践的な指針が「ある程度の一般化」だ。SI稼業で何らかの成功体験がある人は、顧客の要件を鵜呑みにせず、後でどうにでもなるような仕組みを提供してうまくいった経験がある人は多いだろう。これはG.M.ワインバーグが著書でも触れていたテクニックで、長い歴史がある。

ただ、この一般化をやりすぎると結局何ができるのかが分からなくなったり、複雑性が設定ファイルやテーブルのデータ内容に移動しただけ、ということになりかねない。SIのプロジェクトでもよく見る。なんでも入るテーブルみたいなやつもそれだろう。一般化のしすぎ。

著者は個別の煩雑な要件を満たし、かつ、複雑性を減じるようなバランスの取れた一般化された目的のモジュールを設計することを推奨している。著者の例はテキストエディタの編集処理の際にUIモジュールから呼ばれるメソッドだ。

個別のユーザーの操作に対応したメソッドを一つ一つ提供するのではなく、より一般的なメソッドを提供し、それをUIが使う。

個人的にはこれらの工夫はドメインモデリングにつながると感じた。ソフトウェアのUIの下の層にドメインの本質が構築される。多分、いいUIはその下の層と操作も一致するか近しくなる。

ソフトウェア設計の本質への回帰

本書はUNIXのファイルアクセスやネットワークプロトコルのソフトウェアとしての設計などが多く出てくる。

近年のDDDなんかだとともそれば、基盤的要素は軽視されがちだけど、ソフトウェアを作る上ではそれらも大切な要素の一つ。むしろ、技術的な要素は上手く設計がされている場合が多いから問題にならない、といった方がいいかもしれない。TCPを意識することが我々があまりないってのは偉大な設計の勝利なんだよな。

この本は現代のプログラマが、ソフトウェア設計の歴史的な蓄積を身につけるのに非常に優れた本だと思う。そしてそれは新しいテクニックをみにつけ、活用するための土台になる。

こういうのが大学で教えられている、というのは非常に素晴らしいことだな、と思った。

Clojureをやってみた感想

この記事はClojure Advent Calendar 2019 - Qiitaの20日目の記事。 僕はClojure使いではなく、Javaメインのプログラマーですが、一昨年からclojure勉強し始めた。最近さぼってる。。。文系出身で、CSのバックグラウンドは皆無。比較的敷居が高いと思われる言語に、初心者から見た雑感を書いてみます。

興味を持ったきっかけ

• 一人でとあるアプリをLispで書いた人のことを聞いて。個人的感覚だと一人で書ききれる代物じゃなかったので、Lispってすげえんじゃないか、という気がしてた。
• 川島さんとか、アンクルボブとか、自分がすごい、と思う人がやってた。
• 関数型言語をやってみたかった。

勉強してみたこと

とりあえず、何冊か目を通した

Programming Clojure (The Pragmatic Programmers)

Living Clojure: An Introduction and Training Plan for Developers (English Edition)

The Joy of Clojure

フレームワークもいくつか触ってみた。

GitHub - duct-framework/duct: Server-side application framework for Clojure

Pedestal

開発ツールは色々試そうとしたけど、やはり、これになった。。。Emacsは何度か試したことあったけど、やはり挫折する。

cursive-ide.com

いまだと、Vs codeでもよさそう。

よかったこと

• 関数型っぽい考え方が分かった気がする。あと、抽象として扱うことを突き詰めること。
• Repl駆動を知れた。
• Rich Hickeyという天才の存在をしったこと。彼のスピーチが（多分）分かりやすくなった。
• 本やドキュメントも全体的に鋭い洞察にあふれているのでプログラマーとしてのレベルアップにつながると感じる。
• 触ってて気持ちいい。

現時点でつらいこと

• 設計の考え方があまりパターン化されていない気がする。というより、Javaのようなレイヤみたいな考えがなくても抽象度高く書けるのでそこらへんはどう書いていけばいいのか戸惑う。Javaっぽくやるのは違うと思っているので。
• 特にJavaとの接続部分で似たような機能があって、ちょっと戸惑う。DataTypeとRecordとか。先にどっち使うか決めなきゃいけない？
• 社内のツールをClojureで書いたが、やっぱメンテ辛いらしい。S式は見た目が違うので、勉強する気を失わせる可能性がある。

今後

やっぱ、不思議な魅力があるので今後も頑張って、勉強したい。多分、身に着けると、相当品質、生産性ともに高く開発できるポテンシャルがあると思う。 使わなきゃ身につかないのでツール作るとか、色々考え中。

ソフトウェアアーキテクチャとサッカーにおけるプレーモデル

共通イメージ

最近、ワールドカップシーズンのみのにわかサッカーファンとして、色々な動画やら、本やらを読んでいた。

youtu.be

サッカーの新しい教科書 戦術とは問題を解決する行為である

本の中で、「プレーモデル」という言葉がでてくる。ようするに、プレーについての監督、選手が共有する、どう戦い、何をすべきかの共通イメージである。複雑系スポーツであるサッカーでは、コンビネーションの秩序を得るためにプレーモデル、という共通イメージが必要ということだ。

ここから発想したこと

多分、サッカーでプレーモデルとされているのは、チームとしてどうプレーするのかの共通理解。
ソフトウェア開発においては、多分、
ソフトウェアアーキテクチャ
プロセスモデル
のふたつがそれに該当すると思う。

— 松下正嗣 (@masatsugumatsus) 2018年7月14日

つらつら書いてく

ソフトウェアアーキテクチャとは

ソフトウェアアーキテクチャの定義としては、色々IEEEとかの定義があるが、

IEEE 1471 - Wikipedia

個人的にはあまり、有用と思えない。不正確とも思わないけど、「So What?」な定義になっている。実際に仕事するとき、自分が念頭に置いているのは、マーチン・ファウラーが『エンタープライズアーキテクチャパターン』で記載した、Ralph Jonson(デザインパターンのGang Of Four の一人？)の言葉

アーキテクチャとは、主観的要素であり、プロジェクト内の熟練開発者がシステム設計に関して共通して理解していることに過ぎない。

 ファウラーはこれに加えて、「変更しにくい」「重要なもの」という要素を何となく付け加えている。

つまり

アーキテクチャとは

• 主観的要素であり
• 熟練の
• 開発者たちが共通して理解している
• システム設計についての事柄で
• 変更しにくく
• 重要なもの

 である。

個人的には、

「熟練の」というのは不要。古い大規模開発とかだと、プログラマにアーキテクチャについての理解を求めない場合もあったかもだけど、現在の規模やプロセスでそれを区別する意味はない。

「変更しにくく」も不要。今のエンジニアリングではほとんどのものが変更容易になっている。もし変更しにくいのは、多くの開発者の「共通して理解」していることだからだとおもう。

「重要なもの」も不要。共通理解が重要である、てこと以上のものはないと思う。

また、「システム設計」には当然プログラミングも含む。

だから、個人的な定義はアーキテクチャとは

アーキテクチャとは、主観的要素であり、チーム内の開発者が、システム設計/プログラミングに関して共通して理解している事柄

である。

これはサッカーにおけるプレーモデルの概念ととても近いと思う。

ソフトウェアアーキテクチャは何のために定義するのか

ソフトウェアアーキテクチャは何のためにあるのか。ここで、サッカーにおけるプレーモデルの概念が参考になる。

 ボール 保持 者 と その 味方 が お互い の こと を 理解 し、「 この 選手 は ここ で ボール を 受け て 壁 パス を したがっ て いる」 という よう に、 味方 の 次 の プレー を わかっ て いれ ば、 動き出し も 早く なる はず です。

この よう に し て 共通 の イメージ を 持つ こと で、 息 の 合っ た コンビネーション プレー が 実現 する の です。 少ない タッチ 数、 特に １ タッチ での コンビネーション プレー という のは、 どんなに 緻密 に 形成 さ れ た 守備 組織 で あっ ても 突破 する こと が 可能 です。 チーム という のは 選手 の 集まり で 形成 さ れ、 各 選手 は お互い の 性格 や 考え方 を 理解 し て いる 方 が よく 機能 する の です。

坪井 健太郎. サッカーの新しい教科書　戦術とは問題を解決する行為である (Kindle の位置No.179-187). . Kindle 版.

つまり、共通イメージをもつことでコンビネーションが促進される。また、意思決定を柔軟に、素早く行う効果もある。

note.mu

また、ソフトウェアは開発し始めたばかりのときは、設計の選択肢は無限にある。だから制約を見つけることは開発の障害であるよりは、より考えることを絞り込めるため、開発を促進する。

制約は味方である。G.M.ワインバーグ

ソフトウェアアーキテクチャ定義、アーキテクティングとは、変化していく要求に対応して開発を駆動していくために、設計とプログラミングにおけるチーム内での共通理解を作り上げ、維持、変更していく行為なのだと思う。

どんなものがソフトウェアアーキテクチャなのか

ソフトウェアアーキテクチャの例として挙げられるのは、論理的に演繹できるもの、というよりは、経験的に、共有していた方がよいとされる認識のあつまり、なのだと思う。

例えば、

• 物理/論理構成
• 採用するフレームワーク
• 採用するコンポーネント分割指針（モノリシックか、マイクロサービスか、MVC、DDDなどのパターンをどのように取り入れるか、など）
• コーディングガイドライン
• テスト戦略

例えば、RDBのテーブル構造を「技術的詳細」としてアプリケーションから隠ぺいするのか、それとも、アプリのモデルとして扱うのか、といった見立てと判断も含むと思う。

これらは文書化されることもあれば、フレームワークやツール上に実装されることもある。文書化されず、文化として保持される場合もあるとは思う。

もちろん、これらを共有するためには一定水準の共通知識が必要。スペインのサッカーでは、プレーモデルを実現する前提として、様々な概念、知識（サッカーの教科書）が育成年代からトレーニングを通じてインストールされているという。

youtu.be

ソフトウェア開発でも同じで、アーキテクチャを理解するための基礎知識は必要なんだろうな。それがあると、個別具体的な状況に合わせた対応ができる。

チーム外のステークホルダーとアーキテクチャ

伝統的なアーキテクチャの考え方として、チームやプロジェクト外のステークホルダーとの合意が重要とされることがある。自分の定義だとその観点はでてこない。ただ、別に普通のシステムに対する要求事項として扱えばよいと思うので定義を変える必要はない。

どうせ、ステークホルダーがレビューしたり、合意したりする場合はそれ向けのドキュメントなりを提示しなければならない。

追記

どんなものがアーキテクチャでないか

• 開発者に認知されないドキュメント
• 個別機能の設計やプログラミングを助けない制約
• 共有する必要のない、一部機能やコンポーネントの詳細

追記

フレデリック・ブルックスのアーキテククチャの定義

• 利用者に知覚される製品の定義

つまり、そのシステム/ソフトウェアとはなんであるか、のイメージ。アーキテクチャは実装ではない。

Jim Coplien氏の認定スクラムマスター研修に行ってきた

アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。

Jim Coplien - Wikipedia

認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。

以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。（通訳は提供されてたが、自分は使わなかった。）

また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ！という主張と理解している。

• スクラムアライアンスとスクラムを一緒にするな
• 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン」
• 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
• ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
• JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
• 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
• ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
• 完了は完了（DONE is DONE）。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
• 信頼を築くには、まず、自分から信頼すること。
• 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの？信頼が大事。
• デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
• チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
• POが出してきた要求にもチャレンジすることが大事
• アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。（どこまで強い主張かは不明）
• スプリント毎の振り返りでは、浅い振り返りになる。年に３日とか使ってしっかりと振り返りをして改革につなげたりする。
• ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。３スプリント連続で変わったりするなら再考必要

前から思っていたけど、ＰＯの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ＲＯＩを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。

講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。

dev.classmethod.jp

coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、ＰＯが書く立場と思う（開発者も含めたステークホルダーは追記できはする）。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。

ロールを全うするには、個人的には、ＲＯＩに責任もてない開発者がとやかくいうのではなく、ＰＯチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。

最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がＰＯチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。

追記①----

• 多分、スプリントプランニングの時と思うけど、３本指テストでPBIをやり切れるか、の自信を試すといい。

追記②----

上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。

とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。

でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。

 追記③----

coplienさんから回答が来た！

Great post! You are right — the developers help the PO with the tests, as they might help her with everything. But the PO does most of the work specifying the tests and has the final word on what end-user functionality to test and what the results should be.

— James Coplien (@jcoplien) 2018年7月7日

以下翻訳。

開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。

google翻訳で読んだのかな？もしくはまだ、日本にいるから、誰かに訳してもらったのかも。 

追記④----

ユニットテストが無駄である旨の記事

https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

上記記事のからの引用

• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.

回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。

• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.

広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ

（ビジネスルールのアルゴリズムとか？）

• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.

上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。

• Design a test with more care than you design the code.

プロダクトコードをデザインするより注意深くテストをデザインしろ

• Turn most unit tests into assertions.

ほとんどのユニットテストをアサーションに変換しろ

• Throw away tests that haven’t failed in a year.

1年間テストして、失敗しなかったテストは捨てろ

• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth

テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。

• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.

もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。

• Be humble about what tests can achieve. Tests don’t improve
quality: developers do. 

テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。

IntelliJ IDEAハンズオン に行ってきた

こちらにいってきた。

samuraism.doorkeeper.jp

仕事で使っているわけではなく、個人用に有償版を何年か前から購入させてもらっていたのだけど、使いこなせている感が全くなかったので参加。ツールを追求するのは苦手。。。

仕事ではEclipseだけど、使いこなせている感覚はない。。。

当日のカリキュラム

・JetBrains社の紹介
・製品紹介
　・TeamCity/Upsource/YouTrackなどのチーム開発製品の紹介
　・各種開発ツール
・ハンズオン

　・キーマップなどの初期設定

　・ショートカットと補完機能をフル活用したFizzBizz

　・デバッグ機能

　・Git

・クーポンなど
・質疑応答

注意点

感想その他

・チーム開発のツールは少人数なら無料みたいなので必要なら積極的につかってみたらよさそう。Upsourceがよさそう。

・コード補完機能は、変数の宣言と初期化が「値.var」「変数.if」や条件式.notでコード生成したり、条件式変更してもらえたり、これは、全く知らなかった。。。流れるようにコーディングできて、使いこなすと生産性がかなり変わりそうな印象。

・デバッグ機能は、Eclipseでも使いこなしていなかったけど、実際に目の前でデモしてもらうと分かりやすかた。

　※特定の条件でのみブレークポイントで止まるって機能、Eclipseにあったっけ。。。

・有償のChrononデバッガーがインストール可能なのでそれも使える、とのこと。業務ではまったときとかは使えそう。

Chronon Time Travelling Debugger | Chronon

・Gitの機能もほとんど使ってなかったのでやくだった。一部だけコミットしておくとかって結構使えそう。

結論

・時間は金で買える。

・そして、使いこなすのに時間を使うくらいなら、ハンズオン依頼しちゃうのがいいと思った。

書評『現場で役立つシステム設計の原則』

下記の本のレビュー記事。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

内容

特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。

基盤となっているのは

• ドメイン駆動設計
• Thoutworks流のオブジェクト指向開発（マイクロサービスアーキテクチャ含む）
• XP（エクストリームプログラミング）
• データモデリング（リレーショナルモデル）

あたり

感想

最初の雑感

とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、としかいいようがない。本当に使えるノウハウが体系的に整理されている。

教育コンテンツとしても完成度がめちゃめちゃ高い。前提知識をほとんど要求しないので、Javaなどの静的オブジェクト指向言語とデータベースの入門書レベルをしっかり理解している人ならそれなりに理解できるように記述されている。語られている範囲が広いのに、ボリュームも少なく、頭に自然に入ってくる。これは驚異的。相当推敲を繰り返したんではないか。

古い設計理論や開発プロセスも踏まえて語られているので、昔ながらのSIの現場にも伝わる内容になっている。そして、伝統的なやり方がなぜだめなのか、どうすればうまくいくのか、がしっかりと書かれている。あとは現場で考えてね！で逃げないのって本当にすごく難易度が高い。

誰向けか

若手～ベテランまで広くお勧め。そして、SIのマネジメント層に読んでほしい。

ドメイン駆動設計との関係

エヴァンスのドメイン駆動設計にある、Entity（エンティティ）やAggregate（集約）みたいな重要なものが語られていない。これは、実は重要でない、というか、意識して作らなくてもいいんでないか、という主張なのではないか、と自分は思っている。エヴァンズのドメイン駆動設計のアップデート。だから、エヴァンスのドメイン駆動設計を知りたかったら、やっぱり原典に当たったほうが良いかと思う。

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

プロセス

アジャイルのような反復開発でどのように開発を進めていくのか、ということも書かれている。重要なところに当たりをつけて部品を作っていって全体をくみ上げるってのがオブジェクト指向開発、とな。。こういうのが明確に語られている本は記憶にないなあ。

そして、これはScrumみたいのを形式的に適用したらオブジェクト指向開発はうまくいかないってことになるんだよね。バックログがPO任せだと、POのやりたいことが順番に降ってくるだけ。ウォーターフォールと大差なくなってしまう。

画面とデータベースに真っ向から取り組んでいるのがいい

従来の教科書的なオブジェクト指向設計の話だと画面設計やデータベース設計と絡めて語られることがほとんどなくて、現場で一番苦労するのがそこだったりするので、

「オブジェクト指向使えない」

みたいなことになってたような気がする。

この本では、画面とデータベースという、コードを汚くする2大源泉に真っ向から取り組んで、成功しているように思える。そのブレークスルーの源は「ドメインオブジェクトの主役は値オブジェクトのようなスモールオブジェクト」って洞察だと思う。

読んでなるほどーと思ったとこ

• 画面は利用者の関心事（ドメイン）を反映してるって視点。
• ドメインモデルとデータモデルの本質的なミスマッチ
• 業務マニュアルを初期から作っていく

なんとなくもやもやしてたけど、明確になった。

まだもやもやしているとこ

• 小さいWebAPI→性能大丈夫か？？
• メッセージ文字列をドメインオブジェクトに直書き→国際化とかは？メッセージ一覧ほしくならないのかな？

書いてないけど、書かなくていいと思っていること

• フレームワークとか、下回り（Radisとか）の話
• 非機能面（性能とか）の対処→疎結合、高凝集の構造だと問題起こっても何とかしやすいからね。

書いてほしかったこと

• テスト→多分、ユニットテストの重要性は小さくなっているはず。メンテもつらいし。開発の中でどうテストし、モデルの成長に合わせてメンテしていくのか、って話をちょっとだけでも書いてほしかった。

独断と偏見に基づく良いソフトウェア工学管理者になるための推薦図書

何につけてもワインバーグ。時々デマルコ。

もちろん、古い本だから、そのままってわけにはいかんけど、どんな本もそのままじゃダメ。チームや組織を作る参考になる。

amazonのレビューもいいこと書いているので、オススメ。

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

ワインバーグのシステム洞察法 ソフトウェア文化を創る〈2〉

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ワインバーグのシステム変革法 (ソフトウェア文化を創る)

パーフェクトソフトウエア

熊とワルツを - リスクを愉しむプロジェクト管理

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン