テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog

世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える

[sue445]

テストが「リファクタや機能追加の邪魔になる」には同意できない（リファクタや機能追加で既存機能が壊れてないことを保証するのがテストでは？）

[taguch1]

ほとんどの現場はオーバーエンジニアリングでなくて、そもそもエンジニアリングが足りてない。

[mizchi]

気持ちはわかるんだけども、この言葉は殆どのケースで糞コードを書く後付の方便として使われてるのが問題

[escape_artist]

いいんだけどさー、テスト書いたことない人が「同意する！」って言ってるのを見るとムカつく。

[zentarou]

これは、「普通に」コードの品質が高くて「普通に」テストもドキュメントも書いてるプロジェクトが過剰に品質求めないようにしよう、ってことだから、ダメエンジニアが真似しちゃダメだよ☆

[msuhara]

まったく同意できない。最初の実装はその後の開発に大きく影響する。些細なものとして残された技術的負債を抱えるサービスを、改修している開発者がいることも忘れないで。

[stealthinu]

結局はバランスの問題とは思うのだけど大概の場合テストや文書のほうが足りてない世界のほうで暮らしてきたからそっちをやり過ぎて弊害が起きてる世界線もあるんだな…という気持ちになった。ほんとにあんの？

[iwaim]

サービス立ち上げの話なのでほぼ同意。ただし「後でテストを書きやすいコードにしておく」ということがとても大事。コントローラーにがっつりビジネスロジックがあるコードとかだと変化速度についていけなくて死ぬ。

[sho]

過激なつもりらしいが事実上「極端なことを求めるな」としか言ってない。そんなのあたりまえやん。

[rryu]

テストコード書かなくていいという人は手動で動作確認するのが好きなだけでテストしていないわけじゃあないんだよな。

[koheisg]

スピード高めるためにテスト書かなくていい理論とテスト書いておいた方が回り回ってテスト書く方がいい理論。この中間がTDD is dead理論かしら。

[okinaka]

スピードとコストのバランスをどう調整するかが悩みどころ。それ以外は大した問題ではない。

[operando]

すごく今の開発に当てはまる部分があり考えさせられる

[niship_0822]

“サービスの安定性に過剰にこだわる サービスのバグのなさに過剰にこだわる” この辺はむしろ顧客（ユーザではなく）のほうが異常にこだわるところなんだよなぁ

[sugimori]

タイトルほど極端ではなかった

[sylvan_l]

テストなんか書かなくて良い　僕の考えるサービス開発の肝

[dmizuno55]

“この記事”

[mmorita44]

モジュールを意識して設計すれば後々利用できる。そもそもソースコードの破棄が保障されるなら良いが、使い回されるならばテストケース必須。

[k-motoyan888]

開発スピードを妨げるもの＝テスト書かないこと、だと思っているのだが。ユニットテストレベルなら中級以上のエンジニアはスピード落ちるどころか上がるでしょと思う。

[nekoruri]

心情としては共感するけど記事としては有害だよなあｗｗｗ

[mikage014]

"もちろん開発効率化のためや、複雑な部分の必要なテストは書いてもいい。大事なのはその見極めだ"

[moondoldo]

開発

[rarere]

“（余談だけど僕はソシャゲは不安定で侘び石がもらえる方が嬉しい）”んだんだ

[surume000]

同意

[src256]

たしかに手段と目的が逆転したら意味がないかも。

[cats_nukui]

キモにめいじましょう。

[raydive]

テストうんぬんかんぬんのお話はここが起点か。言ってる内容は妥当（品質と他の関心事のバランス大事）だと思うけど、タイトルは最悪ですね。

[ooblog]

#時短経済 「API~認証フロー等~必要なテストは書いてもいい~理由がなければテストを書いてはいけない~メソッド名変更などに対応~機能追加の邪魔~1日で新機能のプロト~ダメなら廃棄、そういう時間軸で生きている」

[uturi]

とにかくスピードが求められる業界の話で、自分にとっては異世界の話。ガッツリレビューして丁寧にテストしてようやくリリースとって文化とは真逆。事故を起こしながらも減速できないダンプカーは大変そう。

[akahigeg]

タイトルで心がザラッとしたけど、読んでみれば正論。

[tackman]

Gunosyの人がどうの火元はこれか。本文は正論書いてるだけだけど、そこからタイトル文は導けないし導いちゃいけないという114514周くらいした議論ですね

[roshi]

いいサービスを作りたいからいいコードを書くわけで、いいコードを書いたらいいサービスになるわけではないってことなのかと。

[rzi]

まさに理想。憧れる

[peccu]

何事も極端にせずチームに合わせてやればよい / テストなんか書かなくて良い　僕の考えるサービス開発の肝 - mosa_siru’s blog

[fgshun]

タイトルで損している

[slash_01]

言ってることは理解できる。

[muratayusuke]

自分も最初はテスト一切書かずにガリガリ機能だけ作る。1人でも仕事で1ヶ月も作ればある程度コードがでかくなってデグレが辛くなってくるからそこで初めて正常系のテストだけ書く感じ

[zetta1985]

テスト無しでリファクタするの怖い > “過度なテストは書く時間の無駄なだけでなく、リファクタや機能追加の邪魔になる”

[otchy210]

最初の “中級以上のエンジニア向け” が全て、という記事。ほっといても、そこそこ可読性があり、そこそこ安定し、適度なコメントとテストを含むコードを書ける人 "だけ" の集まりで、このやり方が生きる。