کدنویسی تمیز یکی از اولین مفاهیمی است که باعث میشود توسعهدهندگان احساس حرفهای بودن کنند. اما برای بسیاری از برنامهنویسان، این مفهوم بهجای یک راهنمای مفید، بهتدریج به یک تله تبدیل میشود. به همین دلیل لازم است مرز آن مشخص شود و زمانی که کدنویسی تمیز علیه بهرهوری عمل میکند، تشخیص داده شود.
همهچیز بیشازحد مهندسی میشود
در مقطعی، بسیاری از توسعهدهندگان از یک خط نامرئی عبور میکنند. تمرکز از حل مشکل امروز برداشته میشود و کد برای حل تمام مشکلات احتمالی آینده نوشته میشود.
یک تابع ساده ناگهان سه لایه انتزاع پیدا میکند «برای روز مبادا». یک قابلیت کوچک به یک مینیفریمورک تبدیل میشود، فقط چون شاید روزی نیاز به مقیاسپذیری داشته باشد.
برای مثال، قالببندی یک تاریخ برای نمایش را در نظر بگیرید. بهجای یک تابع ساده، نتیجه شامل اینترفیس DateFormatter، پیادهسازی پیشفرض، یک factory برای انتخاب فرمتکننده و تزریق وابستگی برای اتصال همه اینها میشود. مشکل اولیه که فقط «تبدیل تاریخ به رشته» بود، زیر حجم زیادی از تشریفات پنهان میشود.
نتیجه، کدی است که از نظر تئوری تمیز است، اما در عمل سنگین و دستوپاگیر. مهندسی بیشازحد اغلب پشت نیتهای خوب پنهان میشود. گاهی این نگرانیها منطقی هستند، اما اغلب فقط حدس و گماناند و حدسهایی که در معماری جا داده میشوند، معمولاً بهخوبی پیر نمیشوند.
در بسیاری از مواقع، تمیزترین راهحل همان سادهترین و حتی خستهکنندهترین راه است: مستقیم، کمی تکراری و بهراحتی قابل حذف در صورت تغییر نیازها.
فلج شدن در دام کمالگرایی
اصول کدنویسی تمیز برای افزایش سرعت طراحی شدهاند، اما اگر بیشازحد جدی گرفته شوند، نتیجه معکوس میدهند و باعث تردید دائمی میشوند.
کدی که بهدرستی کار میکند، بارها بازنویسی میشود چون هنوز «بهاندازه کافی تمیز» به نظر نمیرسد. نام متغیرها بهتر میتوانند باشند، یک تابع بیش از یک مسئولیت دارد، یا یک شرط کمی عجیب است. اصلاح پشت اصلاح انجام میشود و در نهایت، هر تغییر نقص جدیدی ایجاد میکند.
این وضعیت بهخصوص در مراحل اولیه توسعه یک قابلیت جدید رایج است. قبل از اینکه رفتار واقعی قابلیت بررسی شود، نگرانی درباره اندازه توابع، تعداد کلاسها یا تفکیک ماژولها شروع میشود.
در نتیجه، بهجای دریافت بازخورد، روی ایدهای پرداخت انجام میشود که شاید اصلاً بعد از مواجهه با کاربران دوام نیاورد. واقعیت این است که اغلب کدها فقط بعد از استفاده، سوءاستفاده و چند بار تغییر، به شکل نهایی خود میرسند. کدنویسی تمیز معمولاً نتیجه تکرار است، نه شرط شروع.
خلاقیت را محدود میکند
وقتی قوانین کدنویسی تمیز به قانونهای سخت و غیرقابل انعطاف تبدیل میشوند، نهتنها سرعت کاهش مییابد، بلکه شیوه تفکر هم تغییر میکند.
بهجای پرسش «سادهترین راه برای کار کردن این چیست؟»، سؤال به «درستترین ساختار معماری کدام است؟» تبدیل میشود. تمرکز از حل مسئله به تیک زدن یک چکلیست منتقل میشود. این موضوع هنگام آزمایش ایدهها بسیار پررنگ است؛ جایی که یک نمونه سریع یا یک ایده موقتی لازم است.
در محیطهایی مثل برنامهنویسی رقابتی، مفهومی به نام کدنویسی تمیز وجود ندارد: نام متغیرهای عجیب، ماکروها و توابع بزرگ کاملاً رایجاند. دلیلش روشن است؛ هدف حل مسئله به کارآمدترین شکل ممکن است، نه تزئین کد. زمانی که تمرکز ذهن روی راهحل قرار میگیرد، خلاقیت واقعی شکل میگیرد و ایدههای خوب متولد میشوند.
کد ناقصِ منتشرشده بهتر از کد بینقصِ منتشرنشده است
حقیقت ناراحتکننده این است که حتی زیباترین و تمیزترین کد، اگر هرگز از سیستم محلی خارج نشود، هیچ ارزشی ایجاد نمیکند.
کد بینقصی که استفاده نمیشود، تفاوتی با کدی که اصلاً وجود ندارد ندارد. وسواس روی کدنویسی تمیز دقیقاً در همینجا بیشترین آسیب را میزند. همیشه یک بازنویسی دیگر باقی مانده، یک تابع هنوز کمی شلخته است، یا نگرانی از قضاوت دیگران وجود دارد.
در نتیجه، ایده منتشر نمیشود، شاخه ادغام نمیشود و پروژه جانبی ناتمام باقی میماند.
دنیای واقعی به خلوص معماری پاداش نمیدهد؛ به بازخورد پاداش میدهد. کاربران اهمیتی نمیدهند که اصول SOLID رعایت شده یا نه؛ آنها میخواهند مشکلشان حل شود. تنها راه فهمیدن این موضوع، انتشار محصول است.
بسیاری از محصولات بزرگ با کدی شروع شدند که امروز طرفداران افراطی کدنویسی تمیز را آزار میدهد. نسخههای اولیه پر از تکرار، توابع طولانی و تصمیمهای مشکوک بودند. آنچه اهمیت داشت، تمیزی نبود؛ یادگیری بود. ابتدا انتشار انجام شد، سپس واقعیت مشاهده شد و بعد بازنویسی معنا پیدا کرد.
کد ناقصِ منتشرشده یک ویژگی دارد که کد بینقصِ منتشرنشده هرگز نخواهد داشت: آموزش میدهد. مشخص میکند کدام بخشها مهماند، کدام انتزاعها ارزشمندند و کدام ایدههای هوشمندانه بیفایدهاند. قدرت واقعی کدنویسی تمیز بعد از این چرخه بازخورد نمایان میشود، نه قبل از آن.
این موضوع به معنای انتشار کد بیکیفیت یا نادیده گرفتن کیفیت نیست. کدنویسی تمیز باید بهعنوان یک ابزار دیده شود، نه یک معیار اخلاقی. ابزاری برای بهبود کدی که ارزش خود را ثابت کرده، نه مانعی برای دیده شدن ایدهها.
در نهایت، کدنویسی تمیز یک مهارت است. اگر درست استفاده شود، فهم و تغییر سیستمها را آسانتر میکند؛ اما اگر کورکورانه دنبال شود، به اصطکاک، کاهش سرعت، خفه شدن خلاقیت و تأخیر در دریافت بازخورد منجر میشود. هدف نهایی، نرمافزاری است که کار کند و بتواند بهمرور زمان بهتر شود.
