開発の手法

最終更新日: 2023-11-07

完了の定義 (DoD) に従って作業

チームごとに「完了」の定義は異なりますが、定義を統一し、状況が定義済みの条件を満たしていることを確認してから受け入れることが重要です。

チームでよく指定される条件には、次のものがあります。

  • コードの書式設定を確認しました
  • コメント/Javadoc が追加されました
  • 必要なテスト対象レベルを満たす
  • 単体テストと統合テストに合格
  • QA 環境で検証済み
  • ローカリゼーションの実装

明確に定義された DoD がなければ、多くのことが途中で完了し、何も真の完全なものがない状況に簡単に終わることができます。

コーディングおよびフォーマット規則を定義し、準拠する

インデントレベルや空白など、重要とは思われないようなものでも、正しいフォーマットでコーディングすることは、読みやすさと保守性に大きな効果があります。チームで表記規則について話し合って合意し、その規則に準拠してコーディングする必要があります。

広範なテスト範囲を目指す

プロジェクトの実装サイズが大きくなると、テストに要する時間も長くなります。 テストの有効範囲が適切でないと、テストチームは規模を拡大できず、最終的に開発者はバグに埋め込まれます。

開発者は TDD(Test Driven Development) を練習し、要件を満たす実稼動コードの前に、失敗した単体テストを記述する必要があります。 QA では、上位レベルから見てシステムが想定どおりに機能することを確認するために、一連の自動受け入れテストを作成します。

Jackalope や Prosper などのカスタムフレームワークを使用して、JCR API のモッキングをより簡単にし、単体テストを記述しながら開発者の生産性を確保できます。

デモの準備を維持

各反復の終了時には、システムのデモを使用できるようにする必要があります。システムのデモを使用可能な状態にしておくことによって、チームは常に実稼動の準備ができているという状態を繰り返すことになり、技術的な負債を維持可能なレベルに保つことができます。

継続的な統合環境を導入して使用する

継続的な統合環境を実装すると、単体テストや統合テストを簡単かつ繰り返し実行できます。 また、開発チームからデプロイメントを切り離し、チームの他の部門の効率を高め、より安定した予測可能なデプロイメントを実現します。

ビルド時間を短く抑えて開発サイクルの高速性を維持する

単体テストの実行に長時間かかる場合、開発者は単体テストの実行を避けるようになり、単体テストの価値が失われます。コードのビルドおよびデプロイに長時間かかる場合は、ビルドおよびデプロイの頻度が減ります。短いビルド時間を優先させることで、テスト対象と CI インフラストラクチャに投資した時間が、チームの生産性を高め続けるようになります。

Sonar やその他の静的コード分析ツールを微調整し、レポートに基づいて操作する

コード分析ツールは、そのレポートが開発チームメンバー側の対処につながって初めて有用であると言えます。これらのツールが提供する分析を微調整しないと、生成される推奨事項は無関係になり、価値が失われます。

ボーイスカウトのルールを守る

ボーイスカウトには、「来たときよりも美しく」というルールがあります。開発チームのすべてのメンバーがこのルールに従って、混乱が発生したときに何かをクリーンアップする限り、コードは常に改善されます。

YAGNI 機能を導入しない

YAGNI(You Ann't Not Need It) の機能は、今は必要なくても、将来何かが必要になると期待したときに実装されるものです。 理想は、今すぐ機能する最も単純なものを導入し、継続的にリファクタリングをおこなって、システムのアーキテクチャが要件に応じて長期間で進化していくようにすることです。これにより、何が重要かに焦点を当て、コードの膨張や機能のクリープを防ぐことができます。

このページ