🚀

ツクリンクに入社してから3年経つので実装時に意識するようになったことを振り返ってみる

2024/12/21に公開

この記事はツクリンク株式会社のアドベントカレンダー21日目の記事になります。
ツクリンクでエンジニアをしている佐山(yama2_0506)です!

私が実務未経験でツクリンクに入社してから間も無く3年を迎えようとしています。
入社当初は初めての環境でドメイン知識など様々なことをキャッチアップしつつ働いていたので大変だったなと記憶しています。特に開発実装に関しては、どんな観点で実装を行えば良いのかというところは把握出来ておらず、とにかく「仕様通りに動くこと」この一点に意識をしていた記憶があります。
そんな私も書籍や記事を読んだり、たくさんのレビュー指摘を受ける中で、実装時に意識するようになってきていることがあるなと感じたので、実際のPRコメントなどを載せて書いていこうと思います。

前提

下記に関しては出来ている前提なので今回はあえて触れません。

  • 仕様通りに実装がされているか
  • 想定通り動いているか

意識するようになったこと

1.パフォーマンスを考慮する

ツクリンクのサービスは10年以上稼働しており、ユーザー数やデータ量が非常に大規模になっています。そのため、パフォーマンス改善や最適な設計が常に求められます。
現状私が考慮しているポイントは下記です。

  • クエリの最適化: 不要なデータ読み込みを避ける。
  • DB設計の見直し: 最適なデータ型とテーブル設計を意識する。
  • メモリ管理: メモリ効率を向上させる。

下記で実際のPRレビューコメントから具体例を見ていきます。

クエリの最適化

元々は empty? を使用して全データをロードしていましたが、exists? に変更することで、存在確認だけを行い、データベース負荷を軽減。1件だけの存在確認で問題なければexists? は効率的に存在確認が可能かなと思います。
↓※他の方のPRが分かりやすかったので参照させていただいております

DB管理の見直し

返信率が 0〜100 の固定値であるため、フィールドサイズを最小限に設定し、ストレージ消費とアクセス効率を改善しました。数値範囲を明確化し、データ型を適切に選ぶことで、無駄を排除しています。

メモリ管理

一回の処理で外部APIに複数回リクエスト・レスポンスを受け取る処理が発生するケースで、当初は全てのレスポンスを受け取ってからまとめてDB更新を行うことを想定して実装を行なっていました。ただその場合1回のリクエストで数千件規模の件数のデータをメモリ持ちする必要があったので、外部APIに1回リクエストを行うごとにDB更新を行なっていく仕様に変更することでメモリ効率向上を図りました。

2.命名に気をつける

命名に関しては下記のようなところを意識しています。

  • 名前だけで役割が明確に分かること
  • 誰が見ても容易に伝わる命名
  • 汎用的な名前を避ける
  • 抽象的な名前よりも具体的な名前をつける


命名に関してはチームメンバーの納得感が得られるまで確認しながら進めることが多いです

3.適切なコメントを入れる

ここで言う適切なコメントは下記のようなものを指しています。

  • 「何をしているか」ではなく「なぜこの実装をしているか」を説明するコメント
  • アノテーションコメント(後で直すべき箇所などにTODOをつけるなど)を残すなど

他の開発者がコードの意図を理解しやすくことや、後で改修を加える際に分かりやすくすることを目的としてコード上やPR作成時のコメントに入れるようにしています。

ソースコード上のコメント↓

PRのコメント↓


4.要件の見落としがないかを確認する

現在、チームはスクラムで開発を行なっており、スクラムイベントの中である程度時間を確保し、リファインメントで仕様・要件詰め、基本設計を行い、その後チームで詳細設計を行なっています。
しかし、どうしても当初の設計時には見えていなかった見落としが出てくることがあるのも事実です。

そういった見落としを拾うのは、レビュー時やQAのマニュアルテスト時などで発覚することはあるのですが、実装時にコードを書いている際や手元で動作確認してみて要件の見落としに気付くことも結構あります。

最後に

こうして書き出してみると、どれもエンジニアとして基本的な部分かもしれません。しかし、入社当初の自分を振り返ると、これらを意識できるようになるまでには、数えきれないほどの試行錯誤や指摘、そして学びがありました。特にレビューで指摘されたことや、先輩エンジニアからのアドバイスを受け、実際のプロダクト開発を通じて得られた経験は、何よりも大きな糧となっています。

また、これらを意識するようになった背景には、チームやプロジェクトの成長、そしてプロダクトの持つ課題や規模が関係しています。例えば、10年以上運用され続けているサービスの特性上、大規模なデータや複雑な要件に向き合う必要があり、その都度「今の自分ができる最適な実装とは何か」を考える習慣が身につきました。

これからも継続して学びを深め、自分自身とプロダクトをさらに成長させていきたいと思います。

Discussion