چطور سادگی نرم افزار را حفظ کنیم؟

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

اکثر افراد سعی می‌کنند تا ساده بودن را اندازه گیری کنند؛ در حالی که سادگی قابل محاسبه نیست! چرا که سادگی مفهومی غیر قابل اندازه گیری است. کاری که برای شخصی ساده محسوب می‌شود ممکن است برای دیگری کاری پیچیده باشد. اضافه کردن یک تکنولوژی پیشرفته ممکن است برنامه‌ای (Application) را ساده‌سازی کند ولی برنامه‌ای دیگر را به کلی از هم بپاشد. 

در حین پیشروی پروژه تیم رفته رفته متوجه می‌شود چه چیزی ساده محسوب می شود. به همین منظور همواره با هم کد خود را به صورت ذهنی بررسی کنید. برای این کار چهار مورد پیشنهاد می‌شود: 

  • قابل تست (Testable)
  • قابل فهم (Understandable)
  • قابل مرور (Browsable)
  • قابل توضیح (Explainable)

قابل تست بودن (Testable) یعنی می توانید یونیت تست‌ها و تست‌های پذیرشی بنویسید که می‌توانند به صورت اتوماتیک وجود مشکلات را بررسی کنند. این موضوع، روی طراحی نهایی برنامه تأثیر می گذارد. سیستم را به بخش‌هایی کوچکتر که قابل تست باشند تقسیم کنید. 

قابل مرور (Browsable) به معنی این است که بتوانید به راحتی هر زمان که می خواهید چیزی را که به دنبالش هستید پیدا کنید. اسامی خوب کمک می‌کنند کدها را به راحتی پیدا کنید.

قابل فهم (Understandable) با اینکه واضح است،‌ ممکن است تعریفی متفاوت برای هرکس داشته باشد. تیمی که برای مدت زمانی طولانی روی یک سیستم کار کرده است به راحتی آن را می فهمد در حالی که ممکن است فردی که به تازگی وارد تیم شده است، کاملا گیج باشد. 

به همین دلیل پیشنهاد می‌کنم قابل توضیح (Explainable) را بدین معنا بدانید که توضیح چگونگی کار با سیستم به افراد جدید تا چه حد ساده اتفاق می‌افتد.

مثالی ساده را در نظر بگیرید: برای اینکه عددی را به درصد تبدیل کنیم باید آن را در ۱۰۰ ضرب کنیم، همچنین برای تبدیل سانتیمتر به متر باید آن را در ۱۰۰ ضرب کنیم؛ آیا لازم است تابعی به صورت زیر داشته باشید که اعداد را در ۱۰۰ ضرب کند؟ خیر

  • convertToPercentOrMeters(x)

گر چه این مدل از تکرار جلوگیری می‌کند اما بهتر است به صورت دو تابع نوشته شود:

  • converToPercent(aFraction) 
  • convertMetersToCentimeters(aLength)

چرا؟ چون هر یک، موضوعی متفاوت را بیان می کند؛ زیرا مسئله این نیست که فقط عددی باید در ۱۰۰ ضرب شود بلکه اینکه چرا عدد در ۱۰۰ ضرب می شود حائز اهمیت است. همچنین به اینکه چه نوع اعدادی ورودی معتبر محسوب می‌شود باید اشاره شود.

نکته‌ای که در مورد طراحی‌های ساده اهمیت دارد این است که افراد لازم است دانش کافی برای تشخیص آن را داشته باشند. دانش (Knowldedge) با اطلاعات (Informations) فرق دارد؛ شما می‌توانید یک عالمه اطلاعات داشته باشید اما در عین حال بی دانش باشید. دانش همان بینشی است که در مورد دامنه فعالیت‌تان در طول زمان به دست می‌آورید.

اغلب پس از کمی پیشروی در طول پروژه به طراحی‌های ساده می‌رسیم. بهترین راهکار، کد نویسی فیچرها و در عین حال جستجو جهت کسب دانش کافی است تا طراحی ساده امکان پذیر شود. با این کار می توانید به تدریج درک و طراحی جدیدتان را پیاده سازی کنید.

تا جایی که ممکن است سعی کنید همه چیز را به ساده ترین حالت ممکن بنویسید؛ برای اینکار از اضافه کردن فیچرهای کاربردی قبل از Deadline خودداری کنید.

منبع مطلب
Developers Team Practice
#xp

اشتراک گذاری

پدرام کشاورزی
اسکرام مستر و اجایل کوچ

نظرات

loading ...