「テストなんか書かなくて良い 僕の考えるサービス開発の肝」という記事を読んだ。 「ほぼ同意」な内容だった
まず第一に、サービスの主役はユーザーであり、その他の話は大体些細だ。 「事業計画がどうこう」「偉い人が」「新しい技術を試したい」「マネタイズが」「綺麗なコードを」その大体が些細だ。
それはそう。 ただし、その「ユーザ」を不足なく列挙できてるのか？は、ちゃんと議論したほうがいいよ。
元の記事が「サービス開発」を対象としているので、それはそうって感じ。
俺はサービスなんて大して興味ないので、知らん。 サービスについて考えるってことはしなくもないし、企画会議への出席を断ったりはしないが、積極的に企画を出すことはしないし、できない。 そもそも 0 から 1 を作るのが苦手というか、無理なので。 推敲するフェーズになったら呼んでくれ。
開発スピードより優先するものはほとんどない。 開発スピードと”品質”は両立できる。
ほんとにこれ。 ただし、品質を維持する努力が必要だし、品質が維持できてないと開発スピードも落ちる。
両立できる とかって話じゃなくて、そもそも「開発スピード」と「品質」は “正の相関” の関係にある。
それはそうなんだけど、ヒューマンマネジメントの都合ってのもある。 エンジニアのモチベを維持する手段として、適度にオナニーをする機会を与える ってのもアリだからね。
まぁ、（オナニーという比喩表現に掛けて）所構わずオナニーしてるような公然わいせつを犯す犯罪者は、チームから追放すべきなので。
オナニーチェックリスト は有用。
開発をすると、ほぼ確実にコードへ変更・追加・削除が発生する。 その際に、「意図せずぶっ壊していないか」を確認するために継続的にインテグレーションするが、専らそのために書いたものをコミットに含める。
別に他の目的（「安心感を得るため」など）で書いて実行するのはよいが、それを CI に乗せる（＝コミットに含める）と、変更時にテストの方がぶっ壊れるので、開発スピードが落ちる。つまり、「CI 以外の目的で書いたテストをコミットに含める」という行為は、コードに品質を下げている、ということ。
正しく CI のために書かれたテストコードってのは、機能仕様書とみなすことができる。 使う側へ提供する情報（ドキュメントにかかれているべき情報）って、それだけで十分だと思うのだけれど、どう？
「テストの独立性が」「振る舞いで書く」とか色々だ。やってもいいけど時間はかけないでくれ。
ミスって CI 以外の目的で書かれているコード（行、式 などの小さな粒度）が含まれちゃた場合に、テストコードを是正する必要があるわけれど、そのときに時間をかけたくないので、「テストの独立性を保つ」とか「振る舞いで書く」ってことをする。 ただし、飽く迄も保険であって、本質ではないので、余計に多くの時間がかかるのなら、やめろ。 「書くときに意識する」程度にしておけ。
「git コミットの分割とコミットメッセージにこだわるな」ってのは、「イチコミットの粒度」や「コミットメッセージの書式」などのどうでも良いことにこだわるな、という話だと思う。 たしかに、そういうどうでもよいことにこだわリすぎるのは、オナニーなので、ほどほどにしてほしい。
コード読んでわからないような話ならソースにコメントとか残しておけば良い。
書いた人に聞けば事足りることも多いし。
ダウト。
マーフィの法則に近しいが、「聞きたいことがあるときに、それを聞ける相手はいない」。 書いた人がいることは稀だし、聞いたところで、書いた本人が覚えているわけがない。 少なくとも自分は過去の自分が書いたコードについて質問されても、答えることはできない。そのときの俺に聞いてくれ。今の俺にはわからん。
というのが常なので、将来必要になりそうな情報は、過剰気味で良いので、Pull Request のコメントに書くべき。
気持ちはわかるが家でやろう。要件を満たせて、チームが最適に能力を発揮できる言語を選ぶべきだ。
完全に同意。
元記事からも言及されているけれど、ウェブアプリケーション開発に新言語を採用したときにインフラで考えることってのは多い。
初めの段階で過剰にこだわるよりも、そこそこにしてさっさと価値を届けることの方が事業としては大事かもしれない。どうせ新規事業なんてほとんど当たらないんだから。
同意。
でも、
スピードと安定性はトレードオフなんだから。
はびみょい。 スピードと安定性は独立できるし、トレードオフにならないようにするのが私の得意分野（というか仕事）なので。
「サービスのバグのなさに過剰にこだわる」も同じ。
prettier や ESLint にやらせろ。
人間がやる分野ではない。
ただし、「やりすぎぐらいが丁度いい」。
最後の方は、飽きてきて、雑になったな…。