良いプロダクトを開発するために気をつけていること

ごきげんよう。ツクリンクでエンジニアをしているあっきーです。
去年から採用を強化しエンジニアメンバーが倍以上に増えました。
エンジニアチーム全体で良いプロダクトを作っていくため、実装やコードレビュー時に気をつけている点をまとめました。
※コードに関する話は定番ですがプリンシプル オブ プログラミングやリーダブルコードを意識しています。

プロダクトの品質を高める

大前提、プロダクトはユーザーさんに利用してもらい初めて価値が出ます。
まずは適切に価値が届けられるコードであることを大事にしています。

パフォーマンス第一

早さは正義です。
重くなるような実装になっていないか、キャッシュは適切に利用されているか、発行されるSQLでは適切なインデックスが利用されるか、N+1が発生しないか、件数が多くなった時に壊れないかなど考慮します。

可変部分の考慮、UIスタックを意識する

基本的なWebサービスはユーザーが何かしらのデータを登録し表示しています。すごく長い文章が入った場合や、逆に短い場合、空の場合など文章やデータの可変部分がどうなるか意識します。
意地悪なテスターになったつもりでいろいろなテストデータを作ると良いです。UIスタックの状態も頭に入れておくと考慮できる幅が広がります。

無くても良いものは作らない

YAGNI原則でもあるように「今後こういう使い方をするだろうから拡張性高く作っておこう」みたいなことは控えます。また、仕様自体に対しても削れるものを削りユーザー価値が担保できる最低限の機能提案を行います。

テストコードを充実させる

コードの品質を担保し、変更容易性を損なわないよう、メソッドのテストからE2Eテストまで、ケースに合ったテストコードを書きます。現状90%弱のテストカバレッジを取れていて継続していきたいポイントです。

障害に強くする

この処理内でエラーが起きた場合にどうするかを考慮します。ユーザーにそのまま操作を続けてほしいなら適切に処理が続くようにし、エラーページを見せるべきか、エラーログには何を残すのか、管理者への通知はどうするのかなど考慮します。

保守性を高める

一度書いたコードは結構な確率で長生きします。
新しいメンバーがコードを読むときや、このコードが5年、10年先まで残り続けた時、誰が見ても理解しやすくメンテナンスしやすい状態であることを目指します。

適切な変数名、メソッド名をつける

変数に何が入っているのか、そのメソッドが何を返すのか予測しやすくします。
1行のスコープの小さい範囲であれば1文字の変数名などもありえますがそれ以外はある程度の長さは許容しつつ分かりやすい命名を行います。
また、予測可能性という観点から似た変数、似たメソッドには似た命名を心がけます。

適切なコメントを残す

コメントにはなぜこうなっているのか、コードを読んだ人が迷わないように背景が分かるコメントを残します。
後から読んだ際に理解しやすいよう、コメントに参照したドキュメントへのリンクを貼るのも良いでしょう。

理解しやすい実装を心がける

責務を分けmoduleやClassに切り出すなど可読性やテスト容易性を上げるよう心がけます。
また、複雑な実装にコメントを残すこともありますが、それ以前に複雑にならないようにRubyのワンライナーで書けるものも、適切に分割するなど可読性を高められるように考慮します。
メンバーのスキルに合わせてということもありますが、どんな人が参画しても理解しやすいコードを目指したいです。

最後に

プロダクトづくりはチームスポーツです。ユーザーにとって価値のあるプロダクトを作っていくために開発チームで意識を揃えプロダクトの品質、コードの品質を高めていきたいと思います。

ツクリンク株式会社では一緒に働く仲間を募集しています。