マンガではわからない ソフトウェア開発の真理

マンガではわからない ソフトウェア開発の真理

所長 たなかひさてる @tanakahisateru

20年以上前の古典をマンガにしました 2019 2020 マンガでわかるデザインパターン マンガでわかるアンチパターン (1994) (1998)

人月の神話 〜狼人間を撃つ銀の弾はない〜 新装版 (銀の弾がぬけてて残念な表紙)

人月の神話 外科手術チーム アンチパターン デザインパターン 銀の弾はない 本質的困難さと偶有的困難さ

人月の神話 フレデリック・P・ブルックス ソフトウェアの設計と開発に関する原典じゃないかな • IBM System/360 の OS を作った経験にもとづくエッセイ集 • ハードウェアコストのためウォーターフォールが当然だった時代 • ブルックスの法則「遅れているソフトウェアプロジェクトへの要 員追加は、プロジェクトをさらに遅らせるだけである」 • ソフトウェア・アーキテクチャという言葉を最初に使った

1975年 初版

1975〜1976年のできごと 私達が知っているコンピューターが初めて世に出た時代 • BASIC を搭載した事実上初のパソコン、アルテア 8800 発売 • ジョブズとウォズニアックが Apple I を開発 • Z80 CPU の登場 • 田中ひさてる爆誕

それから 20 年… 1995年 改定第2版 現在普及しているのはこの版のほうですね

1995年前後のできごと インターネットというコンピューティングの大転換 • GoF デザインパターン • Windows 95 発売 • Java や Ruby の登場 • 我らが Personal Home Page Tools のソース公開 • 田中ひさてるプロデビュー

1995年以後 〜近代的なウェブ開発のスタイルまで • アンチパターン 1998 • SOLID 原則 2000 • アジャイルソフトウェア開発宣言 2001 • テスト駆動開発 2002 • ドメイン駆動設計 2002 ← ここ重要 • (Ruby on Rails 2003 〜 ひとつの時代の終焉)

人月の神話 外科手術チーム 〜 アンチパターンとの関係

ブルックスの法則 人数と時間は交換可能ではない • 主流だったウォーターフォールが間違っていることは 75 年時点 ですでに示されていた • プログラマーを追加可能で均一な労働リソースと考えるな • 産業の理論: 後の工程ほど誰でもできる作業になる ←→ ソフトウ ェア開発の妄想 • IT では最終工程の労働力がコンピューター → 考えたらわかる

外科手術チーム プログラマーは工場労働者より医師に近い職業 • 高度なソフトウェアは人体のように複雑 • 専門的な知識と患者の病状理解が必要 • 執刀する主治医と助手数名の精鋭チーム + 看護や事務など • アーキテクチャ設計、モジュール実装、テスト(当時は手動)、文 書化、その他雑務… 外科手術同様、まったく均一な労働ではな い • にもかかわらず、人月の神話を信じる考えなしの人が増えた

アンチパターン: 偉大なるヨーク公 技能の不均一さについて改めて • ヨーク公 = すべての民衆を公平に扱った立派な王様 • …でも公平さはソフトウェア開発を失敗させる • 優秀なプログラマーは少なく、凡庸なプログラマーは超多い • 全員の意見を公平に採用すると、優秀なプログラマーの意見が、 思慮が浅くそれを理解できない多くの人に潰さる • というように、他のアンチパターンの多くも、失敗原因の本質が 思い込みや思考停止だと説いている

アジャイル宣言(超訳) 思考停止やめよう運動 • 個人と個人で理解 > 組織的管理手法で • 動くプログラム > 仕様書に全部書いてある • いっしょにがんばる気持ち > 自分だけ損したくない気持ち • 計画は柔軟にね > 最初に言ってたとおりにしかできません • 右は組織の理論による思考停止の正当化 = すでにアンチパターン ですべて問題提起されていた

ていうかブルックスは すでに語ってた

銀の弾はない 本質的困難さと偶有的困難さ 〜 デザインパターン

偶有 vs 本質 • 偶有 • コンピューターの都合で仕方なく必要という意味 • エラー処理、メモリ上限、通信速度… 昔は厳しかった • 本質 • 偶有的な問題をすべて取り去れたとしてもまだ残る部分 • コンピューターを使って解決したい問題そのもの • 時代とともに偶有的困難さは減り、より本質が求められるだろう

デザインパターンで理解 疑問: GoFはなぜこんな構成で書いたのか • 「生成」「構造」「ふるまい」の順に書かれている • 生成: AbstractFactory / FactoryMethod / Prototype • ふるまい: Strategy / Iterator / TemplateMethod • 「ふるまい」から先に教えたほうがわかりやすいのに ← NO • OOP の基礎 = 使用と生成の分離 • デザパタはその構成全体でこれを語っている

思考実験: 仕様書とコードの if 比 • コードには仕様説明にない大量の if 文 • 場合の組み合わせが人間の理解を超える → バグ • 要求の元は人 → 本質的に必要な分岐は人が理解できる数のはず • 多くの if は偶有的な条件分岐だ • これを減らすには? → オブジェクトの多態性を活かした判断の前 倒し (ブルックス 1995 OOP = 真鍮の弾丸かも)

使用 DatabeseDriver query() MySQLDriver PostgreSQLDriver 適切なドライバを1回だけ new するだけで 生成 毎回どっちの DB かで if しなくて済む

デザパタ = 偶有的関心のコレクション • 抽象による詳細の if 隠蔽こそが OOP の本領 • OOP ができているとき、使用と生成の境界が必ずある • つまり生成は最重要な偶有的関心、構造やふるまいは派生物 • パターンは記述するより認識するほうが大事 • パターン名で偶有的困難を抽象化し、分けて考えることで本質が 残る

そして裸になった本質 固有の問題=ドメインモデル • 「銀の弾はない」 = いくらデザパタ等で偶有的な問題を分離して も、本質的な問題自体は消えない • 現在は70年代と比べれば偶有的困難は明らかに少ないが、いま だにソフトウェア開発は難しい (ツールを使う難しさなんて、ツールがなかった頃の難しさの比じゃないので無視) • なぜなら: 本質的困難さ、つまり、妥当なドメインモデルをデザ インする難しさが絶対になくならないから

やっぱりブルックスは すでに語ってた

我々は45年間 ブルックスの世界で 同じことを続けている のではないか…

? 正しいソフトウェア開発のかたちとは?

グレゴリーのダルメシアン Gregory R (1970) "The intelligent eye" McGraw-Hill, New York (Photographer: RC James)

経験による知識 → 実在しない輪郭線が見える

人月の神話 (75) 銀の弾 経験 ? 経験 経験 外科手術 わかる人にはこれで十分

しかし「プログラマーの経験」の現実は… 怠慢 誤った 教育 失敗体験 未経験 「文字は読めるが意味がわからない」状態 輪郭を認識した人と初見の人では全然違う

人月の神話 (95) オブジェクト指向 デザインパターン アンチパターン ? より狭いフォーカスで具体的な例を大量に ダウンサイジング 開発者人口の増加

でも情報量がいくら増えても、輪郭線を直接表すことはできない ドメイン駆動設計 銀の弾 ? アンチパターン これでもまだ デザインパターン アジャイル 外科手術

? なぜなら

輪郭を引くのは経験知識 = ダルメシアンを知らなきゃ無理

マンガでわからない真実 • マンガ = もちろん最強の紙媒体 • 絵ですぐ登場人物を通して感情移入 → 共感できる • が、そもそも共感のもとになる経験は表現できない • 経験 = 反復の中で少しづつ間違えながら学習し得られるもの • スポーツでいうと「頭で理解しようとするな体で覚えろ」

反復訓練の重要さを表した画像 遺伝的アルゴリズムの進化 = 言語化されない経験 これいま面白いと思えるかも経験ですよね。説明しても面白くない。

真理は開発者の 経験の中にある コード書こう 巨人の肩に立つには自分の足が必要だよ