開発の手法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

YAGNI 機能を導入しない

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

このページ