توسعه Test-Driven و چرخه مشاهده آن
مباحثههای جالبی بین توسعهدهندگان در مورد ماهیت Test-driven Development یا TDD و استفاده از آن وجود دارد. در TDD یا «توسعه آزمونمحور» اول آزمون (تست کد) و سپس کد نوشته می شود.
توسعهدهندگان در این مباحثهها سلایق گوناگونی دارند که البته جای تعجب ندارد. در سلایق مختلف توسعهدهندگان اصل مشترکی وجود دارد؛ همگی معتقدند «قبل از اینکه بتوانند تصمیمگیری کنند باید همهچیز را مشاهده کنند.» برخی مایلند اول آزمون را بنویسند تا بتوانند عملکرد کد را حین کدنویسی مشاهده کنند. برخی دیگر گاهی (نه همیشه) مایلند کدهای اولیهای را بنویسد تا در ادامه برای تصمیمگیری در مورد اینکه آیا باید کد بیشتری بنویسد یا نه، فرصت مشاهده داشته باشند.
حتی وقتی توسعهدهندگان در مورد روشهای جایگزین خود صحبت می کنند (مثلاً روشهای غیر TDD)، بازهم بر اینکه مشاهده بخش ذاتی روند توسعه است توافق دارند.
بااینحال شاید برخی «مشاهده» را دست کم بگیرند و فقط بخشی از آزمون یا اشکالزدایی (debugging) بدانند. در اینکه مشاهده در حیطه اشکالزدایی است شکی نیست، اما وقتی با بسیاری از توسعهدهندگان ارشد صحبت کنید، متوجه میشوید که این ایده واقعاً مبنای اصلی کل گردشکار توسعه است. توسعهدهندگان برای تصمیمگیری در مورد کد نیاز به مشاهده دارند. نیاز به مشاهده فقط بعد از تکمیل کد یا مواجهشدن با یک اشکال (باگ) نیست بلکه در هرلحظه، بخشی از روند چرخه حیاتی نرمافزار است.
اصل مشاهده در چرخه تمام توسعههای نرمافزاری به قرار زیر است:
مشاهده —> تصمیم —> عملکرد —> مشاهده —> تصمیم —> عملکرد —> (به همین ترتیب).
«چرخه مشاهده» [۱] یا ODA اصطلاح مناسبی برای این روند است.
اما هدف از ODA در توسعه آزمونمحور چیست؟ چند نمونه برای وضوح بیشتر آن بیان میکنیم. در زمان انجام TDD پیشروی چرخه به شرح زیر است:
- مشکل را میبینید (مشاهده).
- تصمیم به حل مشکل میگیرید (تصمیم).
- یک آزمون مینویسد (عملکرد).
- به آزمون نگاه میکنید و میبینید که آیا API به نظر خوب میرسد (مشاهده).
- اگر خوب به نظر نمیرسد، تصمیم میگیرید که چطور آن را تصحیح کنید (تصمیم)، آزمون را تغییر میدهید و تکرار میکنید: مشاهده —> تصمیم —> عملکرد… تا جایی که API به نظر مناسب باشد، ادامه میدهید.
- اکنون که API به نظر مناسب است، آزمون را اجرا میکنید و میبینید که آیا عمل میکند؟ (مشاهده).
- تصمیم میگیرید که چطور از آزمون عبور کنید (تصمیم).
- کمی کد مینویسید (عملکرد).
- تست را اجرا میکنید و میبینید که آیا عبور میکند یا عمل نمیکند (مشاهده).
- اگر عمل نکرد، تصمیم میگیرید که چطور آن را تصحیح کنید (تصمیم) و کمی کد مینویسید (عملکرد) تا از آزمون عبور کند (مشاهده).
- برحسب اصول طراحی نرمافزار، آگاهی از مشکل، یا دادههای حاصله در حین نوشتن کد قبلی تصمیم میگیرید چه باید انجام بدهید (تصمیم).
- به همین ترتیب ادامه میدهید.
راه مطمئن دیگر برای ادامه این روند نوشتن کد اولیه است. تفاوت آن با توالی فوق این است که در مرحله ۳ بهجای «یک آزمون بنویس»، «یک کد بنویس» خواهد بود. در این صورت برای تصمیمات بیشتر کد را مشاهده میکنید، یا آزمونها را بعد از کد مینویسید و مشاهده میکنید.
بهرهوری و روندهای توسعه
جالب است که هر روند توسعه معتبر، این چرخه را اصل هدایتگر اولیه خود قرار میدهد. حتی این اصل در روشهای مقیاسبزرگ مانند چابک (Agile) که کل تیم را پوشش میدهد برقرار است. در واقع شاید چابک نتیجه تلاش برای کوتاهکردن چرخههای مشاهده-تصمیم-عملکرد تیمها (در حد هفته) نسبت به مدلهای ناموفق قبلی (مانند واترفال، آکا Big Design Up Front) که تکمیل یک چرخه ماهها یا سالها به طول میانجامید بود.
بنابراین به نظر میرسد که چرخه های کوچکتر بهتر از چرخه های بزرگتر باشند و بهرهوری بیشتر، فقط با کوتاهکردن چرخههای ODA، حتی دورههای زمانی مربوط به توسعهدهنده، تیم یا سازمان، امکانپذیر باشد.
معمولاً میتوان کوتاهکردن چرخهها را با تمرکز بر مرحله مشاهده محقق کرد. با تمرکز بر مرحله مشاهده، معمولاً دو بخش دیگر چرخه خودشان سرعت میگیرند (در غیر این صورت باید راهکارهای دیگری بهکار گرفته شود که از حوصله این مقاله خارج است).
در مشاهده سه عامل کلیدی وجود دارد:
- سرعت تحویل اطلاعات به توسعهدهندگان (مثلاً با تسریع آزمونها)؛
- کاملبودن اطلاعاتی که به توسعهدهندگان تحویل داده میشود (مثلاً با پوشش کافی آزمون)؛
- دقت اطلاعاتی که به توسعهدهندگان داده میشود (مثلاً با آزمونهای اعتماد).
با بررسی این سه معیار علل موفقیت برخی از ابزار توسعه در دهه اخیر را میفهمیم. یکپارچهسازی پیوسته، سیستمهای نظارت بر محصول، پروفایلرها، اشکالزداها (دیباگرها)، پیامهای خطای بهتر در کامپایلرها و محیطهای توسعه پیوسته (IDE) که کدهای نامناسب را مشخص میکنند، از این قبیل هستند.
تقریباً هر کارکردی چنین روندی دارد، چراکه با این روند، مشاهده سریعتر، دقیقتر و کاملتر میشود.
نکته مهم در این میان، تحویل اطلاعات به نحوی است که دریافت آن برای افراد آسان باشد. اگر افراد را در دریای عظیمی از اطلاعات غرق کنیم، بدون اینکه راه آسانی برای یافتن اطلاعات موردنظرشان فراهم کنیم، دادهها بیفایده میمانند. شاید یک توسعهدهنده هیچگاه در این مورد انتقاد نشود، اما اگر به دقت اطلاعاتی دریافتی توجه نکند، شاید عادت به نادیده گرفتن دقت اطلاعات بکند. باید اطلاعات را با موفقیت انتقال داد، نه فقط تولید کرد.
اولین ODA
میتوان برای کل فرایند توسعه نرمافزار، یک چرخه بزرگ ODA در نظر گرفت که شامل مشاهده یک مشکل، انتخاب راهکار و تحویل آن در چارچوب یک نرمافزار است. در این چرخه بزرگ، چرخههای کوچک بسیاری هست: تشخیص نیاز به یک ویژگی، تصمیمگیری در مورد نحوه کار ویژگی و سپس نوشتن ویژگی. حتی چرخههای کوچکتری هم وجود دارند (نیاز به تغییرات، تصمیمگیری برای اجرا و نوشتن کد آن) و مانند آن.
سختترین بخش در تمام این مراحل، اولین چرخه ODA است، زیرا نمیتوانید بدون تصمیم یا عملکرد قبلی مشاهدهای انجام دهید. معمولاً در چرخه «بزرگ» چیزی برای مشاهده نیست. هنوز هیچ خروجی کد یا رایانهای وجود ندارد!
در زندگی برای مشاهده از خودتان شروع میکنید. میتوانید محیط اطرافتان را مشاهده کنید. افراد دیگری هستند که میتوانید با آنها صحبت کنید.
اما در توسعه نرمافزار گاهی به نقطه انتخاب میرسید و از خود میپرسید «بعدازاین چه کنم؟». در اینجا است که دانستن اصول طراحی نرمافزار پرفایده است، زیرا میتوانید از این اصول در کدنویسی و مشاهده مشکلات استفاده کنید و در مورد توالی کار تصمیمگیری کنید. میتوان این اصول را مشاهدات دستهدومی درنظر گرفت که قبلاً آزموده شدهاند و تجربه هزاران شخص و صدها سالی است که بهصورت قوانین و مقرراتی فشردهای درآمدند تا دیگران از آن استفاده کنند. مشاهدات ثانوی مادام اینکه دقیق باشد، معتبرند.
حتی خود فرایند مشاهده را میتوان یک چرخه کوچک ODA درنظر گرفت: به دنیا نگاه میکنید، تصمیم میگیرید که باید به چه توجه کنید، توجه خود را بر آن معطوف میکنید، آن را مشاهده کنید، و بر اساس آن مشاهده، قصد مشاهده دیگری را میکنید.
شاید راههای بیشماری برای بهکارگیری این اصل وجود دارد؛ آنچه ذکر شد چند نمونه از آن است.
[۱] Cycle of Observation
