بایگانی

Posts Tagged ‘Refactor’

تست محصول در 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 کار کنید ,  تغییرات را با آغوش باز پذیرا باشید و چابک بمانید .

یاشیاسیز

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

مارس 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 برچسب‌ها: , ,

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

فوریه 10, 2010 بیان دیدگاه
معمولا در مرحله Bug-fixing یا رفع خطا ها فرصت های مغتنمی برای Refactor کردن کدهای تست نشده به وجود می آید . به عبارت دیگر شما کدهایی دارید که مشکل دار هستند و این فرصت را دارید تا با ساختاری بهتر کدها را بازسازی نمایید .
بعنوان یک قاعده کلی ، به ازای هر کسی که یک مشکل (Problem) را به شما اطلاع می دهد بین 10 تا 100 نفر دیگر وجود دارد که با همین مشکل مواجه شده است ولی به شما اطلاع نداده است .

http://www.uvm.edu/~learnco/ls/test_taking.gif

زمانی که می خواهید به مسائل بالای کیفیت دست پیدا کنید در واقع می خواهید کدهای قدیمی , تست نشده  خود را Refactor نمایید . توجه داشته باشید که Refactor  بر پایه تست های اتوماتیک می باشد و اگر تست نباشد پس Refactor ای در کار نیست . پس شما چگونه می خواهید کدهای تست نشده خود را Refactor نمایید ؟ پس اول نوشتن Test و بعدا Refactor کردن .
منبع کتاب : Debug It
یاشیاسیز
دسته‌ها:Agile, Refactor, TDD, Unit Testing برچسب‌ها:

Refactoring tools in Visual Studio

ژانویه 14, 2010 ۱ دیدگاه
چگونه از ابزاری که به منظور Refactor  در Visual Studio موجود است استفاده نماییم؟
https://i2.wp.com/www.agileprogrammer.com/uploads/bradwils/red_2Dgreen_2Drefactor.png

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‹refactoring›) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

منبع : Refactoring

برای این منظور می توانید از لینک های زیر که حاوی فیلم آموزشی نحوه استفاده از ابزار Refactoring در Visual Studio می باشد ,  مراجعه نمایید :
یاشیاسیز
دسته‌ها:Programming, Refactor برچسب‌ها:

آموزش ۵ اصل برای ایجاد کدهای خوب

ژانویه 14, 2010 3 دیدگاه

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

https://i1.wp.com/2.bp.blogspot.com/_6XzX92QqP8U/Se8zIm-q-0I/AAAAAAAAA2I/laaZF1aZUTk/s320/dirty-code.png

منظور از کد تمیز چیست ؟ کد تمیز رو می شود با کد کثیف (Dirty Code) توضیح داد . به هر اندازه ای که کد خوانایی و قابلیت نگه داریش را از دست بدهد در اصلاح می گویند کد کثیف و یا کثیف تر است و در حالت برعکس هم میگویند کل تمیز یا Clean  می باشد .

اصل سادگی

ما همه روزه شاهد ظهور انواع تکنولوژی ها ,  فریم ورک ها , الگوها ,  ابزار ها و … هستیم که همیشه هم سعی در یادگیری آنها داشته و داریم . ولی مشکلی که تعدد این مسائل به وجود میآورد باعث پیچیده کردن کدها میشود . ببینید بهترین راه حل ساده ترین آن می باشد نه مشکل ترین آن . پس سعی خواهیم کرد که از این بعد همیشه ساده ترین راه و ساده ترین ابزار ها را انتخاب نماییم .

اول کار بکنه , بعدا سریع تر بشه

بهترین همیشه دشمن خوب است

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


از تست اتوماتیک استفاده کنیم

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

بررسی کد

کدهایی که نوشته اید را همیشه مرور نمایید و به شاهکار هایتان یکم بخندید . این کار باعث میشود تا بعدا یک اشتباهاتی که در کدهای قدیمی کردین رو دوباره در کدهای جدید انجام ندهید , همان قضیه عبرت .


Refactor

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

برداشتی آزاد از سایت Macking Good Software

یاشیاسیز

دسته‌ها:Programming برچسب‌ها: ,