فصل ۷ — طراحی افزایشی و Practiceهای یکپارچهٔ XP | Learning Agile

فصل ۷ — طراحی افزایشی و Practiceهای Holistic در XP

وقتی دو بخش Code به هم وابسته‌اند، Change یکی بدون فکر به اثرش روی دیگری دشوار می‌شود. Monolithic Design معمولاً Code به‌شدت Coupled دارد؛ Unit معمولی Connectionهای زیادی به بخش‌های دیگر System دارد و Change آن Frustrating است. همین Coupling اغلب Shotgun Surgery و Antipatternهای دیگر را می‌سازد. Connectionهای پنهان میان Unitها Rework ایجاد می‌کنند و Rework Bug می‌آورد.

همان‌طور که Code می‌تواند Coupled باشد، می‌تواند Decoupled هم شود: Connectionهای غیرضروری را بشکنید، یا بهتر، اصلاً ایجاد نکنید. Code Smell و Refactoring ابزار این کارند.

به Example Bee Hive برگردید. دو Method برای Move Bee Extract شد. اگر این Methodها داخل Unit بزرگی باشند که Initialization سنگین می‌خواهد، Developer با Habit خوب هنگام Reuse Smell «Half-baked Code» را حس می‌کند و Refactor می‌کند تا Dependency اضافی حذف شود. حالا Method در چند قسمت Codebase استفاده می‌شود و لازم نیست بداند Caller کیست؛ از Caller Decouple شده است.

System زمانی آسان‌تر Maintain می‌شود که از Unitهای کوچک و Independent ساخته شود و هر بخش تا حد عملی ممکن از بقیه Decouple باشد. Dependency کم، Change بدون Rework گسترده را ممکن می‌کند. اگر Shotgun Surgery دیدید، Refactor را امروز انجام دهید، نه فردا؛ Codebase را بهتر از چیزی که تحویل گرفتید باقی بگذارید، با Unitهایی که هرکدام یک Task روشن انجام می‌دهند.

Incremental Design و Holistic XP Practices

در فصل ۶ ده مورد از سیزده Primary Practice را در Programming، Integration، Planning و Team دیدیم. سه Practice باقی‌مانده آن‌قدر به هم وابسته‌اند که نویسندگان آن‌ها را Holistic Practices می‌نامند. برخلاف Practice مستقلی مثل Pair Programming یا Weekly Cycle که می‌توان با Baby Step جداگانه Adopt کرد، این سه Practice واقعاً فقط در Context کل XP معنا می‌دهند:

1. Incremental Design
2. Energized Work
3. Whole Team

Incremental Design

Incremental Design برای فرد تازه‌وارد به XP شاید دشوارترین Primary Practice باشد. Exampleهای خوب در Projectهای Mature Open Source مثل Linux، Apache HTTP Server و Firefox دیده می‌شود. این Projectها Core پایدار دارند و Featureهای اضافی با Plug-in Architecture یا Separation مشابه از Core جدا می‌شوند؛ فقط Featureهای Stable و Reused به Core راه پیدا می‌کنند.

Developerهای این Projectها معمولاً Refactor مداوم، Test زیاد و Continuous Integration دارند. بسیاری از Practiceهای XP نیز در چنین Communityهایی شکل گرفته یا صیقل یافته‌اند.

هر Developer Unit Decoupled خودش را تقریباً مستقل می‌سازد، با اعتماد به اینکه Unitهای دیگر هم Decoupled هستند و Clash کم است. با این حال Project در Vacuum نیست: همه روی یک Codebase کار می‌کنند، CI خودکار و Manual دارند، Code Smell را جدی می‌گیرند و مسئول Fix فوری آن هستند. Refactoring به انتهای Project موکول نمی‌شود. Result این است که Codebase در طول زمان به‌صورت Incremental و تقریباً Organic رشد می‌کند، حتی با Team بزرگ و Distributed.⁷

⁷ برای Open Source Teamها کتاب‌های Eric S. Raymond، The Cathedral and the Bazaar، و Karl Fogel، Producing Open Source Software معرفی شده‌اند.

Incremental Design در هسته یعنی Design Decision را در Last Responsible Moment بگیرید و از Trap «همه‌چیز را یک‌باره بساز» دور شوید. Teamی که همه چیز را اول Project Design می‌کند ممکن است Future Edge Case را بیش از حد حل کند، Hook زیاد بگذارد یا Framework بزرگ برای Problem کوچک بسازد. وجه مشترک همه: تصمیم‌های Design زیادی خیلی زود گرفته شده‌اند.

اگر Team Habit ساخت Unit کوچک، Solid، Independent و Decoupled دارد، Complete Design Up-front لازم نیست. High-level Design کافی است. وقتی Edge Case تازه کشف شد Tool و Habit لازم برای Handle کردنش وجود دارد. Code Piece-by-piece با Learning Team رشد می‌کند.

اما این فقط وقتی کار می‌کند که همه واقعاً باور داشته باشند ساخت Piece کوچک امروز و Fixکردن فردا ــ اگر لازم شد ــ سریع‌تر و بهتر از Overdesign امروز است.

شکل ۷-۱۱ — Incremental Design به System Robustتر و Maintainableتر می‌انجامد.

تیم زمانی بهترین کار را می‌کند که احساس کند برای فکرکردن زمان دارد

«Software Development بازیِ Insight است و Insight سراغ ذهن آماده، استراحت‌کرده و Relaxed می‌آید.» — Kent Beck

یکی از دشمنان Incremental Design، Pressure دائمی است. Teamی که احساس می‌کند هیچ Time ندارد، هر کاری را که فوراً Line of Code اضافه نمی‌کند Extra می‌بیند. Developer می‌گوید «وقت Refactor ندارم، Feature بعدی را باید بزنم» و Coupling و Smell تولید می‌شود. Bossی که Artificial Deadline ناممکن را Motivation می‌داند، Barrier جدی XP است و Projectهایش احتمالاً Late و گاهی Failed می‌شوند.⁸

XP پاسخ را در Energized Work و Whole Team می‌بیند.

Energized Work

Energized Work یعنی Environmentی که به هر فرد Time و Freedom کافی برای درست انجام‌دادن Job بدهد. در این Mental Space Habit خوب شکل می‌گیرد و Code Changeableتر می‌شود؛ در نهایت Team Feature بیشتر و Valuableتر را در Time کمتر تحویل می‌دهد.

Software Development تقریباً تماماً Mental Exercise است.⁹ Developer ممکن است ساعت‌ها به Problem خیره شود و Solution هنگام Dinner، Shower یا Bike Ride به ذهنش برسد. Project از زنجیره‌ای از همین Innovationهای کوچک ساخته می‌شود.

برای رسیدن Developer به Flow یا تمرکز عمیق معمولاً 15 تا 45 دقیقه زمان لازم است.¹⁰ Interruption او را از Flow بیرون می‌کشد. Under Pressure شدید، ذهن به «فقط Code را بیرون بده» مشغول است و احساس می‌کند Time برای Thinking ندارد.

Disrespect، Unrealistic Deadline و رفتار بد Manager یک Unenergized Environment می‌سازد؛ جایی که افراد Autonomy و Mental Space برای Decision خوب و Innovation ندارند. وقتی همیشه «عقبیم»، Team Corner Cut می‌کند، TDD/Refactor/CI را کنار می‌گذارد و از Flow دور می‌شود.

XP عکس این را می‌خواهد: Environmentی که هر فرد Autonomy دارد دربارهٔ Work خودش، Code، Plan و حتی نحوهٔ اجرای Project تصمیم بگیرد. Weekly Cycle جلوی Decision Up-front غیرضروری را می‌گیرد و Slack Flexibility Plan را بالا می‌برد. Codebase Decoupled نیز Choice آینده را باز نگه می‌دارد.

اصل Agile Sustainable Pace را به یاد بیاورید: Sponsor، Developer و User باید بتوانند Pace ثابت را نامحدود حفظ کنند. Courage لازم است تا Team در برابر Pressure ناسالم Sustainable Pace را نگه دارد.

بسیاری از XP Practitionerها Energized Work، 40-hour Work Week و Sustainable Pace را نزدیک به هم می‌دانند. تاریخ 40-hour Week با شعار «هشت ساعت کار، هشت ساعت تفریح، هشت ساعت استراحت» پیوند دارد. Studyهای Productivity نیز نشان داده‌اند Work Week بسیار طولانی Productivity را کم و Quality Problem را زیاد می‌کند. XP Team می‌داند Life خارج از Office بخشی از Quality Work است.

Whole Team: اعتماد و تصمیم‌گیری جمعی

«مردم به حس Team نیاز دارند: ما متعلق به این جمعیم. همه با هم در این کار هستیم. از Work، Growth و Learning یکدیگر پشتیبانی می‌کنیم.» — Kent Beck

Team عالی بیش از مجموع افرادش Value ایجاد می‌کند، چون Skill و Perspective مختلف در Environment Communication و Mutual Respect، Innovation را تغذیه می‌کند.

Whole Team یعنی Individualها واقعاً یک Whole بسازند. با Obstacle با هم مقابله می‌کنند؛ Decision مهم Direction Project را با هم می‌گیرند؛ و به یکدیگر Trust می‌کنند که تشخیص دهند چه Decisionی فردی است و چه چیزی باید برای Team آورده شود.

همه در Discussion دربارهٔ Value Feature، Work قابل قبول و نحوهٔ ساخت Software شریک‌اند. اگر هر Member برای Coding Decision جهت Deliver بیشترین Value Trusted باشد، Risk Gold-plating فردی کم می‌شود.

روی دیگر Trust این است که همه Mistake می‌کنند. Whole Team سالم از Mistake نمی‌ترسد، چون می‌داند Error طبیعی است و Team با هم Learn و Recover می‌کند.

Practiceهای Design، Planning، Team و Holistic یک Ecosystem نوآوری می‌سازند

Whole Team در Energized Environment بهتر از Team Disconnect در فضای خفه‌کننده Design می‌کند. Innovation در XP مفهوم Lofty نیست؛ واقعیت روزمره است. Developerهایی که Flow را تجربه می‌کنند و Informative Workspace/Osmotic Communication دارند از Ideaهای یکدیگر تغذیه می‌شوند. Incremental Design نیز Canvas نسبتاً خالی به هر Developer می‌دهد، چون Constraint زودهنگام کم است.

Manager خوب Trust می‌کند Team Value را بفهمد و Climate‌ای می‌سازد که Focus روی Product بهترین باشد، نه Deadline غیرواقعی. چنین Teamی Faster کار می‌کند و Product Changeableتری می‌سازد.

شکل ۷-۱۲ — همهٔ Practiceهای XP به هم مربوط‌اند و یکدیگر را تقویت می‌کنند.

این همان دلیل تأخیر معرفی Holistic Practiceها تا فصل ۷ است. اگر آن‌ها را جدا و Checklistی اجرا کنید، شاید Result بهتر از هیچ بگیرید اما Design Software عمیقاً تغییر نمی‌کند.

در XP Team با Mindset درست، Practiceها Ecosystem می‌شوند:

• Test-first → Unit کوچک، Independent و Decoupled.
• Unit کوچک → Smell و Antipattern آسان‌تر Refactor می‌شود.
• Sit Together + Pairing → Whole Team و Energized Work/Feedback بهتر.
• Continuous Integration → Defect بین Pairها Fail-fast آشکار می‌شود.
• Unit Test → CI Failure را دقیق‌تر Catch می‌کند.
• 10-minute Build → Integration Frequent و Interruption کمتر.
• Slack + Sustainable Pace → Time واقعی برای Refactor و Technical Debt.

برای Developerی با XP Mindset این‌ها «روش طبیعی ساخت Software» احساس می‌شوند. Team بدون Mindset اما در Practiceهای منفرد دفن می‌شود و وقتی همه Test می‌نویسند، Pair می‌کنند، Weekly Cycle و CI Server دارند تصور می‌کند XP کامل شده؛ سپس Ecosystem Effect را نمی‌بیند، درست مثل Scrum Teamی که Practice دارد اما Hyperproductivity ندارد.

Incremental Design در برابر Designing for Reuse

Auke Jilderda در مصاحبه‌ای برای Beautiful Teams توضیح می‌دهد Designing for Reuse اغلب Approach مناسبی برای Software Development نیست. Pattern Open Source بیشتر use → use → reuse است: ابتدا چیزی را برای یک Use بساز؛ نفر دیگر آن را برای Need خودش Modify و Reuse می‌کند؛ بعد که Commonality واقعی دیده شد Function مشترک را Refactor کن. Design for Reuse بیش از حد Static است.

Unix Toolset Example کلاسیک Incremental Design است. هزاران Developer طی دهه‌ها Pieceهای کوچک و بزرگ به آن اضافه کرده‌اند. Toolهایی مثل cat, ls, cut, awk, sed, grep هرکدام Job مشخص دارند و برای ترکیب‌شدن ساخته شده‌اند.

مثال کتاب: File آدرس comma-delimited با نام addr.txt شامل Name، Title، Email، Phone، Address، City، State و Zip. برای استخراج Name، Title و Phone افراد Minnesota می‌توان Command زیر را ترکیب کرد:

egrep ",MN,[0-9]{5}([-][0-9]{4})?$" addr.txt | cut -d, -f1,2,4 > output.txt

Toolها برای Address Book خاص طراحی نشده‌اند. Philosophy آن‌ها Simplicity است: هر Tool یک کار Straightforward می‌کند و Output هر Tool Input Tool دیگر می‌شود. cut Field می‌بُرد؛ grep Line مطابق Pattern را عبور می‌دهد. ترکیب آن‌ها Taskهای بی‌شمار حل می‌کند.

وقتی gzip در 1992 اضافه شد، Pattern از قبل روشن بود: Input/Output با Pipe، Execution از Command Line و Documentation در Man Page. چون Toolها Decoupled و Independent بودند، Compression بدون Change در بقیه System اضافه شد. Over دهه‌ها System تقریباً Organic رشد کرد و Culture/Knowledge Community هم همراهش رشد کرد.¹²

¹² کتاب برای فهرست جامع Unix Tools به Wikipedia اشاره می‌کند.

¹³ مثال Toy همه Edge Caseها مثل Address غیرآمریکایی، Header Row یا Quoted Comma را Handle نمی‌کند؛ کتاب صریحاً می‌گوید روی این Edge Caseها تمرکز نکنید.

Interaction ساده میان Unitها رشد Incremental System را ممکن می‌کند

Unix Toolها Contract سادهٔ Input/Output دارند. | Output یک Tool را Input دیگری می‌کند، < Input از File و > Output به File. همین Contract ساده Extensibility را بالا می‌برد.

در هر System Incremental، Contract بین Unitها باید Simple باشد: Message؟ Method Call؟ Network Service؟ هرچه Mechanism Interaction Consistent و ساده‌تر باشد Addکردن Unit آسان‌تر است.

چطور Contract را Simple کنیم؟ باز هم Decision را در Last Responsible Moment بگیریم و از Test-first Programming استفاده کنیم. Developer Unit Test را قبل از Unit می‌نویسد و Unit را قبل از وجود Actual Code «مصرف» می‌کند؛ Complexity Interface زود دیده می‌شود. Integration Test هم می‌تواند Interaction چند Unit را قبل از Implementکردن Communication مشخص کند.

اگر Contract Simple باشد Integration Test نوشتن آسان است. اگر Complex باشد Test مجبور به Initialize Objectهای نامرتبط، Translate فرمت‌های مختلف و عبور از Hoopهای زیاد می‌شود؛ خود Test Smell Complexity را قبل از ورودش به System نشان می‌دهد.

Design عالی از Interaction ساده Emergent می‌شود

Emergence یعنی Behavior پیچیده از System ساده پدیدار شود؛ مثل Ant Colony که هر Ant Behavior ساده دارد اما Colony Behavior پیچیده دارد. Emergent Design نیز وقتی است که Behavior System بیشتر از Interaction Unitها پدیدار می‌شود تا از یک Controller مرکزی.

Emergent System معمولاً Unitهای کوچک، Independent و Decoupled دارد و به‌جای Call Hierarchy عمیق، Message، Queue یا Mechanism سادهٔ Communication استفاده می‌کند. Unix Pipe Example روشن است.¹⁴

¹⁴ Ant هم Unit Decoupled است و با Pheromone Communication ساده دارد.

در XP Team مؤثر:

• هر Unit برای Use مشخص Design می‌شود.
• Test-first تضمین می‌کند همان Function لازم را انجام دهد و وقتی Test Pass شد Code اضافه متوقف شود؛ Behavior بی‌دلیل اضافه نمی‌شود.
• Call Stack عمیق Avoid و Structure Flat/Wide ترجیح داده می‌شود.
• Interaction Unitها Simple است؛ اگر ممکن باشد Message Queue Dependency Source را هم حذف می‌کند.
• Change جدید با Modify Unit یا Interaction ساده انجام می‌شود و Cascade کمتر است.
• Shotgun Surgery، Spaghetti یا Half-baked Object Warning بزرگی است که Complexity برگشته و Refactor لازم است.

System Emergent می‌تواند سال‌ها Grow کند و Maintainable بماند. Flexibility به Team Confidence می‌دهد Design Decision بیشتری را تا Tomorrow عقب بیندازد و Code امروز Simple بماند. Team Relaxedتر، Collaborativeتر و Fastتر می‌شود و Change Bug کمتری می‌سازد.

یعنی Code Simple می‌ماند و همین به Team اجازه می‌دهد Change را Embrace کند؛ و این Point اصلی XP است.

پردهٔ پنجم: امتیاز نهایی

تقریباً یک سال از زمانی که Danielle XP را معرفی کرده بود می‌گذشت. او و Justin Pair Programming می‌کردند که Danielle فهمید این اولین بار در حدود سه ماه است دوباره با هم Pair شده‌اند، چون Partnerها را آن‌قدر Rotate کرده بودند که Justin تقریباً با همهٔ Team کار کرده بود.

Team هر Week Release می‌داد و Cycle اخیر برای Campaign تبلیغاتی با TV Network بزرگ بود که تازه Production شده بود. Danielle پرسید آخرین بار چه زمانی Late Work داشتند. Justin گفت باید Phone را نگاه کند تا آخرین Apology Text را پیدا کند؛ مدت زیادی گذشته بود.

Danielle گفت احتمالاً چون در این کار بهتر شده‌اند و Code او از شش ماه قبل خیلی Simpleتر است. Justin اعتراف کرد TDD اول خیلی Theoretical به نظر می‌رسید اما حالا طبیعی است؛ قبلاً Team دائم دربارهٔ ارزشش Argument می‌کرد، حالا مدت‌هاست کسی نیاز به Convince ندارد. Danielle حتی حس نمی‌کرد خیلی متفاوت کار می‌کند.

Bridget که Conversation را شنیده بود گفت از دید او همه چیز فرق کرده. قبلاً Job اصلی‌اش Convinceکردن Product Manager برای Time بیشتر بود؛ Team همیشه Late بود و هر درخواست Months طول می‌کشید. حالا معمولاً حتی برای Request بزرگ می‌گوید «yes»، چون Team Change را بهتر Handle می‌کند. Danielle گفت شاید به همین دلیل Bridget دیگر Yell نمی‌کند و آن‌ها Weekend Work ندارند.

Bridget شوخی/نیمه‌شوخی پرسید: «پس یعنی می‌توانید Work بیشتری برای من انجام دهید؟» Justin فکر کرد Joke است، Danielle مطمئن نبود و گفت: «فکر کنم هنوز Learning ما تمام نشده.»

نکته‌های کلیدی

• Developer با Refactoring مداوم Code Smell را Fix می‌کند: Structure بهتر بدون Change Behavior.
• Refactor بی‌رحمانه Technical Debt را کم می‌کند.
• Slack باید Time برای Refactor و Pay down Debt بدهد.
• Continuous Integration Problem Integration را زود پیدا می‌کند.
• Refactor + Debt Reduction + Fix Smell = Codebase آسان برای Change.
• Incremental Design از Code Decoupled با Unitهای کوچک و Independent ساخته می‌شود.
• Team فقط Unit مورد نیاز Problem فعلی را می‌سازد و Decision بعدی را به Last Responsible Moment می‌سپارد.
• Energized Work Sustainable Pace و Time برای Doing Job Right می‌دهد.
• Whole Team بر Trust و Membership واقعی همه بنا می‌شود.

پرسش‌های متداول

Incremental Design خیلی تئوریک به نظر می‌رسد؛ واقعاً کسی این‌طور Software می‌سازد؟

وقتی کسی می‌گوید «Theoretical»، گاهی منظورش «امتحان نکرده‌ام و سخت به نظر می‌رسد» است. XP Practiceها Skill واقعی‌اند و باید مثل Music تمرین شوند. خرید Guitar و Book یک‌شبه Musician عالی نمی‌سازد؛ اجرای Practice بدون Practice و Learning هم XP عالی نمی‌سازد. تکرار Mistake بدون Reflection Improvement نمی‌آورد.

Technical Debtهایی که به‌عنوان Slack می‌گذاریم هیچ‌وقت انجام نمی‌شوند. چه کنیم؟

اگر هیچ Slack Itemی انجام نمی‌شود، Weekly Cycle Overloaded است. Slack Optional نیست؛ فقط Itemی است که نبودش مانع «Done Done» Delivery نمی‌شود. بیشتر Slackها باید تکمیل شوند. در Planning Item کمتر وارد Cycle کنید.

اگر فقط Technical Debt همیشه عقب می‌افتد، Mindset Problem است. Trap رایج: Debt را در Ticket/Spreadsheet/Backlog «ثبت» می‌کنیم و خیال می‌کنیم Acknowledgeکردن کافی است. چون Feature جدید Priority بالاتر دارد، Debt هیچ‌وقت Fix نمی‌شود.

XP Technical Debt را برای «زیبایی» Fix نمی‌کند؛ Fix می‌کند چون Future Value Delivery را آسان می‌کند. مثل Credit Card، می‌توان ماهی پرداخت نکرد اما Debt در طول زمان Crushing می‌شود.

اگر Debt جمع شده Openly Discuss کنید: External Feature Pressure؟ باور نکردن Importance؟ Reward Culture که Feature «sexy» را تشویق و Plumbing را نامرئی می‌کند؟ اگر Promotion برای New Feature است، عقب‌انداختن Debt Rational می‌شود. Root Cause Culture را ببینید.

Self-similarity فقط Buzzword دههٔ 1990 نیست؟

خیر. Self-similarity یعنی Pattern در Scaleهای مختلف تکرار می‌شود. Software Solid، Reliable و Easy-to-use معمولاً Layerهایی با همین صفات دارد؛ Layerها از Unitهای Solid و Simple ساخته‌اند؛ داخل Unit هم Code قابل فهم است.

در Energized Work نیز Team Flow وقتی شکل می‌گیرد که Individual Developer بتواند وارد Flow شود. در Planning: Developer Test را Plan و Code می‌سازد؛ Team Feature را Plan و Weekly Cycle اجرا می‌کند؛ Theme را Plan و Quarterly Cycle اجرا می‌کند. لازم نیست همه‌چیز را با این Principle توضیح دهید، اما Patternها Understanding می‌دهند.

شنیده‌ام TDD مرده است. درست است؟

TDD Tool است؛ گفتن «TDD مرده» مثل گفتن Screwdriver مرده است. Teamهای زیادی هر روز استفاده و Success کسب می‌کنند.

اما Debate عمق دارد. برخی Teamها TDD را از Tool به Orthodoxy تبدیل می‌کنند و Test را Goal می‌دانند، نه وسیلهٔ Software بهتر. Framework Trap وارد Test می‌شود: Test Framework بسیار Complex، Mock Object سنگین، 100% Coverage مصنوعی، Test سخت‌تغییر یا Commented-out. در این حالت TDD Complexity را زیاد کرده و Goal خودش را نقض می‌کند.¹⁵

Goal XP نوشتن Unit Test نیست، همان‌طور که Goal Waterfall نوشتن Specification نیست؛ Goal Working Software است.

برخی میان Test-first Programming (Test قبل از Unit Code) و TDD (Approach گسترده‌تر Design) فرق می‌گذارند، گرچه اصطلاح‌ها سال‌ها Interchangeably استفاده شده‌اند. آیا بدون Test-first می‌شود Design خوب ساخت؟ قطعاً. آیا TDD Tool باارزشی است؟ قطعاً.

¹⁵ Complex Test، Reflection/Mock افراطی، Test سخت‌تغییر و Test Commented-out می‌تواند علامت Complexity باشد.

Kent Beck در پاسخ طعنه‌آمیز به مقالهٔ DHH دربارهٔ «TDD is dead» فهرست کرد که بدون TDD باید برای Problemهایی که TDD حل می‌کرد جایگزین پیدا کند:

• Over-engineering: Red Test → Green کمک می‌کند فقط به اندازهٔ کافی Implement شود.
• API Feedback: Feedback سریع دربارهٔ API Decision.
• Logic Errors: Catchکردن Errorهای منطقی.
• Documentation: نشان‌دادن نحوهٔ Expected Use API و Thought Process.
• Feeling Overwhelmed: حتی وقتی Implementation را نمی‌بینید، معمولاً Step بعدی را با نوشتن Test پیدا می‌کنید.
• Separation of Interface/Implementation Thinking: Design API را از Speculation پیاده‌سازی جدا می‌کند.
• Agreement: با Pair دقیق می‌کند چه Problemی حل می‌شود.
• Anxiety: Button فوری «Is Everything Okay?» می‌دهد.

DHH در مقابل هشدار می‌دهد Test-first افراطی می‌تواند Web پیچیده‌ای از Intermediary Object و Indirection برای Avoidکردن DB/File IO/Browser بسازد و Architecture Monster تولید کند. Critique او نیز با Code Smellهای همین فصل سازگار است: Test Code هم Code است و می‌تواند Smelly شود.

DHH هم در عین حال می‌گوید TDD در شروع «دعوت محترمانه‌ای به دنیای بهتر Testing» بود و Confidence یک Well-tested Codebase را به او نشان داد؛ Training Wheelی برای عمیق‌تر فکرکردن دربارهٔ Test.

نتیجهٔ کتاب: TDD تنها راه نیست، اما Tool بسیار مؤثر XP است. بهترین راه قضاوت این است که واقعاً امتحانش کنید و مراقب Framework Trap در Testها باشید.

کارهایی که همین امروز می‌توانید انجام دهید

• یک Refactoring کوچک در Code فعلی انجام دهید که Structure را Simplify و Behavior را ثابت نگه دارد.
• Code Smellهای WikiWikiWeb را مرور و در Codebase خود پیدا کنید.
• Checkout + Build را بررسی کنید؛ اگر Step دستی زیاد است Build Script بسازید و Process را Automate کنید.
• اگر TDD را هنوز امتحان نکرده‌اید، برای یک User Story فقط یک یا دو Unit Test اول بنویسید و سپس Code لازم برای Passکردن آن‌ها را بسازید.

برای مطالعهٔ بیشتر

• Extreme Programming Explained: Embrace Change, 2nd Edition — Kent Beck with Cynthia Andres، Addison-Wesley، 2004.
• Refactoring: Improving the Design of Existing Code — Martin Fowler, Kent Beck, John Brant, William Opdyke، Addison-Wesley، 1999.
• Peopleware: Productive Projects and Teams, 3rd Edition — Tom DeMarco & Tim Lister، Addison-Wesley، 2013.

شکل‌ها و تصاویر منبع

تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و به‌صورت دادهٔ داخلی Base64 جاسازی شده‌اند.