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

Slide 1

Slide 1 text

クソコード動画「switch⽂」解説オブジェクト指向カンファレンス2020 2020年2⽉16(⽇) お茶の⽔⼥⼦⼤学 #ooc_2020 #ooc_e ミノ駆動 ( @MinoDriven )

Slide 2

Slide 2 text

この動画の解説です https://twitter.com/MinoDriven/status/1228896043435094016

Slide 3

Slide 3 text

レジュメ • ⾃⼰紹介 • 今回の元ネタ • 設計の話 • コミュニケーションの話 • まとめ

Slide 4

Slide 4 text

⾃⼰紹介 • ミノ駆動( @MinoDriven ) • ⼀昨年まではキヤノンの組込みエンジニア。 • Twitter転職で昨年よりクラウドワークス社のWebエンジニア。 • リファクタリング専⾨。巨⼤ RailsアプリをDDDベースで鋭意リファクタ中。 • TwitterではRPGツクールで制作したクソコード動画や⾵刺動画を投稿。 (←僕のアバターではなく、制作中ゲームの主要登場⼈物)

Slide 5

Slide 5 text

今回の元ネタチケット料⾦モデリング

Slide 6

Slide 6 text

何も考えずに動かすだけのコードを書くと、条件分岐だらけになって⾮常に複雑化するお題。複雑なドメインに対し、いかにシンプルに設計できるかが問われる。

Slide 7

Slide 7 text

設計の話

Slide 8

Slide 8 text

GoF Strategyパターン • switch⽂など条件分岐の重複解消に有⽤な設計パターン。 • 同⼀構造にStateパターンがあるが、映画チケットの場合インスタンス⽣成時に対応ロジックが確定するためStrategy。

Slide 9

Slide 9 text

今回のあるべき設計ここだけにswitch⽂を書く。条件に応じたチケットinterface実装クラスのインスタンスを返す。リスト操作をカプセル化するパターン。チケット.料⾦()の値を総計して返す合計⾦額()など定義可能。チケットinterfaceで抽象化してるため、何のチケットかswitch分岐せずに済む。シーズンを過ぎたら「シーズン限定」クラスだけ削除すれば良い。変更が容易。料⾦や座席は関⼼事が異なるが、その点の設計は割愛。

Slide 10

Slide 10 text

ソフトウェアと複雑さ • コンピュータは複雑な処理を、⾼速かつ正確に実⾏し、社会に恩恵をもたらしている。 • その⼀⽅で • DDD著者エヴァンス⽒「ソフトウェアの複雑さに⽴ち向かう」 • 増⽥亨⽒「複雑さとの戦いとは、即ち条件分岐との戦いである」 • 開発者には、ソフトウェアが破綻しないよう複雑さを解消したり、複雑さがもたらすリスクを低減する設計責務が求められる。 • 条件分岐が暴れ出さないよう封じ込める呪術(スキル)を⾝に着けよう。

Slide 11

Slide 11 text

【重要】安易にswitch⽂を書かない • switch⽂は、同じ条件のものが複数書かれがち(※程度の差はあれif⽂も同じことが⾔える)。 • 分岐が発⽣しそうだからといって、安易に即座に条件分岐を書くのは良くない。⼀旦落ち着くことが肝要。 • switch⽂を書きそうになったら、Strategy, Stateパターンで設計できないかを真っ先に検討すること。 • 何よりも、複雑さを解消、リスク低減する様々な設計⼿法を把握し、いつでも使いこなせるよう普段から素振りをしておくことが⼤事。

Slide 12

Slide 12 text

コミュニケーションの話

Slide 13

Slide 13 text

この動画、実は助かっていたかもしれないシーンがあります。どのシーンか、分かりますか？

Slide 14

Slide 14 text

クラスB,CがクラスAを無視したシーン

Slide 15

Slide 15 text

switch⽂に「家族」条件を追加し、不具合が発⽣した後、クラス Aが同じswitch⽂が書かれていることに驚くシーンがある。

Slide 16

Slide 16 text

もし彼らが適宜コミュニケーションを取りながら仕様変更に対応していれば、switch⽂の条件変更にすぐに気付き、対応の仕⽅も違っていたはず。

Slide 17

Slide 17 text

これは極端な例ですが… しかし私は20-30個近いswtichコピペコードを⾒たことがある。これだけ⼤量のコピペコードがあれば、さすがに皆異常に気付くはず。

Slide 18

Slide 18 text

まあ設計の知識がなければ結局こうなる(全部にcase⽂追加する) だけなんですが。

Slide 19

Slide 19 text

条件分岐こそチームで設計議論を • ソフトウェア開発とは複雑さとの戦い。条件分岐との戦い。 • チーム開発では、情報共有不⼗分が原因で、この動画のような事態が容易に起こりうる。 • ゆえに、条件分岐の箇所、特に分岐が複雑になりそうな箇所こそ、チームで集まって設計議論する必要がある。

Slide 20

Slide 20 text

コンウェイの法則 • この⽂⾯だけ⾒ると「設計構造が組織構造に似てくる」ように読める。 • 「あるソフトウェア開発において、チーム数の分だけ別々のパッケージが出来上がる」と多くでは⾔及されている。 • その通りではあるが、コンウェイの法則の事象のひとつに過ぎない。システムを設計する組織は、その構造をそっくり真似た構造の設計を⽣み出してしまう。

Slide 21

Slide 21 text

「エンジニアリング組織論への招待」では、コンウェイの法則における組織構造のことをコミュニケーションコスト構造と捉えている。

Slide 22

Slide 22 text

• この動画を例にすると、クラス B,Cらが意思疎通を拒絶。 • 意思疎通がなく、コミュニケーションコストが⾼い構造にある。 • これにより同じ条件のswitch⽂が量産される歪な構造になってしまった。 • 実際、コミュニケーションコストが⾼い組織ほどバグが多くなる傾向。

Slide 23

Slide 23 text

表⾯的な逆コンウェイ作戦は上⼿くいかない • 近年コンウェイの法則を逆⼿に取って、最適なアーキテクチャに合わせるようにチーム編成する「逆コンウェイ作戦」が考案されている。 • ただ、この逆コンウェイ作戦を表⾯だけなぞらえるのは良くない。ただチーム編成すれば良いというワケではない。 • チーム内でメンバーの関係が冷え切っていたり、コミュニケーションが分断されていると、設計実装の歩調が合わなくなり、この動画に類似する不具合は容易に起こりうる。

Slide 24

Slide 24 text

プロマネがすべきだったこと • 現場に丸投げするのではく、設計上の意思疎通を綿密に⾏うことを指⽰すべきだった。 • 意思疎通を円滑にするためにも、⼼理的安全性向上に取り組む必要があった(※無視やいじめの類の場合、労働契約法における職場環境配慮義務違反)。

Slide 25

Slide 25 text

設計は技術知識と意思疎通の両輪 • 仮にチームに設計スキルの⾼いメンバーがいても、意思共有が不⼗分だとそのメンバーの知⾒を活かすことができない。設計技術の効果が限定的になってしまう。 • とかく設計パターンや構造など技術知識が注⽬されがちだが、設計は、技術知識とコミュニケーションの両輪によって初めて成⽴する。

Slide 26

Slide 26 text

まとめ • 安易にswitch⽂を書かない。 • 複雑な条件分岐を解消したり、複雑さに伴うリスクを低減する設計⼿法、即ち条件分岐が暴れ出さない設計スキルを、いつでも使いこなせることが肝要。 • switch⽂や複雑な条件分岐が発⽣しそうな箇所は、チームで設計議論すること。 • チームの議論が成⽴するように、しっかりチームビルディングすること。⼼理的安全性向上に努めること。