見出し画像

個人開発では得られにくい!実務を通して得たプロダクト開発の知見5つ

こんにちは!はっさんです!

最近は仕事・個人どちらも元気に開発しています。個人開発では SQL の学習サービス ( https://q-dash.jp )を作りました。今後も機能追加していこうと思っています。

さて、今回は実務で開発をする中で「個人開発だけでは学べなかった」と思う開発ノウハウ・Tips を5つ書こうと思います。常にアクティブユーザー数が数百、数千いるようなサービスで早く正確に機能を作っていく人の参考になれば幸いです。

1. リリースしたい機能を特定のユーザーや商品に絞る

満を期して新機能をリリースした後、エラー通知が沢山きて revert 対応や切り戻しをすることになった経験はありませんか?

この際は特定のユーザーや商品に絞ってリリースをすると、バグがあったとしても影響をうけるユーザーを限定することができます。(例えば id が 100 の商品の画面でのみ反映するなど)

プロダクション環境では常に多くのアクティブユーザーがいるため、想定していなかったケースでエラーが発生する可能性が大きいです。新機能のリリース時などで不安が大きい時は、反映対象を限定して問題がないことを確認した後に全体反映する方法が有効です。

因みにこのケースでは「カナリアリリース」というリリース手法も有効です。新機能を先に一部のユーザーにリリースして問題がないことを確認した上で全体展開をします。

2. 修正したいメソッドが多くの場所で参照されている場合は新しいメソッドを作ってそれを用いる。 そして徐々に移行していく

何かしらのメソッドを拡張したいが多くの箇所から参照されている場合、そのメソッドを修正することはリスクが高い行為となります。ある程度テストで動作が担保されていた場合でも修正されたケースを想定しておらず、思ってもいないところでバグが出る可能性が高いです。

その場合は新しいメソッドを作成し、修正して反映させるのも影響範囲を限定する一つの手段です。そして問題なければ他からの参照箇所も徐々に新しいメソッドへ移行していきます。(重複している理由をコメントに残す配慮はもちろん必要です。)

なお、そもそも「オープンクローズドの原則」で修正をメソッドの外で行える設計になっていればベストです。

3. 設計段階でレビューを依頼する

実装に入る前は Issue などに設計・実装方針についてまとめ、チームメンバーにレビューをしてもらいましょう。設計段階でレビューをもらうことで、実装後のレビュー時に設計上の問題が発覚するということを防げます。また、設計のレビューをしていた場合、共通認識があるため実装のレビューもスムーズに行えます。

自分は設計時にレビューをしてもらうことで実装の手戻りが発生することがかなり少なくなりました。より良い設計について議論するのはチームメンバーの設計力向上にも繋がるので積極的にやっていきたいところです。

4. プルリクエストの粒度は小さくする

レビューをしたものの差分が多い故にミスに気づけなかったことはありませんか?

プルリクエストの差分が大きいと1行1行の修正に問題がないかの確認、また動作確認する際の組み合わせも多くなり神経を大きく使います。結果としてレビューの質の低下に繋がります。

なのでプルリクエストの粒度は小さく保つようにしましょう。例えば一つの機能を開発するのにロジックの実装、APIの用意とフロントエンド実装がある場合、ロジックの実装、API、フロントエンド実装用のプルリクエストをそれぞれ作成してレビュー、マージをしていくのが堅実です。(ロジックの実装だけでも..? と思うかもしれませんが、マージすればロジックを他でも使えるようになるのでマージしない理由はありません。)

大きな差分でレビューを依頼をしてしまう際、前回もこれで問題が起きなかったし今回もいけるだろうという思考が考えられます。しかし差分が大きいが故に問題が発生するケースは往往にしてあり、その中のいくつかはプルリクエストを分割してレビューをすれば防げたものがあるはずです。

画像1

このぐらいの差分になると1行1行の変更に問題がないかの確認、テストケースの洗い出し・動作確認のレビューは不可能です。(目安は 300 以下)

5. data 属性を使って E2E テストの修正手間を減らす

html  ファイルに書かれている css の class 名を変更する際、その画面に対応する E2E テストが落ちて修正が必要になったことはありませんか?例えばコードの修正をするデザイナーさんが「デザイン部分を修正しただけなのにその度にテストが落ちるんだけど。。」と思うこともあるでしょう。

この場合テスト用の data 属性を定義して、E2E テストでそれを用いる方法があります。(例では data-spec)

# rspec
 
it do
  visit root_path

  find('a[data-spec=link-to-mypage]').trigger('click') # point!
  expect(page).to have_selector 'div[data-spec=username]'
end


// root.html

<a class='red' data-spec='link-to-mypage'> // point!class 名を変えてもテストは落ちない

<a class='blue' data-spec='link-to-mypage'>

こうすることで css の class 名を変更しても E2E テストが落ちることが限りなく少なくなります。デザイナーとエンジニアの協業かつ E2E テストがしっかり書かれている環境であれば導入を検討してみてください。

【番外編】 仕様の最終決定者は誰か?

個人開発をしていると機能のあるべき姿を決める最終決定者は自分です。しかし組織でエンジニアとして開発をする場合、機能の仕様について最終決定する役割を持つのは自分とは限りません。

仕様の最終決定者 (or プロダクトの責任者) は組織によって異なりますが、それが自分ではない場合、最終決定者と仕様の認識に問題がないかコードを書く前、またはコードレビューをしてもらう前にしっかり確認しましょう。

以下は確認していなかった例です。

レビュワー「このケースの場合、Aという挙動になるのですが問題ないですか?」

実装者「問題ないです。A の方が便利だからです(主観)」

レビュワー「それは、〇〇(仕様の最終決定者)さんに確認とりましたか?」

実装者「確認していないので聞いてみます。」

最終決定者「それは B となる方が良いと思います。なぜなら〇〇だからです」

実装者「確かに。B となるよう実装し直します;;」

こうなると再実装、再レビューが必要になり時間がかかってしまいます。気をつけましょう。(自戒を込めて)


以上です!いかがでしたでしょうか?

こう振り返ると実務だからこそ学べたことは多いなと感じます。他にもあるのでまた気が向いたら第2弾を書こうと思います。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
note.user.nickname || note.user.urlname

記事が良かったと思ったらサポート頂けると嬉しいです。サポート料は、美味しいご飯を食べる際に使わせていただきます。

ありがとうございます!良かったらシェアいただけると嬉しいです!
10
はっさんです。フリーランスの Rails エンジニア。 仕事の話お待ちしております。 作ってるもの ➡︎ https://signbook.apphttps://q-dash.jp / 自己紹介 ➡︎ https://hassansan.me

こちらでもピックアップされています

Web開発
Web開発
  • 4本

個人で開発したサービスについて。サービス開発に役立つ知見など

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。