入社 1 年目の気づき
入社 1 年目の気づき
はじめに
Web エンジニアとして働いているせーと申します。メインはバックエンドですがフロントやインフラも触ったりしています。
早いもので、入社してから 1 年が経過し、もう新卒の 2 年目になろうとしています。そこで、入社して 1 年間で学んだことや成長したことを記事としてまとめたいと思います。
会社外で何をやっていたかはこちらの記事に記述していますので、よければご覧ください。この記事では、業務で得た経験から成長したことを主に言及していきます。
気づき
設計書・ドキュメントはすぐに更新する
プロジェクトに途中から参画する人や未来の自分が設計書を見て間違えないように、仕様が変わったり、コードが修正された段階でドキュメントも同時に修正することが重要です。また、口頭で話したことは忘れがちなので、その場で修正するか、タスクを切って忘れないようにすることをおすすめします。
設計書にはどの画面でどのエラーが返却される可能性があるかも記述する
QA にテストしてもらう時に、どの画面でどのようなエラーが発生するかがわからず、別途作成する必要が出てしまったので、設計書作成段階でエラーについても記述するようにしました。どのような操作をしたらどのようなエラーが発生するかを明確に記述しておくことが求められます。例えば、ログイン画面でフォームを入力せずにログインボタンを押下すると「パスワードを入力してください」と表示される、などです。
フロントエンド・バックエンド両方に影響がある修正をする際は、あらかじめどのように修正を行うかを確認しておく
開発環境の場合でもチームで開発している場合、両方に影響する修正を行うともう一方の環境でクラッシュしてしまうことがあります。そのため、一時的に機能追加ブランチに変更して、フロントエンドの修正が終わったら develop ブランチに戻すなど、どのようにしてマージするかを事前に決めておく必要があります。
実装時にはマージ前確認をしっかりと
全てを網羅して確認することはほぼできませんが、先にどのような状態になるのかが望ましいかを定めておき、その状態になることを確認することで、少なくともフロント側との認識齟齬は起きにくくなります。
本当にその仕様が必要か考える
実装を進める中で、この仕様に沿って実装するのは難しそうだな、この仕様でパフォーマンスを上げるのは難しそうだな、と感じることがあります。そこで、そもそもその仕様である必要があるのかを考えてみましょう。最初に目的があって、その目的を達成するために仕様が決められているわけですから、目的に立ち返って仕様を再検討してみるのも一つの手です。
ログは出力しよう
ログを確認することで、DB を過剰に呼び出していたり、エラー原因の特定が迅速に行えます。そのため、ログを出力することが大切です。各言語・ライブラリでログ出力用のライブラリがあると思うので、それを利用することで簡単に実装することができます。
リクエスト制限について
フレームワークで 1 分間に何回までしか API を利用できないという制約がデフォルトで設定されている場合があります。これは通常、過多アクセスや DOS 攻撃を防ぐためのものですが、ユーザーが不便に感じることもあるかもしれません。そのため、要件を決めておくことが大切です。
SQL の曖昧検索について
SQL の曖昧検索（LIKE）をする際に、ワイルドカード文字やエスケープ文字が含まれている場合にうまく検索できないため、エスケープする必要があります。
ソースコードが公開されていたら、ドキュメントを読むよりもコードを読んだ方が良い
ドキュメントよりもソースコードの方が正確で、細かい情報までわかります。そのため、公開されている場合はソースコードを読むことをおすすめします。コードを読む力の向上にもつながります。
公式ドキュメントだから何でも載っているでしょ、と思っていましたが、言語によっては載っていないことも多いです。
基本的には RFC に従う
各ライブラリや言語固有のものではなく、デファクトスタンダードになっているので、可能な限り RFC に従うようにしましょう。知っておくべき RFC をまとめている方がいたので共有します。
タイムゾーンの設定
サーバーが複数ある場合、サーバー間でタイムゾーンがずれていると不整合が生じてしまいます。そのため、UTC や JST など、一つに統一する必要があります。
API 単体でリリースしても問題ないような実装に
API を作成する際に、フロントエンドをまとめて開発することもあると思いますが、API 単体でリリースしても良いように、フロントエンド側、API 側の両方にバリデーション・制約をつけることが重要です。
外部の API を使うときは、どのようなデータが返ってくるか確認する
内部で作成している DB に格納する際に、型が合わないということになりかねないので、何の型か、最大値、最小値、null があるかなどを確認することが大切です。言語によって異なってきますが、null・undifined・空文字・レスポンスなしなど似ているようで異なるデータもあるので、その点も確認が必要です。
DB 設計で関連テーブルについて
親テーブルのデータが削除されたら、子テーブルのデータも削除されるような場合は、on delete cascade を利用するのも一つの手です。ただし、一長一短があるので、要件と照らし合わせて吟味する必要があります。
おわりに
本当にあっという間の一年でした。
今年はアウトプットを増やしたいと思っているので、登壇やカンファレンススタッフなどに挑戦しようと考えています。
Discussion