2019/08/03に開催された「すえなみチャンス暑気払い」( https://suenamichance.connpass.com/event/134462/ )で公開したクソコード動画「Managerクラス」に関する解説です。本作中に登場する設計の、何かマズいのかについて説明します。

1. クソコード動画
「Managerクラス」
解説
#すえなみチャンス暑気払い
#すえなみチャンス暑気払い
ミノ駆動( @MinoDriven )

2. この動画の解説だよ！
https://twitter.com/MinoDriven/status/1157554468201746432

3. うん、まあ…話にならない
少なくとも全体概要を示す
仕様書があってもいいのでは

4. WorkflowManagerは
実在します

5. 「責務」って一体なんだろ（白目
↑
作者が上司から
実際言われたセリフ

6. うん…
話にならない
責務とは
関心事それぞれについて果たすべき振る
舞い。「関心の分離」と密接に関わる。
Viewや永続化など、アーキレベルで関心
事を分離することは当然ながら、DDDに
おけるドメイン層においても、各業務概念
それぞれの関心事を分離することが肝
要。

7. 高凝集って（白目
作者が上司から
実際言われたセリフ
関心事を分離して、
各関心事それぞれ
に関係するものを集
めなさいよ！！(#
ﾟДﾟ)

8. - 修正箇所の特定が困難
- 影響範囲分析が困難
それ以上に深刻なのは、上記分析に異
常な工数を浪費してることに気づいてな
いプログラマや現場が多いこと。むしろ
「それが当然」という認識。
設計よる生産性の効果は、良い設計をし
た未来と悪い設計した未来を比較しなけ
ればならず（並行世界）、説得が困難。
書籍Clean Architectureにあるように、
アーキテクトはここを全力で戦う責務があ
る。

9. 厳しいことを言うと、クラスB君は「仕事を
サボっている」。
生産性や品質を向上させる設計業務を
怠っている。
でも本人は一生懸命仕事した気になって
いる。これが罠。
「これ以上生産性が上がるはずがない」と
本気で思ってるプログラマは多い。
仕事の仕方にBestはない。ただBetterを
目指すのみ。

10. クラスそれぞれには、自己を不正な状態
へ陥らせない「自己防衛責務」が備わっ
ていなければならない。
クラスが大きくなればなるほど考慮を要
する要素や影響範囲が広くなり、防衛責
務を果たすのが困難になる。
僅かな変更にも、非常に脆くなる。
クラスを1つ1つが確実に正常動作するよ
う、小さく、堅牢に設計することが肝要。

11. 最後に 命名と関心事の関係
名前は処理の在り処を識別するための単なる印ではない。
関心事のスコープ(範囲)を決定づける上で重要なもの。
「Manager」という命名は関心事の範囲が広すぎて曖昧で、「関心の分離」になんら貢献
しない。
関心事の範囲ひとつが小さくなるなるよう、意味が具体的で限定的な命名することが重
要。

12. その他「クソコード動画」で検索！

13. 動画のRTを
お願いします！！