بررسی agile بصورت جزئی تر (قسمت چهارم)

طبق پست های پیشین در مورد بررسی agile بصورت جزئی تر در ادامه به برنامه نویسی گروهی و نحوه ی تست برنامه می پردازیم .

برنامه نویسی گروهی
همانطور که گفته شد هیچ کسی در تیم مالکیت انحصاری کد نوشته شده ی خود را ندارد و هر کسی از تیم می تواند آن را برای بهتر شدن ویرایش کند . در برنامه نویسی گروهی می توان هر کسی یک قسمت از کدنویسی را به عهده بگیرد و با نرم افزارهای مدیریت نرم افزار مانند SVN و Git با هم روی سورس کار کنند ، یا دو نفر با یک کامپیوتر کار کنند . هر کدام از این دو نفر می توانند کیبورد را در اختیار بگیرد و کد نویسی کند و دیگری همراه با اون فکر کند که چه راهی بهتر است و کدام متود سریعتر و بهتر جواب می دهد ، هرگز فکر نکنید این روش وقت تلف کردن است یا دو نفر موازی یک کار انجام می دهند ، بلکه کیفیت و سرعت کد نویسی همچنین درصد خطا بسیار پایین می آیند ، در این روش 1+1>2 می باشد . باید توجه داشت که بهتر است بطور مداوم جای کدنویس (راننده) با نفر دیگر عوض شود .
کمک برنامه نویس وظیفه دارد هر خطی که نوشته می شود را در ذهنش چک کند که درست باشد و در مسیر متودهای گذشته باشد . هر دو نفر می بایست اخلاق دسته جمعی و کار گروهی را رعایت کنند ، جنسیت دو برنامه نویس نباید خللی در کار وارد کند و تیم به حاشیه برود ، هر دو برنامه نویس باید سخت کوش باشند و مسئولیت و وظیفه محول شده را از خودشان بدانند .
به هیچ وجه جَو سرزنش برای وجود باگ در تیم ایجاد نکنید ، تا هر کسی که شک در برنامه ای که نوشته بود پیدا کرد آن را به راحتی بیان کند نه این که اصطلاحا آن را به زیر قالی بفرستد .
اگر شک در برنامه ایجاد شده احتیاج به زمان زیادی برای اصلاح داشت Itration تمام شده و آدرس و محل مشکل را برای مرحله ی بعد یادداشت می کنیم . (به هیچ وجه وجود مشکل در کد نباید باعث به تعویق افتادن اتمام مرحله شود)

تست برنامه
تست کد نوشته شده می بایست همزمان با کدنویسی انجام شود
تست صفر و یک می باشد یا 100% درست می باشد که به مرحله بعد می رویم یا مردود می شود که تا درست نشده نباید به سراغ کد دیگر رفت
در برنامه نویسی چابک ابتدا مشخص می شود که قرار است چه چیزی تست شود و با چه کیفیتی می بایست نتیجه دهد سپس برنامه نویسی بر اساس این اصطلاحا Test case ها صورت میگیرد . این موارد تست از روی user stories هایی که در ابتدای شروع مرحله نوشته بودیم نوشته می شود .
با استفاده از این روش سرعت کار فوق العاده بالا می رود چون از شروع کار برنامه نویس کاملا می داند چه چیزی قرار است در نهایت تست شود و برنامه را بر آن اساس می نویسد و از دوباره کاری و نوشتن برنامه های بی مصرف جلوگیری می شود .
اگر Test Case خوبی نوشته نشود وظیفه ی برنامه نویس پیچیده می شود و نباید انتظار برنامه خوبی از او در پایان داشت .
بعد از هر اصلاح می بایست کل سیستم تست شود نه فقط آن قسمت ، چون ممکن است در حین اصلاح بعضی توابع درست کار نکنند و تغییراتی در آنها ایجاد شود .

1) راه اندازی اولیه و ریختن طرح اینکه چه دیتای ورودی ای می خواهیم به برنامه بدهیم .
2) راه تست کردن و روش تست برنامه چیست
3) چه اطلاعات خروجی مورد انتظار است و چه اطلاعاتی نیاز است
خروجی دریافتی نباید شبیه و نزدیک به اطلاعات مورد نیاز و مورد انتظار باشد ، می بایست دقیقا چیزی باشد که در User stories ها مشخص کردیم .
در صورتی که یک تست چندین بار می بایست انجام شود ، بهتر است یک اسکریپت مخصوص اجرای عملیات تست و مهیا کردن ورودی ها بنویسیم به نحوی که در نهایت با فشردن یک کلید بطور اتوماتیک تست انجام شود . بهتر است بصورت شفاف نتایج خطا یا درستی را نشان دهد ، هیچ پردازش اطلاعات دوباره ای رو نتایج نباید انجام شود ، و برنامه نویس بلافاصله می بایست بفهمد اشکال از کجاست : 1) کد 2)شرایط ورودی 3)نتایج خواسته شده 4)نوع تست
کد باید قابل تقسیم باشد طوری که هر باز که چیزی تغییر کرد لازم نباشد همه ی سیستم اجرا شود و فقط بخش مربوطه دائما تست شود ، و در نهایت بعد از دریافت نتایج دلخواه همه ی سیستم یکبار تست شود .


2 پاسخ به “بررسی agile بصورت جزئی تر (قسمت چهارم)”

  1. مشکل علامت سوال وردپرس گفت:

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

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *