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