テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話

「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも

[t-wada]

釣りタイトルが残念。問題は事業の段階に即していない形骸化した開発プロセスや指標の運用にあるので、別の道具でも結果は芳しくないだろうと思います。テストのコピペも悪い（プロダクトコードの10倍は多すぎる）

[natu3kan]

FGOみたいに、最初は設計が雑でキャッシュ消すとセーブデータが消えたりとかドタバタしても利益が出て、今も慢性的な問題が残ってはいるが、改良しつつ動いてるみたいなのはあるから、大量の利益は七難を隠すと思う。

[jralove]

アジャイルおじさんとCICDおじさんがいて、手段が目的化するという悪い例ですね。

[roshi]

"きれいな開発"を信じてる方は他のやり方に攻撃的な嫌悪感を持ってるのも輪をかけてつらい（もちろん正しいのは理解してるが）

[monorod]

テスト駆動開発でカバレッジ気にし出すとヤバいよなー。というかそれはテスト駆動開発じゃない

[KoshianX]

正しいやり方に固執して改善のサイクルが回せないようなら意味はないわねえ。むしろ改善のサイクルをスムーズに回すための手法でしょうに。

[essa]

TDDもマイクロサービスもアジャイルがベースで、対話によるプロセス改善がないのはアジャイルではない。2000年の時点で既にプロセス自身の適応性について言及がある http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html#A51

[wkubota]

タイトルは釣りなんだと思うけど、もし本当に"テスト駆動開発とマイクロサービスのせい"とおもっているなら別の失敗をしそうですね・・・。YAGNIも分かるけどTDDを必要になってからは辛そう。

[uehaj]

マイクロサービスについては分割が悪いぽい。「APIが5つのマイクロサービスに分割されさらにそれぞれのサービスから共通に使えそうな部分が約40モジュールとして分離」そういう共通化はサービス分割の意味を薄める

[su_zu_ki_1010]

タイトル詐欺だけど、要はちゃんとした知識がない人が付け焼刃な知識でテスト駆動開発！マイクロサービス！と取り入れちゃうと辛いことになるよという実例だった。

[mapawata]

これはよくわかる。結局綺麗なシステムが受けるサービスとは限らない、ということだ。

[sokobaka]

雑だけど高速な開発が出来る凄腕が去って、半可通ばかりになるとこんな感じになりがちな気がします

[rushow]

状況に応じた例外が許されないワークフローや駆動開発は、柔軟性を要するプロジェクトとは相性が悪いよね / リーン過ぎてひどいソシャゲも結構あったけどなｗ

[daichirata]

本文読めないから分かんないけどソーシャルゲームトラフィックの割にトランザクションが結構きついからマイクロサービスあんまり向いてない。やってギルドとかそういうのを切り出すくらい

[kei_0000]

教科書の知識と、現場のニーズとのバランスが取れていない例。学者的な意味で頭が良いだけの人は、理論の美しさに惹かれて現状分析をおろそかにしてしまいがち。程よく経験知も取り入れたい。

[innx_hidenori]

記事へのツッコミはさておき、「マイクロサービスは規模が大きくなってからでも遅くない」はどれくらい事実や経験に基づいた説なのか知りたい。

[daybeforeyesterday]

うーむ

[ptpadan]

TDDってこういうことだったっけ？

[koroharo]

このやり方決めた人がSIer出身だったりするんじゃないかな。SIerの開発ではとんでもないポンコツがそれなりの確率でいるので、これくらいやりたくなる気持ちは分からんでもない。

[raamen07]

開発メンバー2人くらいの新規プロジェクトにアレもコレもとモダンな取り組みを入れる必要はあんまりないんだよね。大事なのは負債をちゃんと見える化して、後でちゃんと直す事を約束を握る事。

[yumu19]

ふむ。

[toro-chan]

単体テストはいまだにどのぐらい作成していいか悩む。いつやっても正解にたどり着いた気がしない。今のところ定式化できてるわけでもないし、経験っても状況で変わるしな。。

[kwhrtsk]

このケースでマイクロサービスは、牛刀を持って鶏を割くですね。テスト駆動開発については下手なだけ。Code to Test Ratioが1:10は多すぎる。皮肉にもテストのコピペがニュージャージー式で状況を悪化させている。

[gabari]

せいではない気がするが。テストしたいならブランチで遊べばいいだろうに、と思うし、結局YAGNIとのバランスが取れなかっただけ/テスト駆動とかしたくない人々が我が意を得たみたいなコメントに溢れてるのが面白い

[hamlet-r]

テストコードにしても、コードレビューにしても、どんなリスクに対するヘッジなのか、冷静に考えてみればいいのにね。あと、複雑にすれば正しいとか、無駄を排除すれば悪いとか、言葉のセンスが何か変だよ。

[char_c3]

TDDとかCI/CDをするのは、承認フローを最低限にしてガシガシコード書いてさっさとリリースするためなのに、それが目的になってしまうとやばいという話

[kagerou_ts]

まあヘルプ的立場んならニュージャージーとかYAGNIとか好きに言っとりゃええんやろうけどな。今時のサービスはそのコードに互換性保ちながら付け足し付け足し一年二年と動かしてくんやで。

[mikage014]

Keep it simple, stupid. だ。

[yujimi-daifuku-2222]

プログラム開発に限りませんが、「念の為」丁寧に進める方法論の弊害は確実に存在します。ただそれは語られ難いんですよ。失敗したら責任取れるのかと言われたら、大抵の場合黙らざるを得ませんから。

[securecat]

ところでディスガイアRPGってどんくらいテストしてたんだろう。テスト用の最強キャラが最初からフレンドにいて誰でも1時間もあればコンプリートできるっていうくらいのテストだったようだけど。

[rryu]

プロトタイプを作るのにそんなに重厚なプロセスを使ってはいけないというだけなような。

[k-takahashi]

TDDとマイクロサービスの適用失敗例。ただ、それが主原因ではなさそうな案件だし、逆パターンも山のようにあるだろうとは思う。

[technopocket]

テスト駆動開発とマイクロサービスのせいではなく単純にプロセスの問題。ゲームに関しては「実際に動かして面白いかどうか」という試行錯誤重要で、そういう事をしやすいプロセスや環境を作る事が重要。

[chinpokomon_master]

タイトル詐欺ではないと思うよ。テスト駆動もマイクロサービスも初期は不要。エンジニアは自分の道具を神性化しすぎなんだよね。

[kita-tuba]

こんにゃくゼリーは、悪くない

[hogeaegxa]

ツールとプロセスの導入と利用が主目的になって何よりも大事な製品として形にするってのが二の次だったんだな。高いのは意識だけで業務と遊びの違いが分からなかったか

[Dolpen]

サービス境界の定義失敗してサービス外まで巻き込まないとテストできなく/書けなくなった結果に見える…

[w1234567]

無駄なテストコードやマイクロサービスの有無に関わらずスマホゲームの開発は大体コケてるから安心しろ

[el-condor]

この失敗の主因は、プロダクト設計的にはMVPの不在と初期スコープの過剰、システム設計的にはサブシステム境界に関する設計の不味さで、モノリスでも普通に破綻する奴だと思う。

[nunulk]

なんで「確率に影響を与えるようにする機能」の追加で「特にテストコードで激しくコンフリクトして」しまうのかがちょっと想像できないので、他にも色々「○○のせい」があるかもってちょっと思ったり