بایگانی

Archive for the ‘TDD’ Category

کتاب اسکرام و اکس پی ساده شده

اکتبر 19, 2010 15 دیدگاه

https://i0.wp.com/iragile.com/css/images/scrumBook.gif

کتاب اسکرام و اکس پی ساده شده (چگونه اسکرام را انجام دهیم) نوشته استاد هنریک کنیبرگ می باشد . این کتاب یکی از محبوب ترین و پرطرفداترین کتاب های اسکرام و Agile می باشد به نحوی که اگر واژه Scrum را در گوگل جستجو نمایید این کتاب را در ردیف های اول مشاهده خواهید کرد .

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

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

حوزه هایی که این کتاب پوشش می دهد در مورد آشنایی و پیاده سازی کامل اسکرام می باشد و علاوه بر آن  معرفی و ترکیب روش XP با اسکرام را به طور مفصل بحث  کرده است .

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

علاوه بر این , این کتاب توسط چندین مربی و آمورزگار اسکرام به عنوان مرجع کورس Certified Scrum Master معرفی می شود و می توانید با این کتاب برای ارزیابی کورس مربوطه نیز آماده شوید.

در این کتاب تمام جلسات و اصول اسکرام همراه با مثال هایی عملی آموزش داده شده اند .

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

https://i0.wp.com/iragile.com/css/images/frontcover.gifدر کتاب نحوه مدیریت نوین توسط اسکرام به صورت کامل شرح داده شده است. در مدیریت مشتریان و تیم نقش بسزایی ایفا می کنند که این کتاب توجهی ویژه به  مدیریت نیروی انسانی و مشتریان داشته است .

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

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

امیدوارم توانسته باشیم خدمت کوچکی به جامعه Agile ایران کرده باشم .

در این کتاب چه چیزی هایی خواهید خواند

  • مقدمه و معرفی اسکرام
  • چگونه بک لاگ  محصول را  ایجاد می کنیم
  • چگونه برای برنامه ریزی اسپرینت آماده می شویم
  • چگونه جلسه برنامه ریزی اسپرینت را برگذار می کنیم
  • چگونگی ارتباطات در طول اسپرینت
  • چگونه بک لاگ اسپرینت را انجام می دهیم
  • چگونه اتاق تیم را مرتب می کنیم
  • چگونه جلسه روزانه اسکرام را انجام می دهیم
  • چگونه دموی اسپرینت را ارائه می دهیم
  • چگونه اسپرینت را بازبینی می کنیم
  • چگونگی فاصله دهی مابین اسپرینت ها
  • چگونگی انجام قرار دادهای قیمت بسته و برنامه ریزی Release
  • چگونه XP را با اسکرام ترکیب می کنیم
  • چگونه تست می کنیم
  • چگونه چندین تیم اسکرام را اداره می کنیم
  • چگونه تیم های پراکنده جغرافیایی را اداره می کنیم
  • چک لیست مدیران اسکرام
  • معرفی خواندنیهای مفید

مخاطبین کتاب

  • مدیران شرکت های توسعه نرم افزار
  • مدیران پروژه نرم افزاری
  • مدیران اسکرام (Scrum Mater)
  • توسعه دهندگان نرم افزار

برای تهیه این کتاب می توانید به این لینک مراجعه فرمایید.

یاشیاسیز

Advertisements

دنیای چابک در یک فایل Pdf

ژوئیه 2, 2010 2 دیدگاه

https://sirasad.files.wordpress.com/2010/07/pdf.jpg?w=400یکی از دوستان به نام سعید اسفندی لطف کردند و برای راحتی دوستان دیگر , کل مطالب وبلاگ را (تا به این تاریخ) به صورت فایل PDF در آوردند . در صورت علاقه و تمایل  می توانید از این فایل به طریق لینک زیر استفاده فرمائید.

دانلود فایل Pdf دنیای چابک

از دوست گرامی که زحمت کشیده اند و این فایل را آماده نمودند نهایت تشکر را دارم .

یاشیاسیز

CSM در ایران برای اولین بار

ژوئن 12, 2010 25 دیدگاه

با هماهنگی انجام گرفته با اساتید گرامی و بین المللی Scrum و Agile  از کشور سوئد خواهان برگزاری یک دوره CSM یا Certificated Scrum Master برای اولین بار در ایران و کشور های همجوار هستم . این دوره شامل آموزش کامل متد اسکرام طی 2 روز و اعطای مدرک CSM خواهد بود . امید است که بتوانیم این دوره را به نحو احسنت در ایران برای بار اول برگزار کنیم .البته این دوره در شرایطی برگزار خواهد شد که تعداد شرکت کننده در این دوره به حد نصاب برسد .

CSMhttps://sirasad.files.wordpress.com/2010/06/logo-certified-scrum-master-seal.jpg?w=260 چیست ؟

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

مدرک CSM از طرف تشکل معتبر Agile Alliance به اسکرام مستر های عزیز اعطا خواهد شد و بدلیل معتبر بودن این مدرک در تمام جهان ,  شما به راحتی خواهید توانست در این رشته شغلی در هر کجای این کره خاکی مشغول به کار شوید .

مزیت این دوره چه می تواند باشد  ؟

  • آموزش کامل متد اسکرام طی کلاس ها ,  سمینار ها و کارگاههای عملی
  • رفع اشکال در مورد Agile و اسکرام به همراه اساتید جهانی این حوزه
  • دریافت مدرک بین المللی Scrum Mater
  • امکان اشتغال زایی به عنوان Scrum Master در تیم های توسعه نرم افزار

CSM در کشورهای دیگر چگونه است ؟

این مدرک در اکثر کشورهای پیشرفته جهان توسط تشکل Agile Alliance ارائه می گردد ولی در منطقه کشور ما فقط در کشور ترکیه و کشور هند ارائه می شود . منتهی در هر دو کشور با هزینه گزافی روبرو خواهید شد . برای مثال فقط خود دوره CSM در کشور ترکیه معادل مبلغ 1500 دلار آمریکا هزینه در بر خواهد داشت . این مبلغ را باید بعلاوه هزینه سفر (رفت و برگشت به ترکیه) و بعلاوه هزینه اقامت به مدت چند  روز و بعلاوه هزینه های متفرقه که در چنین کشورهایی خرج می شود باید بکنید .

فرق این دوره با دوره های کشور های همجوار چه خواهد بود ؟

دو فرق اساسی این دوره با دوره های کشورهای خارجی خواهد داشت :

  1. هزینه پایین: به خواهش بنده حقیر و بدلیل اولین برگزاری این دوره در ایران و با مساعدت  Agile Alliance این دوره با هزینه بسیار کم و شاید یک دهم کشورهای دیگر برگزار خواهد شد و تمام در آمدهای حاصله , خرج سفر اساتید گرامی ,  هزینه اقامت آنها  ,  هزینه محل برگزاری دوره و هزینه های متفرقه خواهد شد و به صراحت عرض می کنم بدلیل علاقه بنده به Scrum و تمایل به نهادینه کردن آن در ایران , بنده قصد درآمدزایی از این دوره را ندارم و فقط قصدم برگزاری این دوره در ایران می باشد .
  2. مدرسین : به جرات می توانم عرض نمایم مدرسینی که به امید خدا در خدمت آنها در ایران خواهیم بود ,  جزو اساتید جهانی و معروف حوزه Agile و Scrum  می باشند . ولی در کشورهای همجوار این دوره توسط اساتید بومی آنجا و با سطح بسیار نازل برگزار می شود .

در مورد اساتید دوره :

به احتمال زیاد ما در ایران در این دوره در خدمت دو تن از اساتید سوئدی اسکرام خواهیم بود  که هر دوی آنها کاربلد و در این حوزه از چهره های سرشناس جهانی می باشند . یکی از این برادران دوست عزیز Henrik Kniberg می باشد . این برادر پیشینه عریض و طویلی در زمینه اسکرام و Agile دارد ,  کتاب Scrum and XP from the Trenches او به جرات می توان گفت بهترین و روانترین کتاب در زمینه اسکرام می باشد . برای اطلاعات بیشتر در زمینه وی می توانید به این لینک مراجعه کنید .

هزینه دوره :

همانطور که در بالا عرض شد این دوره به دلیل اولین بار بودن آن با هزینه بسیار کم برگزار خواهد شد (شاید در دفعات بعدی بدین گونه نباشد) . این دوره در کشورهای مختلف با هزینه های مختلفی برگزار می شود : برای مثال این دوره در کشور سوئد با مبلغ 1500 یور برای هر نفر و یا در کشور ترکیه با مبلغ 1500 دلار آمریکا برای هر نفر برگزار می شود : ولی این دوره با حسن نیت دوستان به مبلغ 600-750 دلار کاهش یافت که مبلغ نهایی مابین این رنج خواهد بود .

ظرفیت دوره :

به دلیل اینکه دوره شامل کارگاههای آموزشی هم خواهد بود پس امکان حضور تعداد زیادی از دوستان نخواهد بود . حداکثر 20- 30 نفر قابل پذیرش خواهیم بود . اما اگر تعداد ثبت نام کننده بیش از این تعداد شد و به حد نصاب دو گروه برسد ,  این دوره در دو گروه مجزا برای رفاه حال دوستان برگزار خواهد شد .

محل برگزاری دوره :

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

زمان برگزاری :

زمان برگزاری دوره در اوایل دی یا اوایل بهمن خواهد بود و مدت دوره 2 روز می باشد .

چه کسانی می توانند در این دوره شرکت کنند ؟

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

  • مدیران شرکت های توسعه نرم افزار
  • متخصصان توسعه نرم افزار(برنامه نویس ,  تحلیل گر , آزمایشگر و… )
  • مدیران پروژه

نحوه شرکت در این دوره :

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

پ . ن : از یکی از دوستان عزیز ساکن در تهران که توانایی رزرو مکان برگزاری این دوره را در یکی از هتل های خوب تهران با امکانات لازم برای این دوره را دارا می باشد وتمایل همکاری دارند لطفا با بنده با ایمیل safari_asad[at]yahoo[dot]com مکاتبه نمایند ,  بدیهی می باشد که در هزینه دوره این عزیز تخفیف ویژه ای در نظر خواهیم گرفت .

یاشیاسیز

تست محصول در Agile

مه 28, 2010 5 دیدگاه

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

https://sirasad.files.wordpress.com/2010/05/doctorninja-tm.jpg?w=275بنده به دو دلیل با تئوری بالا مخالف هستم و عقیده دارم باز هم  اگر Tester به تیم توسعه اضافه گردد دوباره برنامه ها پر از باگ خواهند بود : 1- Tester خوب در ایران وجود ندارد و یا خیلی کم است 2-  Tester نمی تواند تمام آزمایش های لازم را انجام بدهد و آزمایشات کامل زمانی می تواند اتفاق بیفتید که برنامه نویس هم تست نماید .

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

تمام مطالبی که در بالا ذکر شد پیش گفتاری برای بحث اصلی مقاله می باشد که نرم افزار و یا محصول در محیط چابک چگونه تست می شود و چه نقش هایی برای این منظور نیاز است .

به طور کلی Agile دید مثبت و خوبی نسبت به تست دارد و کلا این مقوله در ارزش ها و اصول بیانیه توسعه چابک پیش بینی شده است .  اصل 9 بیانیه توسعه چابک اشاره غیر مستقیمی به لزوم تست دارد .TDD روشی می باشد که در متدهای Agile به عنوان روش تست معرفی شده است .

همانطور که در مقالات قبلی در مورد TDD عرض شد در این روش اول تست ها نوشته می شوند و بعدا براساس تست های نوشته شده ,  کدها تولید می شوند . شاید بپرسید که فرق ندارد که تست در اول نوشته شود و یا در آخر ,  بالاخره هدف ایجاد تست برای نرم افزار می باشد و حتی شاید در ایجاد تست در آخر راحتتر و بهتر عمل کنیم ؟

مزیت اصلی نوشتن تست در اول و قبل از کد نویسی این می باشد که ما به اندازه و تمیز کد خواهیم نوشت . فقط هدف از کدنویسی پاس کردن  تست  ها می باشد و به عبارت دیگر می توان گفت که برادر ما می خواهیم رفع تکلیف کنیم با پاس کردن این تست ها ,  کمتر کد بنویس با ضواید کم که فقط این تست ها پاس شود . مزیت دیگر نوشتن تست قبل از کدنویسی ایجاد یک الگو و هدف برای کدنویسی می باشد . یعنی ما دقیقا می دانیم که فقط هدف ما نوشتن این تکه کد برای پاس کردن این تست با این مضمون می باشد و این دوباره باعث Refactoring خواهد شد .ولی اگر تست در آخر نوشته شود کمی تست ها متفاوت خواهند شد : زیرا ما برای کدهایی که ایجاد شده تست می نویسیم و در واقع کدهای نوشته شده فرمانده و الگوی تست نویسی خواهند شد در حالی که شاید کد نوشته شده درست نیست ,  یعنی انتظار مشتری بر آورده نشده است و پس تست این قسمت که دقیقا معلوم نیست انتظار مشتری را بر آورده می کند یا نه چه فایده ای می تواند داشته باشد ؟

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

هدف Agile ارائه ارزش های مورد نیاز تجارت , کسب و کار مشتری طی یک محصول نرم افزاری می باشد . بحث از ارزش گردید , یعنی هدف ما ارائه و فقط ارائه ارزش ها مورد انتظار مشتری می باشد . ارزش مشتری همان User Story هایی می باشد که آن ها را در اول و یا طی  پروژه جمع آوری می نماییم . مثلا  : » کاربران سیستم باید در هنگام ثبت نام از رمز عبور امن (Secure) استفاده نمایند» : این می تواند یک ارزش یا User Story برای مشتری باشد ; ولی در تعریف Agile گفتیم که : » هدف ما ارائه و فقط ارائه ارزش ها مورد انتظار مشتری می باشد » . ما ارزش را به صورت یک User Story بیان کردیم ولی انتظار مشتری را از این ارزش بیان نکردیم . به عبارت ساده تر این ارزش چه ویژگی هایی باید داشته باشد تا نیاز مشتری برآورده شود؟

برای وضوح بیشتر به این مثال توجه نمایید : فرض کنید ما یک مشتری داریم که او می خواهد یک کارخانه اتومبیل سازی راه بیندازد و ما هم راه انداز کارخانه هستیم . در فاز تحلیل و یا در راه اندازی کارخانه در می یابیم که  برای کارخانه نیاز به لیفت تراک می باشد .  این یک ارزش برای کارخانه می تواند باشد . اما مشتری اذعان دارد که این لیفت تراک باید بتواند در یک نقطه 360 درجه بچرخد و باید بتواند بارهای بالای 20 تن را بردارد . این ها هم ویژگی های این ارزش می توانند می باشند . زمان تحویل لیفت تراک ما باید تست بکنیم ببینیم که آیا این لیفت تراک می تواند این باید ها را پاس کند ؟ به این حالت اصطلاحا  Acceptance Test می گویند .

پیاده سازی یک ارزش در محیط چابک می تواند به صورت زیر می باشد :

  • ارزش یا User Story شناسایی می شود و مستند می شود.
  • ویژگی های ارزش شناسایی و مستند سازی می شود.
  • هر کدام از ویژگی های یک ارزش به صورت تست هایی پیاده سازی می شوند.
  • ارزش بر اساس الگوی تست موجود کد نویسی می شود .

همانطور که مستحضر می باشید گام های بالا همان گام های TDD می باشند ولی این گام های وظیفه چه کسی می باشد ؟

  • گام اول – ارزش یا User Story شناسایی می شود و مستند می شود : وظیفه کل تیم توسعه می باشد .
  • گام دوم – ویژگی های ارزش شناسایی و مستند سازی می شود : وظیفه Tester های تیم و توسعه دهندگان می باشد .
  • گام سوم و چهارم-  وظیفه برنامه نویسان عزیز می باشد .

داشتن تست برای هر ویژگی بسیار سودمند و با ارزش می باشد که در محیط چابک اگر تست نباشد کار تقریبا امکان پذیر نخواهد بود . یکی از ارزشها و شعارهای اصلی توسعه چابک «قبول و پذیرایی از تغییرات» است . بنده به صراحت عرض می کنم که اگر تست نداشته باشید این شعار قابل انجام نخواهد بود . بدلیل اینکه هر تغییر ویرانی هایی را بدنبال خواهد داشت . اگر تا به حال برنامه نوشته باشید و محصول توسعه داده باشید باید به خاطر بیاورید که در هر تغییر (جزئی و یا کلی) قسمت هایی از برنامه درست و قسمت هایی از برنامه ویران شده است . اگر تست داشته باشیم ,  در هر تغییر می توانیم بعد از اعمال تغییرات تمام تست ها را اجرا نماییم ,  اگر کدی در یک جایی ویران شده باشد ,  تست آن قسمت پاس نخواهد شد و قرمز رنگ خواهد شد ,  پس می توان به راحتی از ویران کردن دیگر بخش ها مطلع شد و تصحیحات لازم را به موقع و قبل از ارائه آن به مشتری انجام داد .

چابک شوید  , TDD کار کنید ,  تغییرات را با آغوش باز پذیرا باشید و چابک بمانید .

یاشیاسیز

آیا TDD در عمل امکان پذیر می باشد؟

آوریل 8, 2010 2 دیدگاه

آیا TDD در عمل امکان پذیر می باشد ؟ این سوالی بود که یکی از عزیزان از بنده پرسیده بود . ایشون فرموده بودند : «شما که می گید اول تست بنویسیم و بعد کد نویسی , مگر چنین چیزی ممکن است ؟ مگر برای کد نانوشته می شود تست نوشت؟ » و ایشون TDD را به یک افسانه تشبیه کرده بودند . من همین سوال را از شما می پرسم , آیا در عمل و یا اصطلاحا در Real World امکان دارد که TDD عملی شود ؟

در مقاله قبلی گفته شد که : TDD عبارتست از ترکیب TFD یا همان Test First Design و Refactor . به عبارت ساده تر یعنی ما اول قبل از اینکه شروع به کدنویسی بکنیم اول تست ها رو طراحی می کنیم و بعد کد نویسی می کنیم و بعد رفاکتور می کنیم . ادامه …

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

به نظر من راز موفقیت در User Story های خوب و کامل می باشد . اگر مقاله بنده در مورد اسکرام با عنوان اسکرام ساده شده را مطالعه فرموده باشید حتما بیاد خواهید آورد که بنده در آنجا گفته ام که هر Story ایه   Product Backlog که می خواهد وارد  Sprint Backlog بشود برای آن Story یک Index Card درست می نماییم همانند شکل زیر :

تجربه نشان داده است که باید تمام حالت های این Task را در پشت این Index Card  یادداشت کرد که در واقع راهنمای TDD ما خواهد بود . در همان جلسه Sprint Planning  باید تمام حالات ممکن یک Task معلوم و پشت Index Card  و یا در برنامه های Issue Tracker مانند Jira ثبت شود . یعنی اگر ما یک فهم خوب از یک Story داشته باشیم و تمام حالاتی که ممکن است اتفاق بیفتد را بدانیم به راحتی می توانیم TDD را پیاده سازی نماییم . پس باید قبل از پیاده سازی یک Task کامل آن مورد بحث قرار بدهیم و تمام حالات را دربیاوریم و بنابه حالات ممکن تست طراحی نماییم و بعد پیاده سازی نماییم . به یک مثال در همین باب توجه نمایید :

فرض کنید ما در حال پیاده سازی یک وب سایت می باشیم . Task جاری ما پیاده سازی یک اعتبارسنج رمز عبور (Password Validation) می باشد . Story ما به شرح زیر است :

کاربران سیستم باید در هنگام ثبت نام از رمز عبور امن (Secure) استفاده نمایند . بدین صورت که حداقل طول رمز عبور باید 6 کاراکتر و در رمز عبور باید حداقل از یک حرف ,  یک عدد و یک علامت استفاده شده باشد .

ما برای وضوح بیشتر این Task یک سری  Test Case آماده می کنیم  و مشتری و یا Product Owner اعلام می کند که اینها معتبر  می باشند : p@ssw0rd, @@@000dd, p@ss w0rd و اینها نامعتبر می باشند :   p@ss3, passw0rd, p@ssword, @@@000 .

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

خوب خیلی ساده شد . ما هم اکنون می دانیم چند تا تابع باید بنویسیم . تابع های ما یک رشته را به عنون آرگومان قبول می کنند و یک مقدار Boolean را به عنوان خروجی تابع باز می گردانند . تست نوشتن برای این توابع که اصلا مشکل نیست  . لیست توابع تست که  نیاز داریم به شکل زیر می باشد :

test_valid_returns_true_when_all_conventions_met
test_valid_returns_false_when_password_less_than_6_chars
test_valid_returns_false_when_password_missing_symbol
test_valid_returns_false_when_password_missing_letter
test_valid_returns_false_when_password_missing_number

مثلا اگر بخواهیم تابع تست test_valid_returns_false_when_password_less_than_6_chars را پیاده ساز ی بکنیم ,  به شکل پایین در میآید : (نمونه کد در زبان #C نوشته شده است)

[Test]
public void test_valid_returns_false_when_password_less_than_6_chars()
{

//1
CsPasswordValidator  iValidator=new CsPasswordValidator();

//2
bool result=iValidator.Is6CharPassword(«SirAsad«);

//3
Assertion.AssertEquals(true, result);
}

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

یاشیاسیز

دسته‌ها:Agile, TDD, Unit Testing برچسب‌ها: , , ,

کد تمیز بهتر از کد کثیف

مارس 23, 2010 8 دیدگاه

قبلا پستی در مورد نحوه نوشتن کدهای تمیز داشته ام ولی هرچه قدر ما به صورت یک پست خلاصه بنویسیم ثواب یک کتاب جامعه در این مورد را نخواهد داد . بدلیل اهمیت این قضیه بر این شدم که کتاب خوبی در این مورد معرفی نمایم . برادر گرامی Robert Martin کتاب بسیار جالبی با عنوان Clean Code: A Handbook of Agile Software Craftsmanship دارد که خواندن آن خالی از لطف نمی باشد .

https://sirasad.files.wordpress.com/2010/03/41pjvb0x-yl-_bo2_pisitb-sticker-arrow-click.jpg?w=413

در این کتاب خواهید خواند :

  • چگونه کد خوب را از کد بد بشناسیم
  • چگونه کدهای خوب بنویسسیم و چگونه کدهای بد را به خوب تبدیل کنیم
  • چگونگی نام گذاری خوب ,  متدهای خوب ,  اشیای خوب و کلاس های خوب
  • قالب بندی کدها برای خوانایی حداکثری
  • چگونگی هندل کردن error ها بدون مبهم کردن منطق کدها
  • مبحث مهم تر : آموزش چگونگی استفاده از Unit Test و TDD

مشاهده کتاب

یاشیاسیز

توسعه آزمایش محور

مارس 1, 2010 9 دیدگاه

یه خواننده هست به اسم شماع زاده (نمی دونم مجازه غیر مجازه – اگر نیست عفو بفرمایید) همان که میگه گیتارم را نبرید {تورو خدا سیب و گلابی و طلاها رو ببرید ولی این گیتارم رو نبرید } واقعا این برادر باید برای برنامه نویس ها یک الگو باشد .

https://i1.wp.com/proactive-dev.inria.fr/img/bug.jpgبرنامه نویس ها باید بگویند که هر چی دلت می خواهد ببر , IDE را ببر , کامپوننت Janus را ببر , Delphi رو کلا ببر , PHP ام دم در بنداز تو Trash ولی تو رو خدا TDD ام را نبر .

در این سال های اخیر در صنعت توسعه نرم افزار چه برای Desktop و چه برای Web شاهد بروز تکنولوژی ها و تکنیک های زیادی بودیم . از مهمترین آنها می توان به TDD یا Test Driven Development [من توسعه آزمایش نخست می نامم] و Refactor اشاره کرد .

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

TDD چیست ؟ TDD عبارتست از ترکیب TFD یا همان Test First Design و Refactor . یعنی چه ؟ یعنی ما اول قبل از اینکه شروع به کدنویسی بکنیم اول تست ها رو طراحی می کنیم و بعد کد نویسی می کنیم و بعد رفاکتور می کنیم .

قبل از اینکه بریم تو بحر TDD اجازه بدید Refactor رو یه شرح کوچولو بدم :

Reafactor عبارتست از پروسه بهبود طراحی کدهای موجود بدون اینکه رفتار کدها تغییر بکند . مثلا کلاس بندی کد ها و یا خوانا کردن کد ها و کلا هر کاری که مربوط به طراحی کدها باشد . برای اطلاعات بیشتر به این لینک مراجعه نمایید .

https://i0.wp.com/upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG

TDD شامل 5 مرحله می باشد :
1- اول یک تست نوشته می شود .

2- تست نوشته شده آزمایش می شود و چون کدی برای این تست نوشته نشده اشت پش نتیجه تست Fail است .

3- به اندازه کافی و تاکید می کنم فقط به اندازه کافی کد می نویسیم که فقط این تست را Pass بکنیم .

4- تست نوشته شده در مرحله اول آزمایش می گردد اگر پاس شود حرکت به مرحله بعدی و اگر نشود برگشت به مرحله قبلی و نوشتن اندکی دیگر کد.

5- Refactor .

به روش TDD اصلاحا Red – Green هم گفته می شود . زمانی که تست را می نویسید چونکه Fail می شود این حالت را Red  می گویند (رنگ قرمز نشانه Fail شدن تست می باشد)و زمانی که تست پاس می شود این حالت را Green  (رنگ سبز نشانه Pass شدن تست می باشد) می گویند . اگر در جایی این اصلاح را دیدید تعجب نکنید ,  همان TDD است .

شاید در اول یکم نامفهوم به نظر برسد ولی روش بسیار کارآمدی می باشد . این روش به نظر من چند ویژگی منحصر به فرد دارد :

1- ما ایرانیان که اصلا تست نمی نویسیم نه در اول و نه در آخر . شاید این بهانه ای باشد که ما هم برای برنامه هامان تست بنویسیم .

2- شما چونکه در اول تست ها را نوشتید پس صاحب یک Automate Test جانانه هستید .

3- چون شما صاحب Automate Test جانانه هستید پس تغییرات و Refactor را می توانید به راحتی انجام دهید . در مطلب چگونه کدهای تست نشده را رفاکتور نماییم؟ به این مسئله اشاره کردم .

4- به اندازه کد می نویسید و نه بیشتر .

5- نوشتن تست در آخر سخت می باشد . و اگر هم سخت نباشد نوشتن تست در آخر به درد لای جرز می خورد .

6- هزینه باگ زدایی پایین می آید ( این مورد را به صورت مفصل در پستی در آینده بیان خواهم کرد)

ابزارک هایی جهت TDD کار ها در جهان هایی متفاوت :

Java -> Junit

.Net -> NUnit

C++-> gunit

Python -> pyUnit

Runy -> Test::Unit

در نوشتن تست ها به موارد زیر دقت فرمایید :

قبل از اینکه بخواهید تست بنویسید , دقت کنید که بدانید چه کاری می خواهید انجام دهید . یکی از نیازمندی های سیستم را انتخاب نمایید . نیازمندی را پالایش کنید و وابستگی ها و جزئیات نیازمندی را دربیارید . باید تست شما تمام جزئیات نیازمندی را پوشش بدهد .

به مثال خردی توجه فرمایید :

فرض کنید ما می خواهیم کلاسی با عنوان کتاب  داشته باشیم که در این کلاس ما متدی برای مقایسه کتاب ها نیاز داریم ,  تست این کلاس می تواند بدین صورت باشد :

[TestFixture]
public class BookFixture
{
    [Test]
    public void BooksWithSameTitleReturnZeroCompareToValue()
    {
        Book same1 = new Book("A");
        Book same2 = new Book("A");

        Assert.AreEqual(0, same1.CompareTo(same2));
    }
}


Example by : One Agile Coder

خوب این تست نوشته شد ولی چون کلاسی به اسم Book نداریم پس عملا تست Fail می باشد .

پس ما نیاز مند این هستیم که کلاس Book را با مخللفات لازم ایجاد نماییم .


public class Book : IComparable
{
    private readonly string title;

    public Book(string title)
    {
        this.title = title;
    }

    public string Title
    {
        get { return title; }
    }

    public int CompareTo(Book other)
    {
        return title.CompareTo(other.title);
    }
}

اگر تست را توسط Unit Test آزمایش کنید  چراغ قرمز ما تبدیل به چراغ سبز می شود . و اینگونه می شود که تستی Pass می شود .
یاشیاسیز
دسته‌ها:Agile, Refactor, TDD برچسب‌ها: , ,