همه ما از سادگی صحبت می‌کنیم و می‌گوییم عاشق سادگی هستیم. ولی شاید جمله «برای آن مسئله یک راه‌حلی پیدا کردم که عمراً کسی بتواند بفهمد چیکار کردم.» را بعضی وقت‌ها با افتخار بزبان می‌آوریم. پیدا کردن یک راه‌حل پیچیده برای یک مسئله که برای دیگران قابل درک نباشد یک حس نبوغ در ما القا می‌کند؛ اما اگر کسی بتواند برای همان مسئله راه حلی ارائه بدهد که به سادگی توسط همه قابل درک باشد، راه حل پیچیده من یک راه‌حل احمقانه و شاید من یک احمق نامیده شوم. پس قبل از اینکه هر لقبی بگیرید لطفاً این سؤال را از خودتان بپرسید «ساده‌ترین چیزی که ممکن است کار کند، چیست؟”.» این سوالی است که توسعه دهندگان چابک در هنگام نوشتن کد از خودشان می‌پرسند و بدین معناست که ساده‌ترین کاری را انجام دهید که شما را قادر می‌سازد تا در مسیر درست به پیش بروید.
یک از ارزش‌های XP، سادگی و یکی از تکنیک‌های آن طراحی ساده (Simple Design) هست. Kent Beck مبدع XP برای داشتن یک طراحی ساده چهار قانون تعریف کردن که عبارت‌اند از:
- پاس شدن همه تست‌ها
- عدم وجود تکرار
- بیان مقصود برنامه نویس
- کاهش تعداد کلاس‌ها و متدها
پاس شدن همه تست‌ها
پیاده‌سازی تمام کلاس‌ها و متدهایی که بر عهده شما بود را تمام کردید، خوب آیا این به منزله پایان کار شما هست؟ چگونه تشخیص می‌دهید کدی که نوشتید واقعاً کار می‌کند؟ چگونه تشخیص می‌دهید زمانیکه قسمتی از نرم‌افزار را تغییر می‌دهید سایر اجزای نرم‌افزار هنوز به درستی رفتار می‌کنند؟
همه سوالهای بالا بر وجود تست در سیستم تاکید دارند. Unit Test ها کمک می‌کنند که شما بدانید چه زمانی وظیفه شما به پایان رسیده است – زمانیکه شما تمام تست‌های مرتبط با وظیفه‌ای که انجام می‌دهید را نوشته باشید و همه آن‌ها پاس شده باشند. اگر تست یا تست‌هایی پاس نشده باشد شما باید به فعالیت خودتان ادامه بدهید تا همه آن‌ها پاس بشود.
عدم وجود تکرار
تکه کدهایی که در قسمت‌های مختلف برنامه تکرار شده است همیشه فاجعه به بار آورده. کافی هست تغییری اتفاق بیافتد و نیاز باشد همه این تک‌ها اصلاح شوند، به صورت معمول یک و یا چند تا از این تک‌ها اغلب فراموش می‌شود و خطاهای که به مرور گزارش می‌شوند.
این اصل اغلب بین توسعه دهنده‌های نرم‌افزار با نام DRY(Don’t Repeat Yourself.) یا Once And Only Once شناخته می‌شود. البته اصل DRY درباره تکرار کد نیست و درباره تکرار دانش هست، این اصل بیان می‌کند که هر قسمت از دانش ما در سیستم باید جایگاه واحد، بدون ابهام و معتبری داشته باشد. (حسین بقایی عزیز چند ماه قبل لینک یک پست را در مورد DRY توئیت کرده بود که به صورت عالی این اصل را تشریح کرده بود خواندنش را از دست ندهید.)
بیان مقصود برنامه‌‌نویس
شاید این اصل یکی از اولین اصول و در ظاهر ساده‌ترین اصلی است که تعدادی زیادی از برنامه‌نویس‌ها سعی می‌کنند آنرا رعایت کنند. تاکید این اصل بر روی این هست که اسامی متغیرها، متدها، کلاس‌ها و … باید به هدف وجود آن‌ها اشاره کند.
کاهش تعداد کلاس‌ها و متدها
این یکی از اصولی هست که شاید در نگاه اول با اصول بالا در تضاد باشد. وقتی برای نمونه شما برای حذف کدهای تکراری کدهای موجود را ریفکتور می‌کنید به احتمال زیاد تعداد کلاس‌ها و متدها شما افزایش می‌یابد. پس اصل چهارم به خودی‌خود نقض می‌شود؛ اما این اصل به تعداد کلاس‌ها اشاره نمی‌کند و در واقع اشاره آن به اصل YAGNI (You Aren’t gonna need it) می‌باشد. اصل YAGNI بیان می‌کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعاً به آن نیاز دارید و نه وقتی که می‌فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعاً روی آن تاکید دارد و اعلام می‌کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهید داشت آنرا الان پیاده سازی نکنید. پس هدف اصل چهارم این است که نباید با پیاده‌سازی کلاس‌ها و متدهایی که احتمالاً در آینده فرضی به آن نیاز خواهیم داشت نعداد کلاس‌ها و متدها را افزایش بدهیم.