フロントエンドでやっちゃダメ？...デベロッパーのためのフロントエンドの良い習慣
コンソールログ
これは削除しましょう。
本番コードでのconsole.logは、機密情報の漏洩を防ぎ、パフォーマンス向上のために取り除くことが重要です。
コンソールエラーと警告
調査して修正しましょう。
本番コードでのコンソールエラーは、スムーズでエラーがないユーザー体験を維持するために取り組むことが大切です。
TypeScriptでのAny
ちゃんとした型付けをしましょう。
TypeScriptでのanyの使用は、コードの信頼性や保守性を高めるために、明示的な型に置き換えて最小限にするべきです。
使われていないコードのコメントアウト
これは削除しましょう。
使われていないコードをコメントアウトすることは悪い習慣です。コードが乱雑になり、保守が難しくなり、コメント情報が古くなる可能性があります。
スーパーコンポーネントと関数
コンポーネントが大きくなりすぎたら、小さなコンポーネントに分割する時です。
SOLIDの原則、特に_Single Responsibility_（単一責任の原則）を考えてみましょう。
関数コードでもクラスコードでも。
何度もCSSを書き直す
Ada Lovelace、Alan Turing、Tim Berners Leeのためにも...
色やフォント、サイズを何度も書き直さないようにしましょう。デザイントークンをうまく活用して、グローバルなCSS変数を作るかライブラリを使いましょう。
デザイントークンを使用するメリットについてチームと話し合いましょう。
リンターを無視するフラグ
例えば /* eslint-disable @typescript-eslint/no-unused-vars */ の使用。
コードを修正してください。
リンターエラーでプルリクエストを送らないでください。
本当に無視する必要がある場合は、どのリンター警告を無視できるか慎重に考えてください。
リレンダーやループが過剰なリソースを消費したりクラッシュしたりする
例: JavaScriptのループ関数やReactのuseEffectが適切でない使い方。
これは、API呼び出しやメモリをオーバーフローさせアプリケーションをクラッシュさせる可能性がある無限繰り返しの原因になり得ます。
自分のロジックを修正しましょう。
- メモ: アプリケーションはブラウザで動作し、限られたエンドユーザーのメモリリソースを消費します。
フロントエンドのビジネスルール
置かないで、許可もしないでください。
一般的に、フロントエンドアプリケーションにはビジネスルールがないことが同意されており、ユーザーインターフェース固有のルール、相互作用、そしてユーザーの成功した旅しかないべきです。
フロントエンドはクライアントであり、サーバーではありません。
大企業やエンタープライズレベルのアプリケーションでは、ビジネスルールとデータ処理をフロントエンドに露出させず、バックエンドに配置する習慣を採用しています。
- メモ: シンプルでサーバーレスなウェブアプリケーションや、サードパーティのAPIを参照するものについては、フロントエンドに一部のビジネスルールを置く必要がある場合があります。ただし、クライアントに敏感または非常に高価な処理を露出させることなく注意して配置してください。
テストをしない文化
あなたのコードベースでテストを行いましょう。完璧なコードはありません。
ユニットテスト、インテグレーションテスト、セキュリティテスト、UXテスト、パフォーマンステスト、アクセシビリティテスト。テストツールを使用して、エラーレポートを生成し、アプリケーションの修正点を特定してください。
例: Cypress、Lighthouse、デプロイパイプラインのSASTなど。
UXチーム、QAチーム、サイバーセキュリティ/ペネトレーションテストチームがある場合は、そのチームと連携しましょう。
コミュニケーションへの恐れ
あなたは人間です。
どうにもならなくなったら、他のデベロッパーやテックリードに問題を共有するために連絡してください。
ペアプログラミングや一緒に考えることで、問題はより早く解決されます！
覚えておいてください：彼らもかつてあなたの立場にいたことがあり、助けてくれますよ！
楽しんでいただけましたか？ 😃✌🏻
さらにアドバイスはありますか？
私の活動を Patreon.com/lucasm でサポートしてください。
こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/lucasm/frontend-best-practices-guide-or-dont-do-it-on-frontend-32n4
