کد تمیز
نوشتهٔ رابرت سی. مارتین · سال انتشار 2008
کد را باید در وهلهٔ نخست برای فهم و نگهداشت انسان نوشت، نه صرفاً برای اجرا شدن توسط کامپیوتر.
نقاط قوت
- مقدمهای عالی بر کد نگهداشتپذیر.
- تمرکز قوی بر خوانایی.
- نمونههای کاربردی.
- اصول مهندسیِ اثرگذار.
نقاط ضعف
- برخی توصیهها بیش از حد جزماندیشانهاند.
- چند نمونه کهنه شدهاند.
- مهندسان باتجربه ممکن است با قواعد خاصی موافق نباشند.
- «تمیز» بودن کد وابسته به بستر است.
خلاصه کتاب
«کد تمیز» یک ادعای اخلاقی-حرفهای دارد که رابرت مارتین (معروف به آنکل باب) آن را با قاطعیت بیان میکند: کد بد نه یک انتخاب سبکی، بلکه بیمسئولیتی حرفهای است. استدلال او این است که کد بیشتر از آنکه توسط کامپیوتر «اجرا» شود، توسط انسانها خوانده، فهمیده و نگهداری میشود — نسبت زمان خواندن به نوشتن کد بهشدت به نفع خواندن است — پس معیار اصلی کیفیت باید خوانایی و قابلفهم بودن باشد، نه صرفاً درست کار کردن.
کتاب ترکیبی است از اصول (نامگذاری، طول توابع، ساختار کلاسها، کامنتها) و مثالهای عملی، جایی که مارتین قطعهکدهای واقعی را قدمبهقدم بازنویسی میکند تا نشان دهد چطور کدِ بهظاهر کارآمد میتواند بهطور همزمان کاملاً غیرقابلفهم باشد. بخش زیادی از کتاب حول این ایده میچرخد که کد تمیز نه یک حالت نهایی، بلکه یک عمل مداوم است — کاری که هر بار با تغییر کد انجام میشود، نه یکبار در پروژهٔ آغازین.
مارتین صریحاً کتاب را برای برنامهنویسانی نوشته که میخواهند از «کدنویس» به «مهندس نرمافزار» ارتقا یابند — کسی که مسئولیت کیفیت بلندمدت کدی که مینویسد را میپذیرد، نه صرفاً تحویل چیزی که امروز کار میکند.
ایدههای کلیدی
۱. نامها باید بگویند چرا وجود دارند
مارتین معتقد است انتخاب نام برای متغیر، تابع یا کلاس، مهمترین و کمهزینهترین تصمیم کیفیتی است که یک برنامهنویس هر روز میگیرد. یک نام خوب باید بدون نیاز به کامنت، دلیل وجود چیزی و نحوهٔ استفاده از آن را بگوید. او نامهای مبهم مثل `d` برای تاریخ سپریشده را رد میکند و پیشنهاد میدهد نامها آنقدر گویا باشند که کد شبیه نثر خوانده شود، نه رمز.
۲. توابع باید فقط یک کار انجام دهند
قاعدهٔ مارتین صریح است: یک تابع باید یک کار انجام دهد، آن را خوب انجام دهد، و فقط همان کار را انجام دهد. او استدلال میکند اکثر توابع طولانی در واقع چند تابع کوچکتر پنهانشده در یک بدنهاند و باید استخراج شوند. معیار عملیاش این است: اگر بتوانید بخشی از یک تابع را استخراج کنید و نام معناداری برایش بگذارید، آن تابع دارد بیشتر از یک کار انجام میدهد.
تنها راه رفتن سریع، درست رفتن است.
۳. کامنتها اغلب نشانهٔ شکستاند، نه فضیلت
برخلاف باور رایج که «کامنت بیشتر یعنی کد بهتر»، مارتین میگوید یک کامنت اغلب عذرخواهی برای کدی است که نتوانسته خودش را بهروشنی بیان کند. بهترین کامنت آن است که اصلاً لازم نباشد، چون نامها و ساختار کد خودشان قصد را بیان میکنند. او هشدار میدهد که کامنتها با گذشت زمان از کد جدا میافتند و دروغ میشوند — کدی که تغییر میکند اما کامنتش بهروز نمیشود، بدتر از نبودِ کامنت است.
۴. قانون پیشاهنگی: کد را تمیزتر از آنچه یافتید ترک کنید
این قاعده — که مارتین از حرکت پیشاهنگیِ آمریکا وام گرفته — میگوید هر بار که به قطعهای از کد دست میزنید، آن را کمی بهتر از قبل ترک کنید: یک نام بد را اصلاح کنید، یک تابع طولانی را کوتاه کنید، یک شرط پیچیده را ساده کنید. نکتهٔ کلیدی این است که این بهبود نباید یک پروژهٔ جداگانه یا «بازنویسی بزرگ» باشد؛ باید بخشی طبیعی از هر تغییر کوچک روزمره باشد. جمع این بهبودهای کوچک، در طول زمان، از هر تلاش یکبارهٔ بزرگ برای «تمیز کردن» کدبیس مؤثرتر است.
۵. توسعهٔ مبتنی بر تست و سه قانون آن
مارتین سه قانون برای توسعهٔ مبتنی بر تست معرفی میکند: تست ننویس مگر برای شکست دادن یک کد تولیدی؛ بیش از حد کافی برای شکست خوردن تست ننویس؛ و کد تولیدیِ بیش از حد کافی برای قبول شدن تست ننویس. این چرخهٔ کوچک و مکرر — تست، کد، بازآرایی — تضمین میکند که کدبیس همیشه پوششِ تستِ کامل دارد و ترسِ از تغییر کد قدیمی از بین میرود، چون هر تغییری بلافاصله توسط تستها بررسی میشود.
برای چه کسی مفید است
- برنامهنویسِ در حال گذار از «کاری که کار میکند» به «کاری که نگهداشتنی است» — دقیقاً همان تحولی که کتاب هدفش قرار داده.
- تیمی که استانداردِ مشترکی برای بازبینی کد ندارد — واژگان و معیارهای کتاب پایهای برای بحثهای تیمی میسازند.
- کسی که کدبیسی قدیمی و بههمریخته را نگهداری میکند — قانون پیشاهنگی مشخصاً برای همین موقعیت طراحی شده.
- مهندسِ بسیار باتجربهای که سبک شخصیِ تثبیتشده دارد — ممکن است با برخی قواعد جزماندیشانهٔ کتاب موافق نباشد.
سؤالات پرتکرار
آیا باید هر قاعدهٔ کتاب را بهطور کامل رعایت کنم؟
نه. حتی مارتین خودش قواعد را «حرف آخر» معرفی نمیکند، بلکه ابزاری برای فکر کردن. بهترین استفاده از کتاب این است که اصول را بفهمید و بعد بر اساس بستر پروژهتان تصمیم بگیرید کدامها واقعاً صدق میکنند.
تفاوتش با «برنامهنویس عملگرا» چیست؟
«برنامهنویس عملگرا» دربارهٔ بودن یک مهندس است — عادتها، مسئولیتپذیری، اتوماسیون. این کتاب دربارهٔ نوشتن خودِ کد است — نامگذاری، ساختار توابع، سازماندهی کلاسها. اگر یکی را میخوانید، این یکی برای بهبود کد روزمره مستقیمتر است.
آیا قانون پیشاهنگی نیاز به اجازهٔ مدیریت دارد؟
معمولاً نه، چون منظور تغییرات کوچک درون همان کاری است که دارید انجام میدهید، نه یک پروژهٔ جداگانه. مارتین صراحتاً هشدار میدهد که «بازنویسی بزرگ» اغلب هرگز تمام نمیشود؛ بهبود تدریجی و پیوسته واقعیتر است.
چرا برخی مهندسان باتجربه با این کتاب مخالفاند؟
عمدتاً بهخاطر جزماندیشیِ برخی قواعد. مهندسانی که سالها در بسترهای مختلف کار کردهاند میدانند «تابع کوتاه» یا «بدون کامنت» همیشه بهترین انتخاب نیست؛ گاهی یک تابع طولانیِ خطی خواناتر از ده تابع کوچکِ پراکنده است.
برای زبانهای برنامهنویسی مدرنتر هنوز کاربرد دارد؟
اصول سطحبالا — نامگذاری، تکمسئولیتی بودن، اجتناب از کامنتهای زائد — مستقل از زباناند. نمونههای کد کتاب به جاوا نوشته شدهاند و برخی الگوها در زبانهای تابعی یا مدرنتر شکل متفاوتی دارند، اما اصل زیربنایی همچنان صادق است.
این مطلب برایتان مفید بود؟
شمارش آرا پس از ۵ رأی نمایش داده میشود.
