Skip to main content

Software mind

Overview

ソフトウェア関連の心掛け

ソフトウェアを作成するときに心掛けること

  • エラーハンドリング
    • 例外を適切にキャッチし、ユーザーに分かりやすいエラーメッセージを表示する
    • ログを記録し、エラーのトラブルシューティングを容易にする
  • 冪等性の考慮
    • Webhook
      • 同じリクエストが複数回送信されても結果が変わらないようにする
    • API
      • たとえば、同じリソースの作成リクエストが複数回送信されても、リソースが一度だけ作成されるようにする
  • セキュリティ
    • 入力のバリデーションとサニタイズ
    • 認証と認可の適切な実装
    • データの暗号化
  • テストの重要性
    • ユニットテスト、インテグレーションテスト、エンドツーエンドテストを含むテスト戦略を持つ
    • テストカバレッジを高める
  • ドキュメントの充実
    • コードのコメントやREADMEを充実させる
    • APIドキュメントを自動生成するツールを活用する
  • 継続的インテグレーションと継続的デリバリー(CI/CD)
    • 自動ビルド、テスト、デプロイメントのパイプラインを構築する
    • 変更がすぐに反映されるようにする
  • スケーラビリティ
    • アーキテクチャを設計する際に、将来的なスケーリングを考慮する
    • キャッシュやロードバランサーを活用する
  • パフォーマンスの最適化
    • コードの最適化やデータベースのクエリの効率化を図る
    • パフォーマンスのボトルネックを定期的に監視し、解消する
  • 可観測性(Observability)
    • ログ、メトリクス、トレースを適切に設定し、システムの状態を監視する
    • アラートを設定し、問題が発生した際に即座に対応できるようにする
  • ユーザー体験(UX)
    • ユーザーインターフェースを使いやすくする
    • ユーザーフィードバックを反映し、継続的に改善する
  • リファクタリング
    • コードの品質を保つために、定期的にリファクタリングを行う
    • 技術的負債を管理し、減らす努力をする

コードをリファクタリングするべきか

コードをリファクタリングしない

「リファクタリング」について話すときは、別の言葉を使うとよい

  • コードのパフォーマンスを向上させました(N+1を特定し、大量のデータの非効率的な処理を発見しました)
  • コードを変更しやすいようにしました(この領域は今後より頻繁に変更されるだろうという予測によって正当化されるはずです)
  • コードをより防御的にしました(間違った引数で実行された場合は早期に失敗し、明確なメッセージを表示します。他のチームが誤って使用し、微妙なバグが発生するためです)
  • テストされていない領域にテストを追加しました(良い理由: 最近数回失敗したため、悪い理由: 任意のコード カバレッジ メトリックを増やすため)
  • ログ記録と計測機能を追加しました(何が起こっているかをよりよく理解できるように)

新しいスタイルガイドに合わせてコードを変更します(頻繁に変更するため)

単にコードをリファクタリングしているだけだと主張してはいけないということです。何かをリファクタリングする唯一の理由は、それが明確で、おそらく文書化されている (バグ レポート、機能要求 (改善を含む) など) 必要がある場合です。あなたが「タスク x を進めていて、既存のコードをリファクタリングする必要があった」のではなく、リファクタリングだけを行ったと主張するほど愚かであれば、実際の最終目標が何であるかをもっと真剣に考える必要があります。これがあなたの言っていることです