ナッシュビル プロジェクト

最近、私のお気に入りの Thoughtworks プロジェクトの一つに時間を費やしました。1998 年に始まり、当時新しい J2EE テクノロジーを使用したプロジェクトです。長い年月をかけて興味深い経緯をたどりました。EJB から始まり、それらを削除し、バンガロールにオフショア化し、シカゴに戻ってきました。多くの人がプロジェクトに参加したり離れたりしており、プロジェクトの規模は 6 人から 60 人にまで変化してきました。全体として、プロジェクトには 300 人年を超える努力が費やされており、100 KLOC 程度になります。

私が好きなプロジェクトである理由は、私の好むソフトウェア開発における重要な特性を示しているからです。適切に設計されたコードベースによってビジネス機能を長期的にサポートします。10 年後も有益なビジネスバリューを追加し続けていることは、大いに評価できます。必要に応じて新しい機能を迅速に追加できるため、レガシーアプリの典型的な泥沼には陥っていません。

この訪問では、いくつかの考えが印象に残っています。

まず、受け入れテストに対するアプローチとその方法、つまり新しい機能を追加するときの更新方法が興味深い進化を遂げていました。彼らの元の（そして一般的な）世界観では、新しい ユーザーストーリー を実装するたびに、1 つ以上のテストを追加します。これにより、各ストーリーが 1 つ以上の受け入れテストによって検証される、単純なトレーシング構造になります。しかし、このアプローチの問題は、時間が経つにつれてテストが複雑になり、重複が多くなることです。

彼らの新しい世界観では、SpecificationByExample スタイルのアプリケーションの動作を記述する受け入れテストのスイートがあります。新しいストーリーをプレイするたびに、新しい動作を反映するようにこのスイートをどのように更新するかを決定します。これにより、シンプルなストーリーとテストの関係は断ち切れますが、テストのスイートははるかにシンプルかつ首尾一貫したものになります。

プロジェクトのもう一つの興味深い側面は、コードベースの改善をどのように継続しているかです。彼らはこれを説明するための適切で、かつ非公式な指標を思いつきました。数年前、誰かを新規採用する場合、少なくとも 1 年間はコミットしてもらう必要があったため、コードベースに対するスピードアップに追いついた後の貢献が価値のあるものでなければなりませんでした。今ではその時間は 3 か月まで短縮されました。10 年前に作成されたアプリで、これほど多くの人々が参加している場合、これはかなりの成果です。

私にとって、優れた設計の主な目的は、コードで作業を迅速に継続できることです（DesignStaminaHypothesis）。開発者がコードベースで生産的になるまでにどのくらい時間がかかるかを評価することは、この設計の品質を認識するための良い方法です。最小コミットメント期間の指標は、この同じアイデアの別の転換です。私たちは客観的に測定できるものではありませんが、チームで検討できるものです。

このプロジェクトから、人々が経験についてより多く語ってくれることを期待しています。彼らは昨年、ポッドキャストを行いました（Thoughtworks ポッドキャスト に進んで、「Keeping Grey Code Fit」を探してください）。