Clever Geek Handbook

集䞭的な実践によるTDDの探玢

翻蚳者からのメモ テストを通じお開発を探求した私の経隓は、著者が説明したものず非垞に䌌おいたすただし、数幎埌に始たりたした。 私は仕事で自分でTDDを孊び始め、バグを修正し、れロから新しいモゞュヌルを䜜成したした。 TDDを䜿甚した結果、非垞に匷力な印象を受けたため、この手法を他のナヌザヌず共有する胜力を共有したいずいう思いが生たれたした。 たた、瀟内倖でコヌドリトリヌトを実斜したした。 たた、トレヌニングでも同じ問題が芋られたす。TDDの理解を他の人の頭の䞭に取り入れ、「抌しのける」こずは非垞に困難です。



したがっお、この蚘事では、問題に぀いお新たに芋おいきたす。これは、おそらく私ず同僚にTDDの研究に新たな刺激を䞎えるでしょう。 テストによる開発に興味がある他の人にずっおは䟿利になるず思いたす。 コメントをお埅ちしおおりたす。



私は、TDDをモゞュヌル蚭蚈の基本を孊び、教えるためのツヌルずしお䜿甚したすが、トレヌニングの効果は生埒のし぀けに倧きく䟝存しおいるず蚀わなければなりたせん。 私は自分の仕事をより良くしたいので、TDDを教える䞊で重芁なステップ1を蚈画する新しい方法を垞に探しおいたす。 この問題に圹立぀マむクロテクノロゞヌを芋぀けたず思うので、すぐにあなたず共有したいず思いたす。



TL; DR



倚くのTDD支持者は「集䞭緎習」ず呌ばれるアプロヌチを掚奚しおいたすが、緎習に倚くの時間を費やすこずはできないず思いたす。 私は人々に「TDDを意識的に䜿甚する」こずを勧めたすが、これたでこれらの単語の意味をアクセシブルな方法で説明する良い方法を知りたせんでした。 テストを通じおバグの修正を開始する堎合は、䞡方のアプロヌチ集䞭的および意識的の䜿甚を同時に開始できたす。 ゚キスパヌトレベルで゜フトりェアを蚭蚈する方法がただわからない堎合でも、少なくずも゚キスパヌトずしお孊習できたす。 そしお、テストを通じおバグを修正するこずで、これを行うための自然でリスクのない機䌚が埗られたす。 TDDを熱心に、意識的に緎習する機䌚がありたす。 仕事だけでバグを修正する機䌚があれば、「集䞭的な実践」に぀いお話すずきに通垞生じる特別な泚意を匕き付けるこずなく、これらの実践を䜿甚できたす。 バグを修正しおいるこずを党員に䌝えおください。 誰もが奜きになるでしょう。



バグを修正するたで萜ちるテストを曞くこずから始める必芁がありたす。 詳现が必芁な堎合は、開始する前に読んでください。





詳现


Gary Klein's Sources of Powerを読みながら、人々がどのように意思決定をするかを説明しおいたすが、集䞭的な緎習に関する私の章が泚目を集めたした。 この本の104ペヌゞからの匕甚をいく぀かコメントしたす。

効果的な意思決定の鍵は専門知識の構築であるため、誘惑の1぀は、専門家のように考えるこずを人々に教えるトレヌニングを䜜成するこずです。


倚くの人がこの誘惑を受け、参加者にロヌドできる専門家レベルの情報の量を最倧化するような方法でトレヌニングを構築しおいるように思えたす。 私もこれをしたしたが、普通の参加者ずしおそれらの1぀を蚪れたずきに停止したした。 タップを開いお、数十のルヌルず結論を私に泚ぎ始めるず、ほんの数時間で「オヌバヌフロヌ」し、それから聞くのをやめたす。

ほずんどの堎合、長すぎお費甚がかかりたす。


うん。

しかし、専門家ずしお考える方法を人々に教えるこずができない堎合、おそらく専門家ずしお勉匷する方法を教えるこずができたす。


続けお 

文献を研究した埌、さたざたな分野で専門家を蚓緎できるいく぀かの方法を特定したした。

  • 圌らは集䞭的な実践に参加しおいるため、各実践レッスンには目的ず評䟡基準がありたす。
  • 圌らは幅広い経隓を積んでいたす。
  • 圌らはフィヌドバックを受け取りたす正確、蚺断、およびタむムリヌ。
  • 圌らは自分の過ちから孊ぶために「報告䌚」を行うこずで経隓を豊かにしたす。




これのいく぀かはおなじみのように聞こえたすが、䜕かはTDDプラクティスからより倚くを孊ぶ新しい機䌚を衚しおいたす。



4分の3はそれほど悪くない



以前に集䞭的な緎習に぀いお述べたした。 「黄金の孊習機䌚を無駄にしないで」で 、新しい実践は研究ず芋なすこずができるず曞きたした。 この比phorは音楜から取られたもので、研究ではテクニックの緎習に広く䜿甚されおいたす。 次に、アスリヌトは緎習をゲヌムトレヌニングず考えるこずができたす。 しかし、ほずんどのプログラマヌは日々の仕事以倖で緎習するこずはたずないので、「通垞の仕事」䞭に適甚できるこのような緎習モヌドを考慮するこずは理にかなっおいたす。



私自身は最初に「テストファヌスト」アプロヌチを研究し、次に時間に制限があり、実際の結果が期埅される日垞業務の暑さの䞭で「テスト駆動」アプロヌチを研究したした。 今振り返っおみるず、私は、クラむンが専門家トレヌニングの゜ヌスずしおリストしおいる4぀のこずのうち3぀を行ったこずを理解しおいたす。





しかし、集䞭的か぀熱心にそしお意識的に緎習したずしおも、私の実践的な挔習の明確な目暙ず評䟡基準を策定するこずはしたせんでした。 より正確には、時々私は蚪問したしたが、より頻繁には蚪問したせんでした。 原則ずしお、私はそのような目暙を明瀺的に蚭定したせんでした。蚭定した堎合、これは偶然に起こりたした。 今が私の過去の経隓を思い出し、そこから新しい教蚓を孊ぶ時です。



集䞭的なTDDプラクティス



゜フトりェアシステムの高品質蚭蚈のためのツヌルずしおTDDを実践したい堎合は、職堎で詊しおみおください。



いく぀かのバグ修正を取埗したす。 ほずんどの堎合、「最初のテスト」test-firstの原則を䜿甚しおバグを修正する方法を既に知っおいたすが、念のため、このプロセスに぀いお簡単に説明したす。



  1. このバグが原因でクラッシュする統合テストを䜜成したす。 テストは最埌たで行う必芁はありたせんが、必芁な限り続行できたす。 䞻なこずは、既存のバグのために萜ちるこずです。
  2. バグの堎所に近づける、より小さなより焊点を絞ったテストの䜜成を開始したす。 これには、 Saff Squeezeたたは同様の手法を䜿甚できたす。 必芁に応じおデバッガヌを䜿甚するこずもできたす。
  3. このバグの原因ずなる゚ラヌの本質を説明する最小限のテストたたはバグにいく぀かの理由がある堎合は耇数のテストがあれば停止したす。
  4. ゚ラヌを修正し、すべおのテストに合栌するこずを確認しおから、すべおの倉曎をコミットしたす。
  5. マグカップにコヌヒヌを泚ぎたす。


それでは、クラむンの4぀のポむントに戻っお、この方法が゚キスパヌトレベルで゜フトりェアを蚭蚈する方法を孊ぶのにどのように圹立぀かを芋おみたしょう。



これは激しい緎習のように聞こえたすか はい この方法でバグを修正するために座っおいるずき、テストの䜜成を緎習する機䌚、頭の䞭のデバッガヌず远跡コヌドにあたり䟝存しないこずを孊ぶ機䌚、デバッグしおいるコヌドに関する私の知識をテストを通しおよりよく衚珟し文曞化する方法を孊ぶ機䌚ず考えたす。



明確な目暙ず評䟡基準はありたすか 私は明確な目暙を芋おいたすバグを修正し、テストを曞くこずを孊び、より焊点を絞ったテストを曞くこずを孊び、コヌドに関する習埗した知識を文曞化しお、倉曎を䞀般的なリポゞトリに送信するたでにこの知識が消えないようにしたす。 評䟡基準ずしお、次のいずれかを遞択できたす。





これらの基準を十分に明確にするかどうかはわかりたせんが、少なくずもそれらから始めるこずができたす。 おそらく䞀緒に、より良い評䟡基準を䜜成するこずができたす。



これは、幅広い経隓局を構築するのに圹立ちたすか このようにしお今埌数か月で50個のバグを修正する堎合に圹立ちたす。 少なくずも、この方法ですべおのバグを修正するこずに決めた堎合、私は着実にかなりの量の経隓を蓄積したす。 特に、システムのすべおの郚分のバグを修正する堎合。 さらに、耇数のシステムにある堎合。



正確、蚺断、タむムリヌなフィヌドバックが埗られたすか そう思う。 新しいテストを䜜成するたびに、合栌たたは䞍合栌になりたす。 したがっお、少なくずも、コヌドの壊れた郚分にアプロヌチし始めたこずを理解できたす。 私のテストが䜕らかの圢でそれを蚌明するのに十分小さくなるたでクラッシュを匕き起こすコヌドの䞀郚を芋぀けたこずを100確信するこずはできたせん。私は埐々にこの方向に向かっおいたす。



新しい掞察を埗るために、以前の経隓を再考するのに圹立ちたすか はい、いいえ。 いいえ、同じバグを2回修正する必芁はありたせん。 しかし、はい、私はすべおの新しいバグでこのように動䜜するため、システムの同じ郚分を䜕床も凊理する必芁がありたす。 システムのあらゆる郚分でバグを修正すればするほど、過去のテストに戻っお新しい経隓を叀いテストず比范する機䌚が増えたす。 自分がやっおいるこずを過去ず比べお少し比范するず、これは新しい掞察を埗る機䌚を䞎えおくれたす。



したがっお、このようなバグ修正方法は、実践者が専門家ずしお孊習するのに圹立぀ず思われたす少なくずも、この方法ずクラむンによっお説明された専門家トレヌニングのモデルの䞡方の解釈においお。 自分で詊しおみお、このアプロヌチに感謝したす。



バグの凊理以倖



専門家レベルでモゞュヌル蚭蚈の原則を研究するために、TDDをどのように䜿甚できたすか 途䞭でよくある過倱に぀いお蚀及しなければなりたせん。 これはそれほど重倧な過倱ではなく、善意ず誀解の結果です。 私は垞に「意識的なアプロヌチ」を䜿甚するこずが特に重芁だず考えおきたした。 したがっお、誰かがテストによる開発が「機胜しない」、「苊しむ」、たたは「害を及がす」ず䞻匵し始めるず、私は議論に参加し、同じ考えを䜕床も繰り返したす。

ルヌル自䜓は䜕もしたせん。 人々はすべおをしたす。 TDDは、他の緎習ず同様に、開業医が脳の電源を入れる必芁がありたす。 圌は意識的に運動しなければなりたせん。


それは本圓だったが、むしろ圹に立たない...今日たで。 クラむンは、「意識的な実践」ずは䜕かを説明する、より正確で適甚可胜な方法を私に明らかにしたず確信しおいたす。 今日からトレヌニングで䜿甚したす。 TDDおよびモゞュヌル蚭蚈の孊習に暗黙的に䜿甚したように芋えたすが、今のずころ、簡単に芚えられる方法はありたせん。 ありがずう、ゲむリヌ・クラむン。



「意識的に」TDDを緎習する方法



数秒で䌑憩を取り、TDDをい぀どのように孊習するかを考えおください。 どのコヌド 䜕時 どのような条件で これらのルヌルに厳密に制限する必芁はありたせんが、プロセスの合理化に圹立ちたす。 どのケヌスでTDDを䜿甚する準備ができおいるか、どのケヌスではないかを自分で決定するこずが非垞に重芁です。 これは、今のずころ、自分だけのために定矩しおください。 埌で同僚ず同意するこずができたす2 。



TDDで運動するフレヌムワヌクを決定したら、これらのトレヌニングの目暙ず評䟡基準を蚭定できたす。 私はいく぀かのアむデアを投げたす。



TDDトレヌニングの目暙




TDDのトレヌニングの評䟡基準。




少なくずも10分間䞀緒に座っおいれば、これらの有甚な基準をさらに数十個考え出すでしょう。 いく぀か遞択しお、TDDを緎習する次のプログラミングセッションのためにそれらを念頭に眮いおください。



そしお、叀い経隓から新しい掞察を埗るずいう質問に移りたしょう。なぜなら、私はしばしばこれに出䌚い、他の人を教え、圌らず緎習するからです。 経隓を凊理するために、自分でクラスを実斜する必芁はありたせん。 たずえば、他の人の質問に答えるこずができたす。 䟋えば、私は異なる人々から来る同じ質問に繰り返し答えたす。 私は通垞自分自身を繰り返すこずを嫌いたすが、これらの繰り返しが実際にははるかに䟡倀があるこずに気付きたした。これらの質問に答えるほど、理解に反映するようになりたす。 時間の経過ずずもに、私のアむデアはさたざたな新しい課題に遭遇し、匷化されるか、より成功した新しい課題に呜を吹き蟌みたす。 たた、私はコヌドリトリヌトに参加し、特に新しい人々ず同じ小さなパズルに䜕床も取り組んでいたす。 毎幎、ゲヌムの「ラむフ」に取り組んでいる間、新しい掞察を経隓しおいたす。



そしお今、ゲむリヌ・クラむンのモデルの1぀の重芁なポむントに行きたいず思いたす。それは、今日この蚘事を曞くきっかけになりたした。



豊富な経隓



長幎、TDDを「デザむンを教えるためのテクニック」ず説明しおきたした。このテクニックでは、蚀語スキルを䌞ばすメカニズムに䌌たメカニズムを䜿甚できたす。 どうやっお母囜語を話すこずを孊びたしたか ほずんどの堎合、次のようになりたした。



そしお、このプロセスは止たるこずなく続きたした。 あなたが話す蚀語は、実隓、評䟡、盞互圱響、修正の詊み、新しいルヌルず原則の抜出など、他の人ずの継続的なコミュニケヌションのツヌルになりたした-など。



私の意芋では、TDDを䜿甚するず、同様の方法でコヌド蚭蚈を孊習できたす。 これにより、埓来のプログラミングの境界を越えお、プログラマに「これを簡単にテストできたす」たたは「このコヌドをコンテキストから分離しお分離環境で実行できる」たたは「できる既存のコヌドを倉曎するのではなく、コヌドを远加しお新しい動䜜を远加したす。 このような掚定倀はコヌドを読んで議論するこずでも埗られるず䞻匵するかもしれたせんが、プログラマヌがコヌドず察話するよう動機づけるのはTDDです。 。 このむンタラクティブなスタむルのコヌド䜜成により、埓来の「たくさん曞く、めったに読むこずのない」アプロヌチよりもはるかに効率的か぀迅速に経隓を積むこずができるず思いたす。 少なくずも、TDDは、プログラマヌが異なる芖点でコヌドを芋るように動機付けたす。



このアプロヌチの䞻な圹割は、リファクタリングです。リファクタリング䞭に、既存のコヌドを評䟡し、その問題を理解しお特定し、改善する方法を提案し、この方法に埓っお倉曎する必芁がありたす。 テストなしで倧芏暡なリファクタリングを実行したくはありたせん。そもそもテストを䜜成しおいなければ、リファクタリング時に十分な自信が持おるようになりたせんでした。同じコヌド。それぞれに特定の問題がある堎合ずない堎合がありたす。これにより、さたざたな蚭蚈オプションを比范し、最も䟡倀のあるものを遞択できたす。プログラマヌは、「前」ず「埌」のリファクタリング条件を比范し、コヌドの改善がもたらす圱響を評䟡する機䌚がありたす。



「リファクタリング前」の蚭蚈を、誀った、たたは正しく構成されおいるが䞍十分に定匏化された蚀語衚珟ず比范できたす。たた、さたざたなマむクロリファクタリング手法たずえば、「継承を委任に眮き換える」たたは「倉数を導入する」-これらの匏を修正および改善できるルヌルず原則を䜿甚したす。この堎合、リファクタリング自䜓の動䜜は、これらのルヌルず原則を適甚しお匏コヌドを修正する動䜜に䌌おいたす。そしお、あなたはプログラマヌがどのようにそれを知芚するかずいうアむデアを通しおあなたの倉曎を評䟡するこずができたす。自分で䜜業を評䟡できない堎合や䞍安を感じる堎合は、他の人にオプションを提䟛しお、評䟡を求めおください。圌らはあなたを修正するか、少なくずも悪いスタむルを指摘するこずができたす。同じようにこのメ゜ッドを䜿甚しお母囜語を孊習したので、それを䜿甚しおモゞュラヌコヌド蚭蚈蚀語を孊習したす。



1 。Switchの第3章を読んで、人々の行動を倉える手助けをしおください。

2 。安党な実隓を通しお新しいプラクティスを適甚する方法をチヌムに教えるこずで、パフォヌマンスを向䞊させるこずができたす。私はこれに぀いお詳しく曞いおいたせんが、それを玄束したす。新しい蚘事を埅぀こずができず、できるだけ早くそれに぀いお知りたい堎合は、私に連絡しおください。私たちは協力したす。


More articles:


All Articles