اکنون آزمون باید بگذرد. اوه ، هنوز هم شکست می خورد. چرا این است؟فکر می کنم این مورد لبه را از دست داده ام. من آن را با اضافه کردن این خط ، در اینجا برطرف می کنم. عالی ، گذشت ، اما اکنون دیگری شکست می خورد. عجیب استمن حدس می زنم که این خط پرونده دیگر را شکست. مهم نیست ، من این خط را نیز اضافه خواهم کرد و این باید هر دو را برطرف کند. اوه ، اکنون من یک دسته از آنها را شکسته ام.

آیا تا به حال در چنین شرایطی بوده اید؟آیا با قطار افکار ارتباط دارید؟چه مدت طول کشید تا همه تست ها را طی کنید؟وقتی بالاخره گذشتند ، چه احساسی داشتید؟خلاق ، انرژی و آماده برای ادامه یا تسکین ، خسته و آماده برای استراحت یا تماس با آن یک روز؟چه می شود اگر به محض عدم موفقیت یک آزمایش ، تغییر را برگردانید و از زاویه دیگری به مشکل نزدیک شوید؟

این یکی از ایده های اصلی آزمایش و تعهد ||بازگشت (TCR) ، یک گردش کار برنامه نویسی متولد شده در یک کارگاه Kent Beck (و همچنین به Oddmund Strømme ، Lars Barlindhaug و Ole Johannessen نسبت داده شده است). در این پست وبلاگ ، من سعی خواهم کرد که یک مرور کلی از TCR ارائه دهم.

قبل از اینکه وارد آن شویم ، بگذارید یک سلب مسئولیت کوچک اضافه کنم. من فقط سطح TCR را خراشیده ام. من فقط از آن در پروژه های زمین بازی استفاده کرده ام ، تنها با هدف درک آن. من از آن در کد تولید استفاده نکرده ام و قطعاً در این پست از آن طرفداری نمی کنم. هدف این پست این است که به شما اطلاع دهد که TCR یک چیز است و صرفاً برخی از معاملات آن را که من کشف کرده ام ارائه می دهد.

ایده اصلی

در طول هر گردش کار برنامه نویسی معمولی ، تست ها را زیاد اجرا می کنیم. ما قطعاً قبل از انجام کد این کار را انجام می دهیم. بنابراین ، ایده پشت TCR این است که ما باید هر بار که آزمون ها می گذرد ، مرتکب شویم. اما یک صید وجود دارداگر هر بار که آزمون ها می گذرد ، مرتکب شویم ، باید هر بار که آزمون ها شکست می خورند ، برگردیم. این ساده اما عمیق و قدرتمند است.

استفاده از این دو محدودیت ما را در یک چرخه قفل می کند. دقیقاً مانند TDD ، فقط با یک چرخه متفاوت. از آنجا که یک تست شکست به طور خودکار کد را برمی گرداند ، وضعیت قرمز وجود ندارد. ما همیشه آزمایشات را پشت سر می گذاریم و همیشه خودمان را در حالت سبز می یابیم ، تنها وضعیت موجود است.

چرا باید آن را امتحان کنم

اکنون ، من می فهمم که TCR ممکن است شدید به نظر برسد (برای گفتن کمترین). من از قبل می توانم اعتراضات را بشنوم."اما من کد را از دست خواهم داد"."اما من عاشق دولت قرمز هستم"."اما به نظر می رسد بسیار ناامید کننده"."اما چرا می خواهم این کار را انجام دهم؟"بشراینها اولین افکار من بودند. بنابراین ، بیایید سعی کنیم درک کنیم که چه چیزی را برای به دست آوردن فرصت TCR به دست می آوریم.

قدم های کودک

اگر یک درس واحد وجود داشته باشد که از تمرین TCR آموخته شود ، این موارد زیر خواهد بود:

تنها راه سریع رفتن ، آن را خوب پیش می برد

این نقل قول از عمو باب است ، که روش تفکر من در مورد نوشتن کد مانند چند نفر دیگر را شکل داده است.

ایده اصلی TCR در مراحل کوچک حرکت می کند. حرکت در مراحل کودک. مراحل کوچکبه اندازه کافی کوچک برای اطمینان از گذراندن تست ها. در صورت عدم موفقیت آزمون ، به اندازه کافی کوچک برای از دست دادن یک دسته کد در معرض خطر نیست. فلسفه "قدم بعدی ، کوچک و پایدار است که می توانم به سمت هدف خود برسم؟"بشر

حرکت به جلو در مراحل کوچک و به ظاهر ناچیز می تواند به طرز شگفت آور سودمندتر از بازگشت و عقب باشد.

بازیگونهسازی

TCR را به مدت 10 دقیقه تمرین کنید و نمی توانید به عنصر بازی سازی توجه کنید. ایجاد یک تست با شکست ، احساس اشتباه در یک بازی ویدیویی و مجبور شدن دوباره از این کار است. بازی سازی باعث می شود ما از آن لذت ببریم. و هنگامی که سرگرم کننده هستیم ، تمایل به خلاقیت تر داریم و تمایل داریم راه حل های بهتری را ارائه دهیم (این فقط شهود من است ، از هیچ مطالعه ای که من از آن می دانم پشتیبانی نمی شود). البته این سکه دو طرف دارد ، اما بعداً در مورد این موضوع عمیق بحث خواهیم کرد.

اصلاح مجدد

اصلاح یک قطعه کد نظم و انضباط دارد. به یک سری مراحل کوچک و با اعتماد به نفس نیاز دارد. نیاز به نگه داشتن آزمایشات در همه زمان ها دارد. حقیقت این است که ، حتی با کمک گزینه های خودکار سازی مجدد IDE ، این چالش برانگیز است.

فهمیدم که TCR می تواند در طی فرآیند اصلاح مجدد بسیار مفید باشد. هرگونه اصلاح که تست ها را می شکند به طور خودکار برگردانده می شود. بنابراین ، با تعریف ، تمام حرکات اصلاح مجدد آزمایشات را سبز نگه می دارد.

اما چیزهای بیشتری در آن وجود داردحرکات اصلاح مجدد که تست ها را شکسته می شوند. آنها "زنده نمی مانند" به تعهدات. فقط مواردی که آزمایشات را "زنده ماندن" نگه می دارد. آنها متعهد می شوند و سرانجام تحت فشار و ادغام قرار می گیرند. این زنگ زنگ می زند ، اینطور نیست؟این به نظر می رسد بسیار شبیه یک فرآیند انتخاب طبیعی برای حرکت مجدد است. فقط مواردی که خصوصیات مفیدی را نشان می دهند (آزمایشات را نگه دارید) آن را به تعهدات تبدیل می کنند. تجمع تأثیرات این بازخورد مداوم ، ما را در دراز مدت ماهر تر می کند. بیایید بیش از حد با استعاره دور نشویم ، اما من به شدت معتقدم که استفاده از TCR در هنگام اصلاح مجدد می تواند مهارت های اصلاح مجدد ما را بهبود بخشد.

ابزاری برای درک کد میراث

TCR به خوبی به عنوان یک ابزار یادگیری کار می کند. با فرض اینکه ما یک قطعه میراث میراث داریم که می خواهیم درک کنیم. طبیعی است که وقتی کد را می خوانیم ، فرضیه هایی را شروع می کنیم. فرض کنید اسکریپت TCR را آتش می زنیم و این فرضیات را به عنوان آزمایش واحد بیان می کنیم. اگر فرض صحیح باشد ، آزمون می گذرد و ما فقط با اطمینان یاد گرفتیم که کد آنچه را که فکر می کردیم انجام می دهد انجام می دهد. در صورت نادرست بودن فرض ، آزمایش از بین می رود و از بین می رود. ما یاد گرفتیم که کد چه کاری انجام نمی دهد. بنابراین ، ما فقط دوباره یاد گرفتیم.

این مانند استفاده شفاهی از مشخصات به عنوان مثال در مکالمه با نویسنده کد است. به جز اینکه نویسنده حتی ممکن است اکنون در یک شرکت متفاوت باشد. به جز این که فضای کمتری برای سوء تفاهم وجود دارد ، زیرا مشخصات به صورت کد نوشته شده است. به جز این که وقتی تمام شد ، باید یک مجموعه آزمایشی جامع را حفظ کنیم.

من در مورد این تکنیک جذاب وقتی که به این ویدیو رسیدم ، آموختم ، که آن را به طرز شگفت انگیزی نشان می دهد.

نزونه

با ذکر برخی از مزایای آن ، بیایید نگاهی به برخی از ناراحتی هایی که با TCR همراه است ، نگاهی بیندازیم.

از دست دادن stacktraces و خروجی تست

احساس می کنم که یک نزولی برای نادیده گرفتن بسیار واضح است. این در حال از دست دادن StackTrace یک آزمون شکست خورده است. طبیعی استوقتی یک آزمایش شکست خورد ، می خواهیم درک کنیم که چرا این کار شکست خورده است. با این حال ، از آنجا که تست ها به طور خودکار برگردانده می شوند ، StackTrace از بین می رود.

شاید با پیکربندی دقیق دستور آزمون مورد استفاده شما ، راه هایی در مورد این مسئله وجود داشته باشد ، اما این اولین چیزی بود که وقتی یک آزمایش را شکست داد وقتی که من انتظار آن را نداشتم ، مرا آزار داد.

هرچند این کار در StackTraces متوقف نمی شود. به طور کلی خروجی آزمون با کد برگشتی از بین می رود. ابتدا وقتی از ویژگی unroll Spock استفاده کردم و یک مورد منفجر شد ، ابتدا برای من زحمت کشید.

غیرقانونی که ممکن است ، این بخشی از روند است. TCR از شما می خواهد که از یک زاویه متفاوت به مشکل نزدیک شوید ، یا شاید یک قدم کوچکتر را انتخاب کنید. اشکال زدایی یک آزمون شکست خورده کاملاً هدف را شکست می دهد.

پیام های متعهد

باید بدیهی باشد که تمرین TCR می تواند به راحتی ده ها تعهد کوچک ایجاد کند. در واقع ، باید دقیقاً همین کار را انجام دهد که درست انجام شود. بنابراین ، سؤالاتی که به طور طبیعی دنبال می شود این است که "من با تمام این تعهدات چه کار می کنم؟"و "در مورد پیام های متعهد چیست؟"بشر

اینها را می توان از چند طریق مورد توجه قرار داد. به عنوان مثال ، روش مورد نظر من اضافه کردن یک پیام تعهد پیش فرض (به عنوان مثال "WIP") است. سپس ، هنگامی که من به جایی رسیدم که اگر از TCR استفاده نمی کردم ، در ابتدا مرتکب می شدم ، همه اینها را ، کوچک و WIP متعهد می کنم و آن را مجدداً مورد استفاده قرار می دهم. جدا از این ، روشهای دیگری نیز وجود دارد که نیز کار می کنند ، مانند استفاده از لیست Git Diff به عنوان پیام متعهد.

با این وجود ، این مشکلی است که باید حل شود و به یک روش یا روش دیگر ، یک سربار است.

نا امیدی

تغییر شکل جنبه Gamification فوق الذکر تحریک کننده ای است که TCR می تواند شما را ایجاد کند. واکنش منطقی اول به شاهد کدی که در طی چند دقیقه گذشته (یا ثانیه) که جادویی در مقابل چشمان شما ناپدید می شوند ، ناامید کننده است. گاهی اوقات حتی عصبانیت. در حالی که بازی سازی می تواند یک خلاقانه تر را ایجاد کند ، ناامیدی می تواند منجر به تصمیمات بد و راه حل های عجولانه شود.

متأسفانه ، این می تواند به یک چرخه شرور منجر شود. هرچه کد بیشتر برگردد ، حال و هوای شما بدتر می شود ، که منجر به اشتباهات بیشتری می شود ، که منجر به بازگشت کد حتی بیشتر می شود. کاملاً جالب ، این یک ویژگی خوب TCR است ، زیرا اگر خود را می بینید که کد خود را 10 بار پشت سر هم برگرداند (مثلاً) ، شاید این بهترین نشانه ای باشد که شما باید استراحت کنید.

در هر صورت ، من احساس می کنم که این شاید جالب ترین معامله ای باشد که TCR ارائه داده است. تعادل بین تفریح و احساس عصبانیت و ناامیدی بسیار مهم است. به عبارت دیگر ، برای مؤثر بودن TCR ، چسبیدن به ذات مهم است. و جوهر هدف برای مراحل کودک است.

سوالات باز

یک گردش کار برنامه نویسی برای سفارشی سازی و آزمایش توسط ماهیت آن باز است. TCR ، نسبتاً جدید (ایجاد شده در سال 2018) ، فضای زیادی را برای هر دو باقی می گذارد. بیایید برخی از جنبه هایی را که باز مانده است بررسی کنیم.

تست های بازگشت

نوشتن یک آزمون فقط برای بازگشت مجدد آن ، زیرا شکست خورده است می تواند دلسرد کننده باشد. به خصوص برای افرادی که پیشینه TDD قوی دارند ، که ابتدا برای نصب عادت نوشتن یک تست واحد ناکام تلاش کرده اند. این می تواند به ویژه برای آنها نگران کننده باشد. شاید به همین دلیل است که یک تغییر نشان می دهد که آزمایشات نباید به عنوان بخشی از فرآیند TCR برگردند. به عبارت دیگر ، هنگامی که یک آزمایش از بین می رود ، کد تولید باید برگردد ، اما آزمایش ها نیست.

من به شدت اعتقاد دارم که رویکردهای مختلف ممکن است برای افراد مختلف بهتر کار کند. TCR ابزاری است. این صرفاً به معنای رسیدن به هدف است و نه به خودی خود. بنابراین ، من عمداً تصمیم گرفته ام که این موضوع را در سوالات باز بگنجانیم. من معتقدم که هر دو رویکرد کار خواهد کرد. بنابراین ، برخی از افراد تصمیم می گیرند تست ها را به همراه کد تولید برگردانند و برخی از افراد این کار را انجام نمی دهند.

آنچه با فشار دادن اتفاق می افتد

ما قبلاً در مورد این موضوع با تعهدات بی شماری و کوچک بحث کرده ایم ، اما چه زمانی کد در طول این گردش کار تحت فشار قرار می گیرد؟باز هم ، این یک موضوع انتخاب است. فشار دستی پس از یک دسته از تعهدات کوچک خوب کار خواهد کرد. دقیقاً مانند فشار خودکار با هر تعهد کوچک. سابق احساس "تحویل مداوم" را که همراه با TCR است ، کاهش می دهد در حالی که دومی به احتمال زیاد نیاز به فشار و فشار نیرو دارد. مسئله با پیام های تعهد باید در هر دو صورت حل شود. بنابراین ، دوباره ، من پیشنهاد می کنم آن را به ترجیح شما سفارشی کنید.

تنظیم محیط برای TCR

تمرین TCR به کمی تنظیم نیاز دارد. باید یک روش خودکار برای مشاهده پرونده های منبع و تشخیص تغییرات وجود داشته باشد ، تست ها را اجرا کنید و بسته به نتیجه آزمایشات ، یا کد را متعهد یا برگردانید. روش های مختلفی وجود دارد که می توان از آن به دست آورد. من شخصاً از اسکریپت های زیر استفاده کردم:

• یک اسکریپت Watch. sh که کد منبع را مشاهده می کند ، تغییرات موجود در آن را تشخیص می دهد و اسکریپت TCR را تحریک می کند.

• اسکریپت tcr. sh ، که منطق پایه TCR را در خود دارد:

• اسکریپت test. sh ، که تست های واحد را اجرا می کند

• متن Comment. sh

• و اسکریپت REVERT. SH

من یک مخزن GitHub Ground Playground ایجاد کرده ام. این برای Kotlin و Spock تنظیم شده است و برای آزمایش TCR به من خدمت می کند ، اما احساس راحتی کنید که اسکریپت های Bash را بگیرید یا مخزن را چنگ بزنید و از آن برای بازی با TCR استفاده کنید.

نتیجه

TCR ایده های هیجان انگیز و تازه ای را ارائه می دهد. این برنامه در مراحل کوچک و پایدار متمرکز است ، که برای ایجاد پیشرفت جمع می شوند. این برنامه نویسی را بازی می کند و از جمله موارد دیگر ، می تواند اصلاح مجدد را بهبود بخشد و به عنوان ابزاری برای درک کد میراث کار کند.

معایبی وجود دارد که باید مورد توجه قرار گیرد ، مانند از دست دادن پشته ها و خروجی تست های شکست خورده ، برخورد با تعهدات بی شماری کوچک و برخورد با ناامیدی. همچنین سؤالات باز زیادی وجود دارد ، مانند اینکه آیا تست ها باید به همراه کد تولید برگردانده شوند یا چه زمانی باید کد را تحت فشار قرار دهد.

TCR بسیار شدید به نظر می رسد ، اما من مطمئن هستم که مردم دقیقاً در مورد TDD فکر می کردند وقتی برای اولین بار بیرون آمد.