元ネタ
テストなんか書かなくて良い 僕の考えるサービス開発の肝
http://mosa-siru.hatenablog.com/entry/2016/03/06/173930
色々と興味深いので乗っかってみる(笑
いつも以上に、完全に「好奇心のみ」ですｗ
以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。
多分「少人数」ってのが一つのキモなんだろうなぁ、と推測。
基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。
これが「IT系エンジニア全体」という母数の何割くらいなのかに興味がゲフンゴフンガフン
まず第一に、サービスの主役はユーザーであり、その他の話は大体些細だ。
「事業計画がどうこう」「偉い人が」「新しい技術を試したい」「マネタイズが」「綺麗なコードを」その大体が些細だ。
マネタイズだけは、あんまり「些細」とは言えないおいちゃんがいる(苦笑
ただまぁそれ以外についてはある程度Yes。
サービス開発におけるプレイヤーの役割を「企画」「デザイナー」「エンジニア」などとざっくり分けるなら、企画（要件決め）が最も大事だ。企画がクソなものをどんなに上手く作ってもクソだからだ。
だから「俺はエンジニアだから言われたものを作る」とかは態度としてありえない。（スペシャリストなら別だけど、スペシャリストほどなぜかこういう態度はとらないものだ。）
サービスの成功を考えるなら立場によらず最も肝である企画フェーズからどんどん意見すべきで、開発工数的にコスパが合わないと思ったらどんどん代替案を提示すべきだ。
「俺はエンジニアだから言われたものを作る」は「防御姿勢に入った時」の常套句ではありますなぁ。
なのでまぁ「エンジニアに防御姿勢を取らせないこと」ってのは大事なのだけど。
その辺は、いわゆる「企画屋さん」の懐がどれくらい広くてどれくらい狭くてどれくらい破たんしているか？ によるんじゃないかなぁ、などと。
（話は逸れるけれど、設計にはドメイン知識と未来予知のスキルが必要で、「ここはきっとこう要件が変わる可能性があるからこうしとくか」だとかの温度感が掴めないとロクなものができない）
ここは微妙。
「ここはこう変わる可能性がある」をあんまり先読みしすぎると、大変に「もわっとした」イヤンな設計になることも多々。
YAGNIとかいうぢゃん。
おいちゃんとしては「隙間があって 隙のない設計( http://d.hatena.ne.jp/gallu/20100506/p1 )」ってのが一番お好みかなぁ。これだと、要件が「実際に変わったら」どうにかできる可能性が圧倒的に上がるので。
開発スピードより優先するものはほとんどない。
開発スピードと"品質"は両立できる。さっさと作って、触ってみてイケてないところを直して、リリースして数字や反応をみて直して─── サービス開発はその繰り返しだ。
多少条件付きではあるにしても、Yes。
一つは「触ってみてイケてないところを直して」ができる程度のコード品質であることと、時間のマージンをちゃんととっていること。
後は「常に何割かは品質向上のための学習に己の工数をぶっこんでる」こと。そのためには「知ってる」じゃなくて「使える」ところまで、スキルを磨いていること( http://d.hatena.ne.jp/gallu/20150319/p1 )。
僕らが作っているのはサービスだ。どんなにコードが綺麗で、カバレッジが100%だろうと、使われないサービスだったらそれは残念ながら意味のないコードだ。
僕らがコミットするべきはサービスの"質"とユーザーへの価値であって、コードの綺麗さではない。全くない。 サービスはユーザーに価値を提供するものであって、エンジニアがオナニーする場所ではない。
ここはたぶん、議論が紛糾するだろうなぁ、と思う箇所の一つ(笑
「僕らがコミットするべきはサービスの"質"とユーザーへの価値であって、コードの綺麗さではない。全くない。」「コードの綺麗さではない。全くない。」「コードの綺麗さではない」。
「どこまでの汚いコードなら許容可能なんだろう？」っていうあたりの予想と妄想と経験と後悔と血と汗と涙と怒号の有無で、この辺の印象値は大分と異なるんじゃないかなぁ？ と。
おいちゃんはどちらかというと「メンテ不能に近い」ようなレベルのコードを一定量見ているので*1、コミットするべきものの１つとして「コードの(ある程度の)綺麗さ」を求めるかなぁ。
だって「触ってみてイケてないところを直……せない！！」では、さっきの話が瓦解するんですもの(苦笑
カバレッジ100%を求める
ドキュメントを完全に書こうとする
テストコードの綺麗さや品質にやけにこだわる
gitコミットの分割とコミットメッセージにこだわる
「やってみたいから」で言語やフレームワークを選ぶ
サービスの安定性に過剰にこだわる
サービスのバグのなさに過剰にこだわる
コードの（見た目の）綺麗さにやけにこだわる
コードレビューフローが整備されすぎている
全体的に「程度問題」。
あとは「「やってみたいから」で言語やフレームワークを選ぶ」あたりが、メンバーによっては「モチベーションと後々の広告につながるから幾分重要視する」くらいかなぁ。
それでもなお
命名にこだわる
効率化のためにテストを書く
が「やっておいた方が良いかなと思うもの」になるんだから、「命名」と「ある程度のテスト」は重要なんだなぁ、と、改めてしみじみ。
カバレッジ100%を求める
とりあえず疑問なんだけど、このカバレッジってCなんぼ？
C0であるのだとすると、C0はできれば100%ないしそれに近しいほうが安全だと思うなぁ。「あんまり特殊な例外」とかはいったん放置もあり得るので「近しい」程度にしておくけど。
C1とかC2とかだとまたお話が違うので省略。
結局
もちろん開発効率化のためや、複雑な部分の必要なテストは書いてもいい。大事なのはその見極めだ。
ここにつながる。
ドキュメントを完全に書こうとする
これも程度問題。
とか書いてあるので、まぁおいちゃんと感覚的には同じくらいじゃないかなぁ、っと。
ここで言ってるのは、内部の処理フローを完全に書くとかそういうレベルの話だ。
で。ほんの10年弱くらい前に「仕様書をもっとたくさんかけ」といわれて「じゃぁ何が欲しいんだね？」と聞いたときに「たとえば変数一覧とか」って言われた時の驚きを、ぜひ、あなたにも届けたいｗ
テストコードの綺麗さや品質にやけにこだわる
こだわった記憶がないのでオミットｗ
gitコミットの分割とコミットメッセージにこだわる
これもこだわった記憶なしｗ
まぁ「コミットの分割」は、ありかなぁ、と思うけど。「１機能の追加修正ごとにcommitはしといてね」的な。
「やってみたいから」で言語やフレームワークを選ぶ
気持ちはわかるが家でやろう。
これはまぁこの一言に尽きるｗ
サービスの安定性に過剰にこだわる
最近あんまり見なくなったなぁ。
「サービスの100%稼働を安価に」とかいう頓狂な案件が、以前はそこそこあったんだけど。
サービスのバグのなさに過剰にこだわる
まぁないほうがいいんだろうけどねぇ。
致命的なモンでなければ「すぐに修正できる」ほうが価値は高いと思うなぁ。
コードの（見た目の）綺麗さにやけにこだわる
時々「見た目は綺麗なんだけど設計がおお汚い」とか見かけて色々と(苦笑
コードレビューフローが整備されすぎている
見たことがないｗ
結論は
「どんな手法もメリット・デメリットがあるんだから、現場のフェーズやプロダクトに合わせて捨てられるものは捨てて、自己満足もやめて、コトに向かおう」ということだ。
という………うん至極まっとうすぎて「なんもいえねぇ」状態(笑
ただまぁ、じゃぁ「どこまでが必要で、どこからが自己満足なのか？」っていうあたりで色々と考えたり議論したりするんだろうなぁ、っと。
後は、初手にも書いてあった通り「中級エンジニアの群れ」でのお話なので。
そもそもそこに「異物が混ざってる」とか「異物だらけ」とかだと、また、異なった方法論が必要なんだろうなぁ、とか(苦笑
そーゆー意味で。
読み手とその周囲が「一通り中級以上」という、おいちゃんにとっては「桃源郷のような」状態が前提なんだろうなぁ、とか、色々と思うところ ありおりはべり いまそかり(苦笑
*1:引きが強いとか言うな
