開発の手法

完了の定義に基づいて作業する

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

次に、チームが一般的に指定しているいくつかの条件を示します。

  • コードのフォーマットがレビュー済みである
  • コメント/Javadoc が追加されている
  • 必須のテスト範囲レベルを満たしている
  • 単体テストおよび統合テストに合格している
  • QA 環境で検証済みである
  • ローカリゼーションが実装されている

DoD が明確に定義されていないと、多くが半ば完了した状態で本当に完成したものはないという状況に陥りやすくなります。

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

インデントレベルや空白など、重要とは思われないようなものでも、正しいフォーマットでコーディングすることは、読みやすさと保守性に大きな効果があります。規則は、チームとして議論し、同意してから、コード内で実行する必要があります。

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

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

開発者は TDD を実践し、失敗する単体テストを記述してから、要件を満たす実稼動コードを記述します。QAでは、システムが高いレベルから期待どおりに動作することを確認する受け入れテストの自動セットを作成する必要があります。

Jackalope や Prosper などのカスタムフレームワークを使用すると、JCR API のモック作成がシンプルになり、単体テストを記述する際の開発者の生産性が高まります。

デモを使用可能にしておく

各反復の終了時には、システムのデモを使用できるようにする必要があります。このシステムをデモに対応できる状態に維持することで、チームは常に生産準備が整い、技術的な債務を維持可能なレベルに維持できるようになります。

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

継続的な統合環境を導入すると、単体テストおよび統合テストを簡単かつ反復して実行できます。また、開発チームからの導入を切り離し、チームの他の部分をより効率的にし、より安定した予測可能な導入を実現します。

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

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

Sonar とその他の静的コード分析ツールを微調整し、ツールが出力したレポートに基づいて対処する

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

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

ボーイスカウトには、「帰るときには、その場所を来たときよりもきれいにする」というルールがあります。開発チームのメンバー全員がこのルールに従い、混乱が発生した場合に何かをクリーンアップする限り、コードは常に向上します。

YAGNI 機能を導入しない

YAGNI(You Aren't Gonna Need It の略)機能は、今は必要なくても将来は必要になると思われる場合に導入するものです。理想的には、今日動作する最も単純なものを実装し、継続的なリファクタリングを使用して、システムのアーキテクチャが時間の経過と共に要件を満たすようにします。 これにより、重要な点に焦点を当て、コードの膨張や機能のクリープを防ぐことができます。

このページ