クソコード動画「switch文」解説

オブジェクト指向カンファレンス2020での登壇資料です。
https://fortee.jp/object-oriented-conference-2020/proposal/b2dcff77-08af-4561-bcda-fc86e553ccec

Transcript

1. クソコード動画 「switch⽂」 解説 オブジェクト指向カンファレンス2020 2020年2⽉16(⽇) お茶の⽔⼥⼦⼤学 #ooc_2020 #ooc_e ミノ駆動 ( @MinoDriven )
2. この動画の解説です https://twitter.com/MinoDriven/status/1228896043435094016
3. レジュメ • ⾃⼰紹介 • 今回の元ネタ • 設計の話 • コミュニケーションの話 • まとめ
4. ⾃⼰紹介 • ミノ駆動( @MinoDriven ) • ⼀昨年まではキヤノンの組込み エンジニア。 • Twitter転職で昨年よりクラウド ワークス社のWebエンジニア。 • リファクタリング専⾨。巨⼤ RailsアプリをDDDベースで鋭意 リファクタ中。 • TwitterではRPGツクールで制作 したクソコード動画や⾵刺動画 を投稿。 (←僕のアバターではな く、制作中ゲームの主要 登場⼈物)
5. 今回の元ネタ チケット料⾦モデリング
6. 何も考えずに動かすだけのコードを書くと、条件分岐だらけになって ⾮常に複雑化するお題。 複雑なドメインに対し、いかにシンプルに設計できるかが問われる。
7. 設計の話
8. GoF Strategyパターン • switch⽂など条件分岐の重複解消に有⽤な設計パターン。 • 同⼀構造にStateパターンがあるが、映画チケットの場合イン スタンス⽣成時に対応ロジックが確定するためStrategy。
9. 今回のあるべき設計 ここだけにswitch⽂を書く。 条件に応じたチケットinterface実装 クラスのインスタンスを返す。 リスト操作をカプセル化 するパターン。 チケット.料⾦()の値を総 計して返す合計⾦額()な ど定義可能。 チケットinterfaceで抽象 化してるため、何のチ ケットかswitch分岐せず に済む。 シーズンを過ぎたら「シー ズン限定」クラスだけ削除 すれば良い。変更が容易。 料⾦や座席は関⼼事が異な るが、その点の設計は割愛。
10. ソフトウェアと複雑さ • コンピュータは複雑な処理を、⾼速かつ正 確に実⾏し、社会に恩恵をもたらしている。 • その⼀⽅で • DDD著者エヴァンス⽒「ソフトウェアの複雑さ に⽴ち向かう」 • 増⽥亨⽒「複雑さとの戦いとは、即ち条件分岐 との戦いである」 • 開発者には、ソフトウェアが破綻しないよ う複雑さを解消したり、複雑さがもたらす リスクを低減する設計責務が求められる。 • 条件分岐が暴れ出さないよう封じ込める呪 術(スキル)を⾝に着けよう。
11. 【重要】安易にswitch⽂を書かない • switch⽂は、同じ条件のものが複数書かれがち(※程度の差はあ れif⽂も同じことが⾔える)。 • 分岐が発⽣しそうだからといって、安易に即座に条件分岐を書 くのは良くない。⼀旦落ち着くことが肝要。 • switch⽂を書きそうになったら、Strategy, Stateパターンで設 計できないかを真っ先に検討すること。 • 何よりも、複雑さを解消、リスク低減する様々な設計⼿法を把 握し、いつでも使いこなせるよう普段から素振りをしておくこ とが⼤事。
12. コミュニケーションの話
13. この動画、実は助かっていたかもしれな いシーンがあります。 どのシーンか、分かりますか？
14. クラスB,CがクラスAを無視したシーン
15. switch⽂に「家族」条件を追加し、不具合が発⽣した後、クラス Aが同じswitch⽂が書かれていることに驚くシーンがある。
16. もし彼らが適宜コミュニケーションを取りながら 仕様変更に対応していれば、switch⽂の条件変更 にすぐに気付き、対応の仕⽅も違っていたはず。
17. これは極端な例ですが… しかし私は20-30個近いswtichコピペコードを⾒たことがある。 これだけ⼤量のコピペコードがあれば、さすがに皆異常に気付くはず。
18. まあ設計の知識がなければ結局こうなる(全部にcase⽂追加する) だけなんですが。
19. 条件分岐こそチームで設計議論を • ソフトウェア開発とは複雑さとの戦い。条件分岐との戦い。 • チーム開発では、情報共有不⼗分が原因で、この動画のような 事態が容易に起こりうる。 • ゆえに、条件分岐の箇所、特に分岐が複雑になりそうな箇所こ そ、チームで集まって設計議論する必要がある。
20. コンウェイの法則 • この⽂⾯だけ⾒ると「設計構造が組織構造に似てくる」ように 読める。 • 「あるソフトウェア開発において、チーム数の分だけ別々の パッケージが出来上がる」と多くでは⾔及されている。 • その通りではあるが、コンウェイの法則の事象のひとつに過ぎ ない。 システムを設計する組織は、その構造をそっくり真似 た構造の設計を⽣み出してしまう。
21. 「エンジニアリング組織論への 招待」では、コンウェイの法則 における組織構造のことをコ ミュニケーションコスト構造と 捉えている。
22. • この動画を例にすると、クラス B,Cらが意思疎通を拒絶。 • 意思疎通がなく、コミュニケー ションコストが⾼い構造にある。 • これにより同じ条件のswitch⽂ が量産される歪な構造になって しまった。 • 実際、コミュニケーションコス トが⾼い組織ほどバグが多くな る傾向。
23. 表⾯的な逆コンウェイ作戦は上⼿くいかない • 近年コンウェイの法則を逆⼿に取って、最適なアーキテクチャ に合わせるようにチーム編成する「逆コンウェイ作戦」が考案 されている。 • ただ、この逆コンウェイ作戦を表⾯だけなぞらえるのは良くな い。ただチーム編成すれば良いというワケではない。 • チーム内でメンバーの関係が冷え切っていたり、コミュニケー ションが分断されていると、設計実装の歩調が合わなくなり、 この動画に類似する不具合は容易に起こりうる。
24. プロマネがすべきだったこと • 現場に丸投げするのではく、設計 上の意思疎通を綿密に⾏うことを 指⽰すべきだった。 • 意思疎通を円滑にするためにも、 ⼼理的安全性向上に取り組む必要 があった(※無視やいじめの類の 場合、労働契約法における職場環 境配慮義務違反)。
25. 設計は技術知識と意思疎通の両輪 • 仮にチームに設計スキルの⾼いメンバーがいても、意思共有が 不⼗分だとそのメンバーの知⾒を活かすことができない。設計 技術の効果が限定的になってしまう。 • とかく設計パターンや構造など技術知識が注⽬されがちだが、 設計は、技術知識とコミュニケーションの両輪によって初めて 成⽴する。
26. まとめ • 安易にswitch⽂を書かない。 • 複雑な条件分岐を解消したり、複雑さに伴うリスクを低減する 設計⼿法、即ち条件分岐が暴れ出さない設計スキルを、いつで も使いこなせることが肝要。 • switch⽂や複雑な条件分岐が発⽣しそうな箇所は、チームで設 計議論すること。 • チームの議論が成⽴するように、しっかりチームビルディング すること。⼼理的安全性向上に努めること。