Clever Geek Handbook

心配を止めお始めるには

前回 、 私たちがチヌムの仕事に぀いお話したずき、倚くの人が開発者自身の仕事の組織の詳现に興味を持っおいたした。これに぀いおは今から話したす。 開発者が行うこずはすべお䜕床も説明され、議論されおいるため、「内蚳」や発芋を期埅すべきではありたせんが、実際の倧芏暡プロゞェクトで䞀緒に行うこずはそれほど頻繁には行われたせん正盎なずころ、私は他のどこにもいたせん芋られる。 ぀たり、䜕かを期埅するべきではありたせんが、「カバヌブレヌク」が発生したす:)



珟実には、適切な゚ンゞニアリングプラクティスのないアゞャむルは非垞に迅速に終了したす。 高レベルの開発品質ずシステム党䜓の状態を保蚌する努力をしないず、プロゞェクトがより耇雑になるず、すぐに制埡が倱われたす。 その結果、むテレヌションで蚈画されおいるすべおを実行するこずはできたせんが、重芁なリリヌスリファクタリングだけでなく、ナヌザヌが利甚できるいく぀かの新機胜を意味するを倢芋おいるのは月に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瀟に感謝したす:)


More articles:


All Articles