心配を止めて始めるには？

前回 、 私たちがチームの仕事について話したとき、多くの人が開発者自身の仕事の組織の詳細に興味を持っていました。これについては今から話します。 開発者が行うことはすべて何度も説明され、議論されているため、「内訳」や発見を期待すべきではありませんが、実際の大規模プロジェクトで一緒に行うことはそれほど頻繁には行われません（正直なところ、私は他のどこにもいません見られる）。 つまり、何かを期待するべきではありませんが、「カバーブレーク」が発生します:)

現実には、適切なエンジニアリングプラクティスのないアジャイルは非常に迅速に終了します。 高レベルの開発品質とシステム全体の状態を保証する努力をしないと、プロジェクトがより複雑になると、すぐに制御が失われます。 その結果、イテレーションで計画されているすべてを実行することはできませんが、重要なリリース（リファクタリングだけでなく、ユーザーが利用できるいくつかの新機能を意味する）を夢見ているのは月に1回だけです。重要なリリースの安定化には1か月以上かかります。

適切なアプローチを使用すると、新しい機能の開発を非常に迅速に行うことができます。ここでのコツは、以前に実行したことを破らないようにするか、正確に壊れたものをすばやく理解して修正することです。 毎回、すべての詳細とニュアンスを手作業でテストすることは非常に長く、非効率的です。なぜなら、今日のElbaには400を超える「スクリーン」があるからです。 そして問題は、テスターがこのすべてを手動で確認する必要があるだけではない-「テスターがバグを追加した-開発者がバグを修正した-テスターがバグを確認して閉じ/再開した」というシナリオに多くの時間が費やされる 急成長しているシステムを安定した状態に保つのがどれほど難しいか、なぜコードがたわむれるのか、修正するのが怖いのか、そしてリリース日を1ヶ月まで告げるだけの人はいない（無責任だから）と長い間話すことができますが、それを良くする方法を学ぶのはもっと面白いです。

テスト、テスト、テスト

「テスト」という言葉を3回書いたのは、言葉を3回繰り返すのが楽しいからではなく、3種類のテストを使用しているからです。

1. ビジネスロジックの単体テスト。 Elbaは、相互に対話する複数のサービス（Web、データストレージ、ディレクトリサービス、印刷サービスなど）の組み合わせであり、これらすべてのサービスとWebのサーバー部分をTDDスタイルで記述します。 TDDについて多くのことが言われ、書かれています。 この方法論の主な利点は、テストの作成が日常的な作業や退屈な作業ではない状況を作り出すことだと思います。 徐々にテストを構築し、現在の一連の単体テストに合格するのに十分なほど熱狂的にコードを記述しますが、それ以上の行はあまり楽しくありません。チェスのようなメンタルゲームです。 さらに、コードのすべての行を単体テストで正直にカバーすると、より高度なコードを取得できます。 狂信はここで適切です：消去できるコードがあり、同時に単一のテストが落ちない場合、教育目的でこのコードをすぐに消去する必要があります。 誰もが優れたコードについての独自のアイデアを持っていると言う価値があります。生徒はコンパイルが完璧であるコードを検討し、一部の開発者は機能するコードを検討します。 幸いなことに、これについて議論することはできません。 最も美しい人物であるボブおじさんは、良いコードの正式な特性の分野で一般化されるべきすべてのものを長い間要約し、それについての一連の記事を書きました。 Elbaでは、 SOLID原則に準拠した優れたコードを見つけています。 それでもそれが何であるかわからず、Haskell開発者でもない場合は、間違っているか無駄になっている可能性があります:)単体テストでカバーされているコードは簡単に構築および変更できます。テストは古いビジネスロジックの不変性を保証します。 SOLIDを使用すると、重要な変更を純粋にローカルで行うことができます（コピーペーストと同じことを行う3つのクラスはありませんか？）-指定された目標を達成し、開発速度は低下せず、指定された品質ですべてが行われます。
   
   
2. クライアント側JavaScriptの単体テスト。 サーバー側のビジネスロジックは優れていますが、エンドユーザーにはWebアプリケーションが表示されます。 そして、彼らは退屈なページを見ているだけでなく、すべてが飛んで爆発しなければなりません。 したがって、多くのクライアントロジックを記述します。 サーバー側のビジネスロジックに比べて新しいものは何もありません。コードはSOLIDであり、テストで覆われている必要があり、異なる言語である必要があります。 このようにして、汎用クラスとコントロール（たとえば、クライアントバリデーター）をテストします。
   
   
3. Webアプリケーションの機能テスト。 すべての単体テストに合格できますが、これはユーザーが特定のページに問題がないことを保証するものではありません。 各フォームのフィールドに入力し、サーバーでこれらのフィールドを処理するための単体テストはテストしません。 リーフページの正しい動作をキャプチャするには、機能テストを使用します。 実際、ユーザーの動作を繰り返します。リンクをクリックし、特定のフィールドセットでページがロードされるのを待ち、これらのフィールドに入力し、検証の有効性を確認し、「保存」ボタンをクリックして、フィールドに入力したものがリポジトリに正確に収まったことを確認します。 ページ上であっても、いくつかの条件に応じて、いくつかの小さな碑文が変更されます-このためのテストがあります。 開発者がコードを書いたすべての条件をテストすることは不可能であると言った場合、彼はこのコードを飲んだり嘘をついたりしました（たとえば、 科学的なアプリケーションではなく、通常のビジネスロジックについて話します）。 テストは次のようになります。
   
   

   [Test] public void ChangeEmailWithGoodPassword() { const string newEmail = "hello_habr@gmail.com"; Prepare(); emailSettingsPage.Email.TypeValueAndWait(newEmail); emailSettingsPage.Password.TypeValueAndWait("superpassword"); emailSettingsPage.SaveButton.Click(); emailSettingsPage.WaitSaveSucceded(); emailSettingsPage = emailSettingsPage.Refresh(); emailSettingsPage.Email.WaitValue(newEmail); } 

   
   テストを実行すると、次のようになります。
   
   
   
   このような理解可能なテストを作成するために、ページの抽象化とコントロールを作成します。これにより、サポートの複雑さが大幅に軽減され、読みやすくなり、TDDで機能テストを作成することも可能になります。

テストを実行する

テストはそれらを実行するために書かれているので、テストを簡単に（1つのボタンで！）実行し、すぐに開始してすぐに解決することが非常に重要です。 その後、開発者は実際にそれらを起動します。 単体テストはそのように動作し、1700のテストが2分で完了します。 機能テストでは、すべてのテストがそれほど単純ではありません。各テストでは、ページ（多くの場合、複数）を読み込んで、その後の検証を行うためです。 数秒から数十秒かかります。 しかし、2000を超える機能テストがあるという事実を考慮すると、1台のマシンですべてのテストを実行するには約7時間かかります。 明らかに、すべての機能テストがパスするのを待つ忍耐を持つ開発者はまだ生まれていません。 したがって、開発者は、作成したばかりのテスト、または変更されたページをテストするテストのいずれかを実行します。 その後、開発者がコミットし、ビルドサーバーが機能します。ビルドサーバーはバージョン管理システムと通信し、新しいものが出現したことを理解し、コミットをキューに追加します。 キューは、エージェント（物理マシンまたは仮想マシン）によってスクープされます。その意味は、コミットごとにテストセット全体を実行することです。 20のエージェントを使用して、重要なすべてのブラウザーで正しい動作を確認します。 落とされたテストのリストを簡単に確認し、それらを引き上げることができます。 同時に、バージョン管理システムにはいくつかのブランチがあります（新しい機能を作成する安定したブランチ）。 そして、すべての主要な支店で、エージェントを入れます。



テストを提起する時間については、別途言及する必要があります。 ここで遅らせることはできません。 Microsoftの一部のチームでは、少なくとも1つのテストが失敗するまですべての作業が停止し、再開しないと聞きました。 正直に言うと、私たちはこれをやろうとせず、毎日テストを行い（これはデューティエンジニアです）、各リリースの前に、安定化中（厳しい場合はチーム全体）に上げました。

その結果、行のテストコードはシステムコードとほぼ等しくなります。 打ち上げのための本格的なインフラストラクチャを構築することができました。 これを行う動機は何ですか？ 長い時間間隔でテストを行わなければ、開発により多くの時間を費やすことに気づきました。 あなたの多くは、次の大きなコミットが何を壊す可能性があるかについての議論に繰り返し参加したにちがいありません。 または、重要なリファクタリングを行う余裕がないという結論に至りました。これにより、発生する問題を特定するのに予測できない時間がかかるため、作業が高速化され、コードが改善されます。 何が起こっているのかをコントロールし、システムの変更が現実のものであることを理解するのは非常に楽しいことです。 複雑なシステムを書くことは簡単な作業ではなく、書くことは常に定性的に機能し、しばしば変化しますが、システムの変化に耐えることは、桁違いに難しくなります。

ペアプログラミング

ほぼすべてのコードをペアで記述し、共通のコード所有権を目指して努力しています。 つまり、サーバープログラマー、クライアント、またはデータベース開発者などの分離はありません。 すべてのチームメンバーが任意のタスクを引き受けることができます。 誰もがプロジェクトやプロジェクトのある分野で異なる能力と関与を持っていることは明らかです。そのため、ペアを使用して知識を広めます。 そして、それらの2つははるかに楽しいです。 正直に。 そして最も重要なことは、これがまったく遅くないことです。ペアで作業する場合、開発者は無関係な問題にまったく気を取られません。

コミット前のコードレビュー

コードの一般的な所有権の状況では、このトピックに最も没頭しているチームの別のメンバーにカップルがコミットしようとしていることを示すことは非常に合理的です。 まず、彼らが書いたばかりのことをレビュアーに説明すると、結果として夫婦自身がこれを完全に理解します。 第二に、校閲者は非常に迅速にいくつかの完全に愚かな問題を見つけ、それらを指摘します。 第三に、情報はカップルから別の開発者に配布されます-これも優れています。

計画中

もちろん、これは純粋なエンジニアリングの実践とは言えません。計画だけが開発チームの生活の中で非常に重要な部分であるため、それについて話さないことは完全に不可能です。 上記で書いたものはすべて品質に関連していましたが、品質だけが目標ではありません。 優れたコード、多くのテスト、リリースは非常に安定していますが、6か月以内に発生するため、プロジェクトはすぐに停止します。 これは、自分が望むものを理解し、それに対して十分な支払いをする準備ができており、単に彼の欲望の高品質の実現を期待しているクライアントがいる場合、カスタム開発で機能します。 他のすべての場合、アイデアの正確性を検証して修正できるようにするには、より頻繁なリリースが必要です。 最後に、今後数週間でチームが何をできるかを確実に理解する必要があります。 また、プログラミングとコードの共通所有権を組み合わせるには、すべての開発者がタスクを開始する前に同じ方法で理解する必要があります。 ポーカーの計画の助けを借りてこれを提供します-柔軟な開発方法論を使用するチームのよく知られたプラクティスです。 従来のアプローチは、チームが次の開発イテレーションにいくつかのタスクを入力し（2週間のイテレーションを使用）、各タスクにかかる「理想的な」時間を投票することです。 当社のノウハウは、投票結果を提示する革新的な形で構成されています。このマインドマップを使用します。



文字はタスクの名前であり、数字はポーカーをプレイした結果として生じた時間です。 しかし、最もクールなことは、毎日状況を過大評価していることです。 各タスクについて、進行状況が決定されます-どの部分が既に行われたか。 その結果、非常に早い段階で不可抗力に対応できるため、チームが間に合わないことを理解するためにイテレーションの終わりまで待つ必要はありません。逆もまた同様です。

虫

開発者の足が踏み込まれていない場合にのみバグはありません。 また、月に一度重要なリリースを作成したいという願望があることを考慮すると、バグを修正する時間がないため、バグにinれる可能性があります。 また、通常バグを修正することはかなり予定外のタスクであることも考慮する必要があります。 バグの数がクリティカルマスに達すると、熱狂的に修正する必要があり、すべての計画が破壊される可能性があります。

私たちはこの問題に直面し、機能するように見える方法を見つけました-バグの日。 最初は、反復ごとに1日のバグがありましたが、とにかくバグの数は増え続けました。 したがって、バグの別の日を導入しました。これは、反復の2週目に開催されます。 したがって、反復の2日間はバグのために予約されていることを常に認識しており、計画する際にこれを考慮します。 このような状況はすぐにではなく、最近になって発生したことに注意してください。 最初は、それなしでなんとか管理しました。

リファクタリング

どのロシアのプログラマーがリファクタリングを嫌いますか？ テストが利用できるため、リファクタリングをかなり簡単に実行できるという事実にもかかわらず、バグの数が増えているのと同じ理由で、月に一度リリースするのに十分な時間を割くことができない場合があります。 バグが何も失うことなく（そしてやる気さえなく）閉じられる（または閉じられない）場合、リファクタリングに関与していて、どこにも退却できないことがあります。 この問題を解決するために、反復の別の日が「自由な創造性の日」の下に割り当てられます。そこでは、リファクタリング、いくつかの魔法のことを行うことができます。 そして、この日の誰かが、逆説的にそのままで、自発的にバグを修正します！

勤務中のエンジニア

修正のために特別に予約された日にバグ修正を延期することは常に可能ではありません。 また、テクニカルサポート、コールセンター、アナリストには、毎日異なる開発者からの質問やリクエストがあります。 チーム全体を混乱させないために、すべての反復で被害者、つまり勤務中のエンジニアを選択します。 その存在の意味は、すべての質問に答え、非開発者エルバの人々のすべての要求を満たすことです。

リリースエンジニア

この役割については、型にはまらない見方があります。 リリースごとに、開発者からリリースエンジニアを割り当てます。 その目標は、すべての機能テストに合格し、パッチが準備およびテストされ、誰もリリースに関する質問がないことを確認することです。 これは、リリースエンジニア自身がすべてのテストを提起することを意味するものではありません。主なことは、彼が正しい質問を提起し、全員が回答を得るよう動機づけることです。 そしてもちろん、彼は常にリリースに存在し、発生した問題を解決する準備ができています。

実際、勤務中のエンジニアとリリースエンジニアは原則として1人です。

結果

このように行動することで、ほぼ2年間、1か月に1回の重要なリリースを行うことができました。 システムは非常に動的に開発されていますが、週に数回更新することを恐れていません（すべてを計画することはできません：法律は急速に変化しており、ユーザーの成長は過去6か月で非常に重要です）、私たちのエンジニアリング慣行は開発を非常に管理可能で予測可能にします。
技術的な詳細
IDE：Microsoft VisualStudio + JetBrains ReSharper
継続的インテグレーションサーバー： JetBrains TeamCity
バグトラッカー： JetBrains YouTrack
機能テスト： セレン
VCS：Mercurial
Webサーバー：Microsoft IIS + nginx
DB：MS SQLサーバー

PSたぶんこれはテキストから明らかではないかもしれませんが、テスターがいます。 彼はいつも忙しくて、とてもうまく働いています:)
PPS素晴らしいツールを提供してくれた愛するJetBrain社に感謝します:)