自分の開発スピードを上げるには

新しい機能なりサービスを作った後に振り返ってみると、もっと上手くやれた気がするなーって思う。
もっと早く、質の良いものを作るにはどうすれば良いのか。
そもそも開発とひとことで言っても、細かくどういうポイントを気にしておく必要があるか、そしてそのどこを改善できそうか考えてみた。

仕様決め

  • それを作る理由について納得しているか

    • 納得してないとか、そもそも背景を理解してない状態で仕様決めに入るのはかなり厳しい。
    • システムとしてだけでなくて、ビジネス的にそれってどうなんですかっていうのは質問して納得しておきたい。
      • とはいえ腰の重い開発者にはなりたくないので柔軟に。
  • 解決したい課題が明確になっているか

    • 最初は何か課題があるはずだけど、それをすっ飛ばして具体的な解決方法から話が始まる事がわりとある。
      • 実は別の方法が良かったりするかもしれないので、解決したい課題は何なのか明確にしておきたい。
  • 誰が最終的に決定するのか

    • 発散はしても良いけど最後決める人がいないとなかなか固まらなくてやきもきする。
    • 特に関係者が増えると本当に決まらないので、誰が決める人なのかってのはちゃんと認識合わせておきたい。
  • 優先順位の高いものはどれか

    • 規模が小さければ一気に作っちゃうのだけど、規模が大きい場合は一気に全部作ろうとしないで重要なものから作って出来たところから出していった方が良い。
    • 優先順位の低いものは本当に必要かもわかってなかったりするので最初から詳細まで詰めなくても良い。
    • いつまでにどこまで出したいかは確認しておく。
  • そもそも現状の仕様がどうなっているかをシステムレベルで把握しているか

    • そもそもの前提が間違っていたりすると議論が全くの無駄になることも。
    • 把握してない状態で課題に対しての解決案を提示するのは結構難しい。

設計

  • 既存に引っ張られすぎていないか

    • 既存がこうだからそれを踏襲していく形で考えてしまいがちだが、そこに縛られすぎずに本来どうあるべきかを考えてみる。
      • 時間的制約などにより結果的に理想の形を取れなくても、チーム内で理想の形は共有しておきたい。
  • それはそのモデルやサービスの責務か

    • 責務を超えた事をやらせていたり、隠蔽しておきたい知識・概念がその範囲外に流出してしまうのは避けたい。
      • ここが自分にとっては結構難しくて、もっと上手くやりたいところ。
        • あしがかりになりそうな DDD の知識を学びたい。
  • なぜその名前付けをしたのかを説明できるか

    • 名前重要ってのは最近本当に感じてて、でもいつも結構悩むんだけど、これは何かのサインなのか。

実装

  • 集中できているか

    • とにかく実装は集中してやっているかどうかで掛かる時間が何倍も変わるので、自分が集中している状態にい続けられるように気を遣う。
    • 詳細な実装方法で迷ったりする時は実際に書いて見比べる方がイメージしやすくて、書いたコードを見てみると意外と悪くないねという感じになる事も多い。
  • テストコードを書く事に時間がかかってないか

    • プロダクションコード書くよりテストコード書く時間の方が長くなりがち。
      • ここはもう少し改善できそう。
      • テストについては何か一冊本でも読んで学ぶと良さそう。
  • コードレビューしやすい PR になっているか

    • レビュアーが気になりそうなポイントは、先に PR の Description に書いておく。
      • ただ、Description が長過ぎると重い感じになるので、コードやコミットメッセージなどで明らかにわかることは書かないことにしてる。
    • 1つの PR が大きくなり過ぎたら分けられないか考える。
      • 1つの PR でだいたい変更が 200行くらいまでにした方が見やすくてレビュアーの負担も少ないと思う。
    • 意味の単位でコミット分ける。
      • コミット単位で見てくれる人もいるので、その人に意図が伝わるように書くと、将来 commit log 見直した時にも意図が分かりやすかったりする。
        • 1行目: 要約
        • 2行目: 空行
        • 3行目: 理由含めた説明
  • リリースタイミングを考えられているか

    • なるべく出来たものから出していきたい。
    • db migration があるものはタイミング気をつける。

検証

  • 検証環境特有の問題を取り除けているか
    • 大体時間が掛かるのは、実際に検証したい箇所ではなくて、何か設定の差異等によるつまらない問題である事が多い。
      • 特に他チームのサービスとのインターフェース部分は、開発環境では普段モックしていたりするので、そういう問題がよく起きがち。
        • そういう問題は起きないように改善するのはもちろんだし、認識してるのであれば事前に取り除いておきたい。

まとめ

改めてまとめてみると、改善できそうなところが見えてきた気がする。
DDD の本とテストの本を読まねば。