Show Menu
トピック×

開発の手法

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

チームごとに「完了」の定義が異なりますが、定義を統一し、状況が定義済みの条件を満たしていることを確認してから受け入れることが重要です。
次に、チームが一般的に指定しているいくつかの条件を示します。
  • コードのフォーマットがレビュー済みである
  • コメント/Javadoc が追加されている
  • 必須のテスト範囲レベルを満たしている
  • 単体テストおよび統合テストに合格している
  • QA 環境で検証済みである
  • ローカリゼーションが実装されている
DoD が明確に定義されていないと、多くが半ば完了した状態で本当に完成したものはないという状況に陥りやすくなります。

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

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

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

プロジェクトの実装サイズが大きくなると、テストに必要な時間が長くなります。適切なテスト範囲がなければ、テストチームは規模を拡大できず、開発者は最終的にバグに埋もれる。
開発者は TDD を実践し、失敗する単体テストを記述してから、要件を満たす実稼動コードを記述します。QAでは、システムが高いレベルから期待どおりに動作することを確認する受け入れテストの自動セットを作成する必要があります。
Jackalope や Prosper などのカスタムフレームワークを使用すると、JCR API のモック作成がシンプルになり、単体テストを記述する際の開発者の生産性が高まります。

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

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

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

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

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

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

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

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

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

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

YAGNI 機能を導入しない

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