を書いてみる気分
今日の時点での自分のやり方なので、またしばらくすると変わってるかもしれない
僕には、最初に考えたとおりに実装できるようなスキルがないので
コードを書きながら形にしていく感じ
サイズ
だいたい、チケット一枚が、5,6時間で実装できるくらいのサイズになってる
2,3日くらいでレビューまで終わって本番にデプロイすることが多いかな
（基本的にはそれくらいってだけで、1,2週間くらいかかるような長いやつもある）
技術的なフィージビリティチェックとかはこの前に終わってる
実装を頭に思い浮かべる
こんなふうにすれば良さそうかなぁ
このあたりは何パターンか考えられるけどどっちがいいかなぁ
とか頭の中に思い浮かべる
とりあえず動くものを実装
まずは思い浮かべたものが全部つながって動くかをサクッと確認したいので雑に実装する
そして、気づくことがいくつかある
あれ？この場合どうなるんだろう？って仕様のことだったり
使ってみて初めて気づくライブラリのくせだったり
その辺りをつぶしていく
いったん見てもらう
ざっくりと方針が見える状態になってるので
ペアに見てもらったり、プルリクエストをドラフトで出して意見をもらったり
悩んでる部分があったらここで相談しておく
色々仕上げてからよりこの時点で意見をもらっておくほうが楽
これが終わるとだいたいチーム内での認識はそろった状態になる
小さく分割する
読みやすくなるように
ユニットテストしやすいように
小さい関数に分割していく
コードを捨てたりもする
この時点で、いちどコードを全部捨ててしまって、それを見ながら新しく書き直すこともある
変更が大きくなったときとかは、レビューしやすいように小さい単位に分割したりとか
分割するときは、デプロイできる単位で分割する
ログとかエラーハンドリングを入れる
このへんでも気づくことがたくさんある
「あれ？このエラーどう処理する？」って仕様レベルの相談とか
「何か問題があったときにこのログがある方がいいね」とか「メトリクスいるね」とか
そんなこんなで、けっこう、構造に影響がある
なのでこれを後からやろうとすると、ちょっと大変
部品のユニットテストをかく
ここまででも、ちょこちょこユニットテストを書いてたりはするんだけど
部品の関数に対して、ここで細かいケースを書いて仕上げていく
テストしなくても大丈夫だろうってようなやつも、やってみたら「あぁ、思ってたんとちがった！」みたいなのがあるからやめられないｗ
メインの関数のユニットテストをかく
部品が思ったとおりに動くことが分かってるので
あとは組み合わせて全体が思ったとおりに動くことを確認する
部品のユニットテストを見直す
メインの関数のテストの書きやすさによるけど
もし、そっちで部品のユニットテストも十分にカバーできてたら、部品のユニットテストは削除してしまう
もし、メインの関数のテストが書きにくい場合は、そっちは少なめにして、部品のユニットテストでカバーしたままにしておく
リファクタリングをする
テストが通る状態で、名前を考えたり、置き場所を考えたり
こっちがいいかなあっちがいいかなとか、置いてみて、ちょっと遠くから眺めてみたり
プロダクションコード側のリファクタリングが終わったら
テストコードもリファクタリングしてコーディングは終わり
end-to-end で動作確認
ここまでもちょこちょこ end-to-end で確認したりはしてるけど
ここでしっかり確認しておく
プルリクエストを出す
ドラフトのプルリクエストに変更をプッシュして Ready for review にしたり
新しくプルリクエストを作り直したり
で、みんなにみてもらって意見をもらってマージ
本番環境で確認
そしたら本番環境にデプロイされるので、本番環境で確認して
おしまい
完全にこの流れってわけじゃなくて、こんな感じの流れを気分でいったりきたりしながらコードを書いてる
いまはこんな感じかな
