تو فصل قبل گفتیم که کد نوشتن یعنی حل مسئله برای کاربر. حالا میخوایم از همین پایه، چهار اصل اساسی رو بسازیم که هر کد خوبی باید داشته باشه:
قابل اعتماد بودن
کارایی
قابل نگهداری بودن
قابل استفاده بودن
قابل اعتماد بودن (Reliability):
یه کد قابل اعتماد سه ویژگی داره: درست، پایدار، و مقاوم.
درستی (Correctness) نیازمندیهای کد باید مستقیماً از نحوه استفاده کاربر بیان. اول کاربر و مسئلهاش رو بشناس، بعد از روی اونها نیازمندیهایی تعریف کن که بشه مستقلاً تستشون کرد.
پایداری (Stability) پایداری یعنی کد در شرایط مختلف و با ورودیهای متفاوت، همچنان درست کار کنه. جاوااسکریپت توی مرورگر خیلی در معرض این مشکله — چون روی سختافزارها، سیستمعاملها، و مرورگرهای مختلف اجرا میشه. بهترین راه تأیید پایداری، نوشتن تستهاییه که کد رو در معرض طیف کامل ورودیها قرار بده.
مقاومت (Resilience) پایداری بیشتر با ورودیهای مورد انتظار سر و کار داره، اما مقاومت اینجاست که میپرسه: اگه یه اتفاق غیرمنتظره افتاد چی؟
مثال خوبش اینه: فرض کن میخوای یه فایل MP3 پخش کنی. قبل از اینکه این کارو بکنی، چک کن که مرورگر اصلاً از MP3 پشتیبانی میکنه یا نه
اگه مرورگر پشتیبانی نکرد، بهجای اینکه کد بیسروصدا خراب بشه، یه مسیر جایگزین فعال میشه — مثل نمایش متن صوتی. بهش میگن graceful degradation یا تخریب ظریف.
نکته جالب: وقتی برای شرایط غیرمنتظره آماده میشی، عملاً اونها رو به بخشی از رفتار عادی کدت تبدیل میکنی. این یعنی مقاومت به پایداری تبدیل میشه.
کارایی (Efficiency)
منابع محدودن — وقت و فضا هر دو.
زمان: کد باید CPU رو بیدلیل مشغول نکنه. ولی مراقب بهینهسازیهای جزئی (micro-optimization) باش — اول اندازه بگیر، بعد روی گلوگاههای واقعی کار کن.
فضا: دادهها روی شبکه جابجا میشن، توی RAM موقتاً نگه داشته میشن، و احتمالاً روی دیسک ذخیره میشن. هدف اینه که فقط فضای لازم رو استفاده کنی و داده رو فقط وقتی که واقعاً لازمه جابجا کنی.
زمان و فضا با هم در هم تنیدهان — بهینهسازی یکی معمولاً روی دیگری هم اثر داره. اصل کلی: فقط کاری که لازمه رو انجام بده، اسراف نکن.
قابل نگهداری بودن (Maintainability)
کد مثل ماشین نیست که بدون نگهداری زنگ بزنه، ولی بالاخره باید تغییر کنه — باگها رفع بشن، فیچرها اضافه بشن، و اغلب توسط آدمهای مختلف. اونهایی که روی کد ما کار میکنن هم کاربر ما هستن — پس باید بهشون فکر کنیم.
سازگاری (Adaptability) بهترین نگهداری اونیه که اصلاً لازم نشه انجام بشه. ولی وقتی تغییر لازمه، دو دشمن اصلی داریم:
شکنندگی (Fragility): یه تغییر کوچیک، جاهای بهظاهر نامرتبط رو خراب میکنه.
سختی (Rigidity): برای یه تغییر ساده، باید همهجا رو دستکاری کنی.
راهحل هر دو: ماژولار کردن کد — جدا کردن مسئولیتها به بخشهای مستقل که کمتر به هم وابسته باشن.
آشنایی (Familiarity) کدی که با الگوهای آشنا و قراردادهای رایج نوشته شده، خیلی راحتتر فهمیده میشه. بیشتر اپهای وب مفاهیم مشترکی دارن — ثبتنام، ورود، CRUD — پس نوشتن کد آشنا کار سختی نیست.
قابل استفاده بودن (Usability)
قابل استفاده بودن یعنی کد و چیزی که ارائه میده، برای همه کاربران — چه کاربر نهایی، چه برنامهنویس دیگه — تا جای ممکن ساده و راحت باشه.
User Story یه تکنیک مفید برای تعریف کاربردها اینه:
بهعنوان یه {کاربر}، میخوام {فلان کار} رو انجام بدم تا {فلان هدف} رو برسم.
مثال برای یه اپ مخاطبین:
بهعنوان کاربر، میخوام مخاطب جدید اضافه کنم تا بعداً بتونم پیداش کنم.
بهعنوان کاربر، میخوام مخاطب رو با فامیلی پیدا کنم تا باهاش تماس بگیرم.
طراحی بدیهی (Intuitive Design) کد خوب نباید نیاز به توضیح داشته باشه. مثالهایی از الگوهای بدیهی:
تابعی که با is شروع میشه، مقدار بولین برمیگردونه.
ثابتها با حروف بزرگ نوشته میشن: MAX_SIZE
دکمه X یعنی بستن
دسترسپذیری (Accessibility) کاربرها یه جور نیستن. بعضیها مشکلات بینایی دارن، بعضیها روی سختافزار قدیمی کار میکنن، بعضیها اختلال یادگیری دارن — و این فقط شامل کاربر نهایی نیست، برنامهنویسها هم همینطور. باید برای همه فکر کرد.
اگه همه این اصول پیچیده به نظر میان، یه قانون ساده همه رو جمع میکنه:
همیشه روی کاربر تمرکز کن — همه کاربرها.
