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

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

• یکپارچه سازی مداوم و تحویل مداوم لازم و ملزوم:)

بدلیل اینکه پروژه از ساختار و لایه های مختلفی تشکیل شده بود و لایه ها به صورت مستقل Build می شدند، و بخصوص اینکه یک فریم ورک هم داشتیم که خود آن کاملا مستفل بود، یکپارچه سازی مداوم یا Continuous Integration  امری بسیار ضروری بود. این کار در TFS اتفاق می افتاد و با در خواست تسترها یا مالک محصول یک Build  شروع می شد و در نهایت یک فایل قابل نصب از پروژه تحویل داده می شد.

یعنی خیلی ساده، در هر لحظه که اراده می شد، آخرین نسخه ای که برنامه نویس ها به Repository ارسال کرده بودند؛ در دسترس بود.

1- تست سریع و منتظر نشدن تا آخر اسپرینت توسط تستر ها و مالک محصول بزرگترین مزیت این روش بود.

2- خودکارسازی اجرای تست یونیت تست ها و Acceptance تست ها، باعث افزیش سرعت پیدا کردن باگ ها می شد.

درسی که یاد گرفتیم،

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

• محیط تولید، تست و پروداکشن از هم جدا باید باشند

این باگ در پروداکشن هست ولی روی سیستم من کار می کنه؟ دیالوگ معروفی که بعد از گزارش باگ از برنامه نویس ها می شنیدیم. محیطی که تسترها در آن تست می کنند باید بسیار نزدیک به محیط واقعی باشد که مشتری ها در حال کار هستند. از نظر سیستم عامل، سخت افزار سرور، culture، تنظیمات و پیکربندی سیستم عامل، دیتاهای موجود و … .

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

برای همین مورد یک سرور واسط مابین پروداکشن و محیط تولید قرار گرفت به نام : Pre-production. وقتی نسخه ای توسط TFS بیلد می شد به صورت خودکار یا توسط تسترها، روی محیط  پری-پروداکشن Deploy می شد(فقط با یک کلیک). بعد تسترها موظف بودند، تک تک شرایط پذیرش آیتم done شده را روی محیط پری-پروداکشن تست کنند و اگر موفقیت آمیز بود به مالک محصول اطلاع دهند تا او هم همین کار را انجام بدهد.

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

• تست های اتوماتیک خوب است ولی نیاز به بلوغ دارد

حقیقتا کسی نمی تواند بر خلاف خوبی تست های اتوماتیک حرفی بزند اما مشکلی که هست نوشتن این تست ها در اوایل کار همانند یک تئوری است که قابل انجام نیست. مشکلی که برای نوشتن تست های اتوماتیک وجود دارد این است که:

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

درسی که یاد گرفتیم،

1-در نوشتن یونیت تست در اوایل پروژه افراط نکنید، سعی کنید تنها برای جاهایی بنویسید که محاسباتی قرار است انجام شود، مثلا تبدیل زمان یا محاسبه استهلاک اموال.
2- بهتر است برای کارهایی با دیتابیس سرکار دارند، از Acceptance Test استفاده کنید
3- در نوشتن Acceptance Test نیز افراط نکنید، سعی کنید از مهمترین بخش سیستم شروع کنید، بخشی که اگر باگی در آن ایجاد شود کلا زیر سوال می روید، برای مثال در Simplydesk ما ابتدا از قسمت ثبت تیکت شروع کردیم که حیاتی ترین بخش سیستم بود
3- باگ ها بهترین زمان برای نوشتن تست هستند، یکی از قوانین تیم این بود که باگی رفع نمی شود مگر اینکه تست آن قرمز و سپس سبز شود
4- ابزار SpecFlow یکی از بهترین ابزارها برای نوشتن Acceptance Test است
5- در نوشتن سناریوهای Acceptance Test سعی کنید خوانایی را شرط اول قرار دهید و از مفاهیم کسب و کار به جای مفاهیم  فنی استفاده کنید

اگر فرصتی شد حتما در این مورد به صورت مفصل خواهم نوشت.

• نوشتن فریم ورک اختصاصی خوب یا بد؟

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

خیلی کار ندارم که این ذهنیت چقدر درست یا غلط است،

درسی که یاد گرفتیم،

1- اگر قرار است چندین ماه اول پروژه فقط صرف تولید فریم ورک کنید و بعدا پروژه اصلی شروع شود، احتمالا و شاید لازم باشد که در نحوه انجام کار بازنگری کنید.

2- معمولا فریم ورکی که شما برای یک پروژه تولید می کنید، به احتمال زیاد نه قابل فروش است نه قابل استفاده در پروژه های دیگر. پس لطفا و خواهشا از Generalize کردن بیش از حد فریم ورک خودداری کنید.

3- تولید فریم ورک همزمان با تولید پروژه اصلی ایده بدی نیست، منتهی، یک- برنامه نویس ها عادت دارند بر اساس پروژه های قبلی و تجربیات گذشته فریم ورک را تولید کنند و نه بر اساس نیاز واقعی پروژه جاری. دو- بهتراست از بردن همه چیزبه فریم ورک خودداری کنید، سه – تا جایی که امکان دارد بگذارید قابلیت های فریم ورک را مشتری های(برنامه نویس ها) بگویند .

• رفکتور و Code Review

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

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

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

درسی که یاد گرفتیم:

1- چیزی به عنوان بهترین طراحی یا معماری وجود ندارد، در ابتدای کار هر چقدر سعی کنیم بهترین ها را در بیاوریم بیشتر رویاپردازی خواهد بود، زیرا به صورت ناخواسته ما نسبت به تجربیات و چیزهایی که بلد هستیم متمایلیم و سعی می کنیم همان ها را در اینجا تکرار کنیم، مثلا کسی در پروژه قبلی از Web API استفاده کرده و خوب بوده، بدون در نظر گرفتن شرایط فعلی این پروژه از همان طرح استفاده کند.

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

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

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

چابک و موفق باشید

اسد صفری