書籍『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える

こちらのトークイベントで用いたスライドです。

『良いコード/悪いコードで学ぶ設計入門』著者トーク
https://modeling-how-to-learn.connpass.com/event/242976/

Transcript

1. 『良いコード/ 悪いコード で学ぶ設計入門』で エンジニアリングの 当たり前を変える 2022/4/26 ミノ駆動
2. #ミノ駆動本 公式ハッシュタグです。 本日のイベントや、拙著のご感想ツイートなどは、 このハッシュタグをお使いいただけると嬉しいです。
3. おしながき • 自己紹介 • 本書概要 • 本書で向上が期待できるスキル • 本書の特徴 • 評判の声 • 各章紹介 • この先に目指す世界 • 執筆裏話
4. 自己紹介 ミノ駆動 @MinoDriven 仙塲 大也 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 悪しき構造が招く凄惨な結末を風刺した「クソコー ド動画」シリーズの作者。
5. クソコード爆殺本 良いコード/悪いコードで学ぶ設計入門 〜保守しやすい成長し続けるコードの書き方〜
6. 様々な悪しきコードを例に 設計を学べる技術書
7. Amazonほしい物ランキング和書No.1
8. ヨドバシ.com 楽天ブックス 予約段階で在庫切れ発生 （現在は回復しています）
9. 4/7 初版部数　2倍増刷
10. 4/25 発売前部数　1万部突破！ ほぼ前例なし
11. 4/26 各種電子版発売 Amazon Kindle 楽天Kobo Gihyo Digital Publishing いちはやく読んでみたい方はどうぞ
12. そして4/30 紙版　全国発売
13. 本書で向上が期待できるスキル
14. 習得スキル① 悪しきコードが見えるようになる
17. 理想形を知ると 理想と違うものを認識できる
18. 大昔、疫病は悪魔のシワザだと恐れられた
19. 悪魔の正体が病原菌だと分かり 対処方法が劇的に革新
20. 悪しきコードも同じ 理想形を知り 正体を見破ることで 正しく対処できるようになる
21. どこが悪しきコードなのか 見えない、よく分からない
22. （悪しきコードが）見える、見えるぞ！ ムスカ大佐の気分になれる とてもうれしい
23. 悪しきコードが光って見える
26. 動悸、息切れ、引きこもり になるかもしれない
27. 習得スキル② 変更に強い構造を設計するスキル
28. なるべくバグを埋め込まず 素早く正確にコード変更できる スキルが身に付きます ただし、練習は必要です
29. 本書の特徴
30. 特徴① 初級～中級向けの設計入門書
31. 入門書
32. 現実には… 入門書
33. 入門書 わーい、ゴールに到着したぞー！ 今日から月収7桁万円だー！！ この先の世界が 認知されていないケースも！ （むしろこちらが多いのでは…）
34. 入門書 初級と中級の間にかける橋
35. 新人さんに命名や責務の重要性を説明しようにも、それらをおろ そかにしたら何が起こるのか、いちいち例えを出すのはとても大 変。 また、設計上おさえるべきポイントを説明しようにも、都度口頭だ と、説明が五月雨になったり抜け漏れが生じたりして、いまいち意 図が伝わらない、といった事態に陥りがち。
36. 本書は、どういうのが悪しきコードなのか、何がマズいのか、設計 でどう解決すればいいのか整理して記述されています。新人教育 にピッタリ。 チーム全体の設計力向上、底上げを期待できます。
37. 本書ならではのユニークな設計観点をいろいろ盛り込んでいるの で、中級以上の方にもオススメです！
38. 特徴② 膨大なサンプルコードと事例で解説
39. どこのページを開いても、ほぼソースコードで満たされています。 それほど具体事例を示すコードが豊富です。圧倒的ボリュームで す。 イメージの難しい抽象的な設計論ではなく、具体的なソースコード を提示してイメージしやすい構成になっております。
40. 特徴③ 実践で使えるオブジェクト指向設計
41. 私は業務でアプリケーションアーキテクトとして、リファクタリング や設計全般を推進しています。普段から泥臭いコードと格闘して いるのです。 私が普段の仕事で用いている、構造改善のためのオブジェクト指 向設計の実践的ノウハウを記載しています。
42. 設計の理論武装ができます！ かつてリファクタリングするかどうかで血みどろの戦いをしていた とき、反対勢力を説得するために理論武装する必要がありまし た。 そのときに得たノウハウが本書には活きています。
43. 特徴④ Javaで書かれています
44. 広く読んでいただくことを意図し、Javaを採用しました。 利用者数が最も多いためです。 ですがJavaの本ではありません。広く読まれることを意図している ので、Java独自の言語仕様やフレームワーク知識はあまり用い ていません。 他の言語でも読み替えが容易になるよう配慮しています。
45. Webアプリ、ネイティブアプリ、組込みソフトウェア、ゲーム……特 定のIT領域に限定せず、オブジェクト指向言語ならばどのIT領域 でも広く適用可能な設計手法として記述しています。 DBやhtml、ファームウェア技術や特定のフレームワークといった 知識は、本書では取り扱っていません。
46. 特徴⑤ ドツボにはまりそうなパターンを網羅 本書最大かつ 他にはないユニークな特徴
47. 再現性のある罠
48. 私は分野の異なる様々なサービス開発の経験。 どのサービスでも、悪しきコードの傾向はほとんど皆同じ。 みーーーーーーーんな同じ罠にハマっている。 そうした再現性のある罠に対応する、再現性のある対処方法を豊 富に解説しています。
49. つまり
50. この本に書かれてることを 遵守すれば 大抵の悪しきコードは解決する（豪語
51. 悪しきコードが最も書かれるタイミングは、仕様変更時。 仕様変更時にやってしまいがちな悪しき実装、悪しき行動に着目 し、どう改善すれば良いかを解説します。 仕様変更時の罠について記述した書物は、（私の観測範囲では） ほとんどあまりない印象。本書最大のユニークさであり、皆さんの スキル向上に貢献する内容だと自負します。
52. 評判の声
56. 各章の紹介
57. 第1章　悪しき構造の弊害を知覚する 1, 2章は新卒プログラマさん向けの章です。 そもそも設計には、「設計しなければ」という危機意識が必要。 危機意識の醸成には、悪しきコードによる弊害を知覚する必要があります。 悪しきコードの弊害をダイジェスト的に紹介する章です。
58. 第2章　設計の初歩 いきなりクラス設計の話となると、新卒プログラマさんにとっては重いので、簡単な命名 やメソッドの設計をベースに、どういうことをするのが設計なのかを学ぶ章です。 1, 2章を通じて、設計が全く分からない新人さんでもステップアップしやすい構成になっ ています。
59. 第3章　クラス設計 すべてにつながる設計の基盤 3章から設計解説の本番スタート！ 低凝集で貧弱なデータクラスを、高凝集なValueObjectへ成長させる例を用いて、クラス 設計の基本を解説します。 本章で解説する設計の考え方が本書全体の基盤になる、超重要な章です。 本書全体の理解には、この章の理解が必須です。
60. 第4章　不変の活用 安定動作を構築する 変数の値を変更できるなど、状態変更可能なことを可変、変更不能なことを不変といい ます。 可変が前提のロジックだと、変数がいつの間にか意図しない値にすり変わっているな ど、挙動の予測が難しくなります。保守や変更が大変になります。 不変を活用して、予測しやすい安定した挙動の設計方法を解説します。
61. 第5章　低凝集 バラバラになったモノたち 強く関連し合うデータとロジックがバラバラに散在している構造を低凝集といいます。低 凝集は重複コードや修正漏れを生じさせ、なにかと厄介です。 低凝集に陥りがちな様々なパターンと、対策方法を解説します。
62. 第6章　条件分岐 迷宮化した分岐処理を解きほぐす技法 条件分岐は、条件に応じて処理を切り替える、プログラミングの基本制御です。しかし条 件分岐をずさんに扱うとロジックが複雑になり、混乱します。 この章では、条件分岐の複雑さを低減し、コントロールできるようになるための設計方法 を解説します。特にロジック単純化の鍵を握る、interfaceの使いこなし方について重点 的に解説します。
63. 第7章　コレクション ネストを解消する構造化技法 配列やリストといったコレクションには、ループ処理が伴います。ループ処理周りも多重 にネストしてロジックが混乱しがちです。 コレクション周りのロジックを簡明にする設計を解説します。
64. 第8章　密結合 絡まって解きほぐせない構造 責務の異なる様々なロジックが複雑に絡み合い、依存関係が強い構造を密結合といい ます。密結合は、わずかなロジック変更でも他の多くの箇所に影響が伝搬しやすく、バ グ化しやすい構造です。変更に弱いのです。 8章では、有名なソフトウェア原則「単一責任の原則」をベースに、密結合な構造を疎結 合な構造へ改善する設計手法を解説します。「単一責任の原則 is 何」「責務 is 何」が しっかり理解できるようになります。 また、密結合は様々な要因により陥りがちです。密結合に陥る様々なパターンと対策方 法も、8章で取り揃えております。
65. 第9章　設計の健全性をそこなうさまざまな悪魔たち この章では、null問題や例外の握り潰しといった、邪悪な実装シリーズを解説します。 単純でありながら、プログラミング初心者が陥りがちな凶悪な罠ばかりなので、新卒プロ グラマさんにはぜひ目を通してほしい章です。
66. 第10章　名前設計　―あるべき構造を見破る名前― メソッドやクラスに付与する名前は、可読性に影響するだけではありません。ロジック構 造を大きく左右します。いい加減な命名をすると、あっという間に粗悪な構造が出来上が ります。 私が提唱する目的駆動名前設計をベースに、最適なロジック構造を導き出すための名 前の設計方法を解説します。 また、命名でついつい陥りがちな罠やその対策方法を、数多く解説しています。名前設 計のさまざまな状況に対応できるようになります。
67. 第11章　コメント 保守と変更の正確性を高める書き方 ソースコード上のコメントは、読み手の理解を促すために記述します。 しかし、いい加減なコメントを書くと読み手に正しく意図が伝わらなかったり、ウソを伝え てしまう可能性があります。 保守や変更の正確性を向上させるためのコメントの書き方を解説します。
68. 第12章　メソッド（関数） 良きクラスには良きメソッドあり メソッド設計の良し悪しは、クラス設計に密接に連動します。メソッド設計が良くないと、 余波でクラス設計が悪化します。逆もまた然りです。 この章ではメソッドの設計方法を集中的に取り扱います。
69. 第13章　モデリング クラス設計の土台 物事の特徴や関係性を簡単に図で表したものをモデルといいます。モデルをつくる活動 をモデリングといいます。 モデルはクラス設計の土台です。モデルがいい加減だったり、もしくはモデリング自体を しないと、クラス構造が粗悪になり、変更が難しくなってしまいます。 モデルが、構造や変更のしやすさにどう影響してくるのか、どうモデリングすれば良いの かを解説します。
70. 第14章　リファクタリング 既存コードを成長に導く技 この章では、リファクタリングの方法を解説します。 「リファクタリング is 何？」の知識がない新人さんもステップアップして理解できるよう記 述しています。 また、テストがないコードをリファクタリングする方法や、リファクタリング時に陥りがちな 罠など、中級者にも有用なテクニックを解説しています。
71. 第15章　設計の意義と設計への向き合い方 15章以降にはソースコードは登場しません。 設計にまつわる考え方や取り組み方を解説します。 この章では、なんのために設計するのか、その意義を深掘りします。そして我々エンジニ アがどう向き合い、設計品質を高めていけばよいのかについて解説します。品質の指標 や、指標をコントロールする各種ツールも紹介します。 会社の事業成長とエンジニア自身のスキル成長について解説している、結構重要な章 です。
72. 第16章　設計を妨げる開発プロセスとの戦い 設計が上手く働かないのは、チームの設計スキルが未熟であること以外に、開発プロセ スに問題があるケースが多いです。 この章では設計を妨げてしまう開発プロセスを取り上げます。 コミュニケーション、心理的要因、組織上の課題etc……それぞれの対策方法を解説し ます。
73. 第17章　設計技術の理解の深め方 最終章です。 読者さんがさらに自主的に設計スキルを高めていく方法を解説します。 中・上級へのステップアップに有用な技術書を紹介します。用途や難易度に応じて様々 な技術書を紹介しています。 拙著で設計知識の足固めをしておけば、スムーズにスルスルと理解が進むでしょう。 また、設計技術の効率的な学習方法も解説しています。
74. 『バグハンター2 REBOOT』 https://game.nicovideo.jp/atsumaru/games/gm22047 無料。 PC、スマホでプ レイ可。 副教材的な位置づけです、ぜひ遊んでね
75. そろそろタイトルの 「エンジニアリングの当たり前を変える」 を回収したいと思います
76. 毎年12兆円以上
77. 毎年12兆円以上 2025年以降 技術的負債による経済的損失
78. 負債による損失（毎年）：12兆円以上 2021年度国家予算：142.5兆円 喫緊の課題 我々は対処していかなければならない
79. 2022年現在　必須スキル Linux Git GitHub
80. 2022年現在　必須スキル Linux Git GitHub Docker AWS 近年はこのへんも推奨スキル になりつつある。
81. 2022年現在　必須スキル Linux Git GitHub Docker AWS 変更容易性を考慮した設計スキル むしろコレを当たり前にすべき では！？
82. より高みを目指す人は アーキテクトへ！
83. 出典：経産省『IT人材の最新動向と将来設計に関する調査結果』（ 2016） アーキテクトが全然足りない！体感レベルで人材不足
84. ITアーキテクト種別一例 インフラアーキテクト ソリューションアーキテクト アプリケーションアーキテクト インテグレーションアーキテクト 本書はここの道に通ずる！ ぜひみんなも目指そう！ やれる！全然やれる！！
85. 設計が 当たり前の世界へ
86. でもそんなことできるの？ そもそも「変更容易性」すら 認知されているか疑問……
87. 10.9％
88. 10.9％ マーケットシェア理論 影響目標値 市場にとって影響を無視できないシェア率 マスコミュニケーションにおいては どんなにマイナーな事柄でも 認知度が全人口の10.9%を超えると あっという間に広がるとされている
89. 国内のプログラマ人口：約92万人 92万人 x 10.9% = 約10万人 約10万人に変更容易性設計が認知されれば良い 10万部売れれば良い
90. 『リーダブルコード』 10万部以上 『ゼロから作るDeep Learning』 20万部以上
91. つまり10万部 しつこい
92. みんなで広めよう
93. おしまい☆
94. ここからは 執筆裏話
95. クソコード図鑑（2020/01/02）
96. なんと、その1ヶ月後に編集者さんから…
97. 夢だけど夢じゃなかった！
98. クソコード動画から繋がった書籍執筆
99. 提案は受けたが企画が通るかが最初の関門 編集者さん： 書籍として商品化するには、売れるに相応しい内容が盛り込まれている必要がありま す。 クソコード動画以外で、書籍に記載できそうなネタは、何かないでしょうか？ 目次みないなアウトライン程度で結構なのですが。 何かリストアップできませんか？
100. ゲーム『バグハンター2』の モンスターリストをそのまま転記して出したところ…
101. 即、 「企画通りました、 執筆に取り掛かりましょう」
102. ゲーム『バグハンター2 REBOOT』があって、 拙著『良いコード/悪いコードで学ぶ設計入門』が 誕生したのです。 両者は、根っこでは実は世界が繋がっているのです。
103. ご静聴ありがとうございました