مقدمه ای بر Agile Technical Practices

تو پست قبلی به طور کلی از مفهوم Software Craftsmanship نوشتم از اینکه چطور با جامعشون تو لندن و بعدش کل دنیا آشنا شدم و راجع به دوره ۴ ماه ای که شرکتم برگزار کرد نوشتم . تو این پست میخوام راجع به جزییات فنی اون دوره بنویسم.

عنوان هفته اول بود Classic TDD که منظور از TDD همون Test Driven Dvelopment یا به فارسی برنامه نویسی تست محور هست . تمرکز هر هفته رو انجام یه سری تمرین های خاص بود برای درونی کردن یکسری عادات خاص و رسیدن به چند هدف گاهی نه چندان ساده در انتهای هفته. هدف هایی که برای هفته اول گذاشته شده بود اینا بودن :

  1. فهمیدن مفهوم Extreme Programming، ارزشهاش، قواعدش و Best Practice هاش .
  2. توانایی پیاده سازی یک الگوریتم ساده با روش TDD
  3. توانایی پیاده سازی یک برنامه ساده برپایه اصول OO
  4. فهمیدن و درونی شدن قواعد Code Smells

روز اول :‌

قسمتی از روز اول به تنظیمات لپتاپ هامون و آشنایی با بقیه گروه گذشت بعدش با مقدمه ای راجع به XP یا همون Extreme Programming و Classic TDD ادامه پیدا کرد. نمیدونم چقدر راجع به Agile و روش Agile برای توسعه نرم افزار میدونید ولی با یه سرچ ساده میتونید کلی اطلاعات فارسی و انگلیسی راجع بهش بدست بیارید. روش Aglile شامل دوبخش میشه:

  • قسمت اول سازمانی و غیر فنیه که همون اصول Scrum و Kanban هستن.
  • قسمت دوم هم سازمانی اما مربوط به اصول فنی Aglie میشه که این بخش Extreme Programming نام داره.

اما سوال اصلی اینجاست که چرا ما به اصول Agile نیاز داریم ؟

گاهی کمبود دانش فنی و گاهی کمبود آگاهی از بیزینس باعث ورود بدهی های فنی و بیزینسی به کد میشود اما زمانی که شواهد این بدهی ها به وضوح قابل دیدن باشه برای حل این بدهی ها دیگه خیلی دیر شده و گاهی بسیار هزینه بر هست. با به کار گیری مجموعه ای از تکنیک ها به طور پیوسته میتونیم میزان بدهی های فنی و بیزینسی رو کم کنیم و از انباشته شدنشون جلوگیری کنیم. نکته کلیدی اینه که به محض اینکه تیم حس کرد بدهی فنی یا بیزینسی ای وارد پروژه شد در همون نقطه باهاش روبرو بشه و حلش کنه. این موضوع با به کارگیری اصول FeedBack و Design قابل اجراست.

FeedBack Practices : ◦ Pair Programming ◦ TDD

DesignPractices: ◦ Refactoring ◦ Simple Design

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

مهمترین نکته ای که در مورد توسعه نرم افزار با اصول Extereme Programming وجود داره اینه که XP چند تا پایه اساسی داره که شامل سادگی، ارتباط موثر، FeedBack، شجاعت و احترام میشن.

و اما یکی از مهارت هایی که توی این دوره خیلی خوب یاد گرفتم و قبلش به شدت برام سخت بود این کار Pair Programming بود که البته باز هم قسمتی از Extreme Programming و زیر مجموعه FeedBack هست. همه برنامه نویس ها میدونن که Pair Programming چقدر کار سخت و طاقت فرسایی هست این روش و البته اگر درست و اصولی انجام نشه میتونه منجر به فاجعه بشه. برای من یکی از سخترین کارهای دنیا همین Pair Programming بود در حالی که الان به یکی از لذت بخش ترین قسمت های روز کاریم تبدیل شده.

برای Pair Programming چند مرحله ساده وجود داره:

  1. دوتایی باهم صورت مساله یا همون تسکمون رو بخونیم .
  2. سعی کنیم با بیان خودمون تسک رو برای هم توضیح بدیم و راجع به تسک با هم Brainstorm انجام بدیم.
  3. ایده هامون برای پیاده سازی راه حل مساله رو برای هم واضح توضیح بدیم و روشن کنیم.
  4. وقتی که هم تیمیمون در جایی از حل مساله یا پیاده سازی گیر میکنه سعی کنیم ابتکار عمل رو دست بگیریم که اینجوری باعث فرسایش و خستگی کمتری میشه.
  5. نسبت به هم گروهیمون مسئول و جواب سوالات و ابهامات احتمالیش رو بدیم.

دو نقش در PairProgramming وجود داره که نقش اول Driver هست و نقش دوم Navigator .

وظایف Driver :

  • تایپ کردن و حرکت دادن موس .
  • در حین پیاده سازی کد راجع به جزئیات حل مساله و روش پیاده سازیش توضیح بده .

وظایف Navigator :

  • نقد کار Driver در واقع منظور از نقد کار اینجا اینه که حواسش به اشتباهات ممکن در هنگام نوشتن کد باشه و همزمان حواسش به جنبه های دیزاین، معماری، پرهیز از تکرار و وابستگی کد در حال توسعه با بقیه قسمت های سیستم باشه.
  • باید به این مسائله توجه کنه که سایر تسک های سیستم رو، برای پرهیز از شاخه ای به شاخه دیگه پریدن و تمرکز بر تسک فعلی، تا اتمام تسک فعلی کنار بگذاره .

زمانی که Navigator راه رو گم میکنه در واقع احساس میکنه که تمرکزش رو از دست داده باید جاش رو با Driver عوض کنه.

برای عوض کردن جای Driver و Navigator یه سری تکنیک وجود داره:‌ Chess clock: نقش ها بعد از یک زمان از پیش تعیین جابجا میشود. (Ping pong (Popcorn: توسعه دهنده A یک تست قرمز بنویسد (Fail) شده بنویسد و توسعه دهنده دهنده B پیاده سازی لازم برای سبز شدن(Pass) تست مربوطه را انجام دهند. برای تست بعدی برعکس عمل میشود.Pomodoro: تایمر با زمان مشخصِ چند دقیقه ای گذاشته شود، بعد از هر بار تمام شدن تایمر و یک استراحت کوتاهِ چند دقیقه نقش ها عوض شود. بعد از هر ۴ Pomodoro یک استراحت طولانی انجام شود.

بریم سراغ مهارت دومِ قسمت FeedBack که (Test-driven development(TDD یا همون برنامه نویسی تست محوره. TDD تا اونجایی که من میدونم دو مکتب اصلی داره که اولیش مکتب کلاسیک هست که به Chicago/Detroit School of TDD معروفه و توسط Kent Beck ( نویسنده کتاب Test-driven Development: By Example که پیشنهاد میکنم این کتاب رو بخونید حتما) معرفی شده البته این مکتب به Inside-out هم معروفه، مکتب بعدی Outside-In TDD/ London School of TDD هست. که بین این دو مکتب یک وجه اشتراک وجود داره اونم سه قانون اصلی TDD هست :‌

قانون RED-GREEN-REFACTOR به زبان دیگه داره میگه که شما حق ندارید هیچ پروداکشن کدی بنویسید مگر برای سبز شدن تست های قرمز (Pass Failing Test). با تست های ساده و کوچک شروع کنید (به این نکته توجه کنید که خطای کامپایلر هم نوعی تست قرمز است) فقط به اندازه ی سبز شدن تست قرمز شده پروداکشن کد بنویسید و در آخر در مرحله ریفکتور فقط زمانی که برای سومین بار یک تکه کد تکراری دیده شود باید اقدام به بیرون کشیدنش بکنید(وسواس بیش از حد در ریفکتور باعث کم شدن بازده کاری خواهد شد).

وقتی که تازه شروع به کد نوشتن با روش TDD میکنید درونی کردن و تبدیل به عادت شدن این روش یه کم ممکنه سخت باشه، البته برای من اینجوری بود. برای همین یه سری روش ها میان به کمک تا این روش رو تبدیل به یه عادت کنن. اولین روش Baby Steps خلاصه این روش اینه که:

  • یک Kata انتخاب کنید و یک ریپوزیتوری گیت براش درست کنید.
  • تایمرتون رو برای ۲ یا ۳ دقیقه تنظیم کنید.
  • شروع کنید اولین تست رو تو این زمان بنویسید اگه تا زمانی که تایمر زنگ زد یک تست قرمز کامل داشتید، میتونید تایمر رو ریست کنید و در ۳ دقیقه بعدی سعی کنید تست قرمز رو سبز کنید.کامیت بعد از هر بار ریست شدن تایمر در این مرحله ضروریه. اما اگر ۳ دقیقه تمام شد ولی شما موفق به نوشتن کامل یک تست قرمز نشدید باید تایمر رو ریست کنید و تمام تست های نوشته شده ناقص رو هم ریورت کنید به آخرین کامیت و در ۳ دقیقه بعدی سعی به نوشتن دوباره تست به صورت ساده تر طوری که در ۳ دقیقه تمام شود بکنید.

این تمرین رو میتونید دو نفری انجام بدید ینی بعد از هربار ریست شدن تایمر نوبت نفر بعدیه. اینجوری همزمان هم Pair Programming و هم TDD رو دارید تمرین میکنید. این نکته رو فراموش نکنید که میتونید تا زمانی که به پیاده سازی اصلی نیاز ندارید از Fake implementation استفاده کنید. که اصولا بعد از نوشتن تست دوم یا سوم به پیاده سازی واقعی نیاز پیدا میکنید. این روش به کارتون سرعت میده. اینم اسم چندتا Kata ساده که میتونید ازشون برای تمرین استفاده کنید:

Fizz Buzz kata, Leap year kata, Nth Fibonacci

ادامه دارد...