برنامه‌نویس عمل‌گرا

خلاصه کتاب

«برنامه‌نویس عمل‌گرا» دربارهٔ هیچ زبان، فریم‌ورک یا فناوری خاصی نیست و همین دلیل ماندگاری‌اش است. اندرو هانت و دیوید توماس کتابی نوشته‌اند دربارهٔ طرز فکر: اینکه یک مهندس نرم‌افزار خوب چطور با کد، با ابهام و با تغییر روبه‌رو می‌شود. ساختار کتاب مجموعه‌ای از نکته‌های کوتاه و مستقل است که هر کدام یک عادت حرفه‌ای را توضیح می‌دهند.

ایدهٔ حاکم بر کل کتاب مسئولیت‌پذیری است. نویسندگان از همان فصل اول موضع می‌گیرند که کیفیت کد، وضعیت پروژه و مسیر یادگیری خودِ مهندس، همگی چیزهایی هستند که او مالکشان است — نه چیزهایی که برایش اتفاق می‌افتند. بقیهٔ کتاب همین موضع را به تصمیم‌های روزمره ترجمه می‌کند.

مضمون دوم، که در عمل بیشتر به کار می‌آید، مقابله با شکنندگی است. بخش بزرگی از توصیه‌ها — DRY، جداسازی، اتوماسیون، متعامدسازی — در نهایت یک هدف دارند: کاری کنید که تغییر دادن سیستم ارزان بماند. نویسندگان فرض را بر این می‌گذارند که نیازمندی‌ها عوض خواهند شد، و نرم‌افزار خوب را نه چیزی که درست کار می‌کند، بلکه چیزی که می‌شود بی‌ترس عوضش کرد تعریف می‌کنند.

ایده‌های کلیدی

۱. DRY: تکرار، دربارهٔ کد نیست

مشهورترین اصل کتاب معمولاً بد فهمیده می‌شود. «خودت را تکرار نکن» به این معنا نیست که هر دو خط شبیه هم را در یک تابع جمع کنید. تعریف اصلی نویسندگان دربارهٔ دانش است: هر قطعه از دانشِ سیستم باید یک بازنماییِ واحد، بدون ابهام و معتبر داشته باشد.

تفاوت مهم است. دو تکه کد ممکن است امروز یکسان باشند اما دو دانشِ متفاوت را نمایندگی کنند؛ یکی کردنشان بعداً هزینه دارد، چون وقتی یکی از آن دو تغییر کند مجبورید دوباره جدایشان کنید. برعکس، یک قاعدهٔ کسب‌وکار که در سه جای مختلف — کد، مستندات و اسکیمای پایگاه داده — تکرار شده، مصداق واقعی نقض DRY است حتی اگر هیچ خط کدی تکراری نباشد.

۲. متعامدسازی و «گلولهٔ ردیاب»

متعامد بودن یعنی تغییر در یک بخش، بخش‌های دیگر را جابه‌جا نکند. نویسندگان این را نه یک آرمان معماری، بلکه یک معیار عملی می‌دانند: اگر برای عوض کردن یک رفتار مجبورید به پنج فایل نامرتبط دست بزنید، سیستم متعامد نیست و هزینهٔ هر تغییر بعدی بالاتر خواهد رفت.

نرم‌افزار مثل ساختمان نیست؛ بیشتر شبیه باغبانی است — مدام باید هرس شود.

«گلولهٔ ردیاب» مکمل این ایده است: به‌جای ساختن کامل یک لایه در هر مرحله، یک برش نازک اما کامل از سراسر سیستم بسازید که واقعاً کار کند، و بعد ضخیمش کنید. تفاوتش با نمونهٔ اولیه این است که کد گلولهٔ ردیاب دور ریخته نمی‌شود؛ اسکلت نهایی است.

۳. اتوماسیون و بی‌اعتمادی به کار دستی

نویسندگان هر رویهٔ دستیِ تکرارشونده را بدهی می‌دانند. استدلالشان دربارهٔ سرعت نیست، دربارهٔ تکرارپذیری است: کاری که دستی انجام می‌شود، هر بار کمی متفاوت انجام می‌شود، و همین تفاوت‌های کوچک منبع خطاهایی‌اند که بازتولیدشان سخت است.

این همان فصلی است که بیش از همه در صنعت جا افتاد. بخش زیادی از آنچه امروز CI/CD می‌نامیم — بیلد خودکار، تست خودکار، استقرار تکرارپذیر — در این کتاب به‌عنوان عادت حرفه‌ای پیشنهاد شده بود، سال‌ها پیش از آنکه ابزارهایش عمومی شوند.

۴. کد شکننده و «پنجرهٔ شکسته»

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

در کنارش، نویسندگان بر برنامه‌نویسی تدافعی تأکید می‌کنند: قراردادها را صریح کنید، فرض‌ها را با assertion بررسی کنید، و زود شکست بخورید. منطقش این است که خطایی که در لحظهٔ وقوع آشکار شود ارزان است؛ همان خطا اگر چند لایه بالاتر و با تأخیر ظاهر شود، ساعت‌ها وقت می‌گیرد.

۵. اردک لاستیکی: توضیح دادن به‌جای فکر کردن در سکوت

یکی از ماندگارترین تکنیک‌های این کتاب — و در واقع خاستگاه اصطلاحی که امروز در سراسر صنعت رایج است — همین‌جا معرفی می‌شود. توصیه ساده است: یک اردک لاستیکی (یا هر شیء دیگری) کنار مانیتور بگذارید و وقتی گیر کرده‌اید، کد را خط‌به‌خط برایش توضیح دهید، انگار او هیچ‌چیز نمی‌داند.

نکته این نیست که اردک جواب می‌دهد. نکته این است که فرایند توضیح دادنِ صریح و گام‌به‌گام، فرض‌های ناگفته‌ای را که در ذهنتان پنهان مانده‌اند بیرون می‌کشد. اکثر باگ‌ها وقتی پیدا می‌شوند که مجبور شوید چیزی را که «بدیهی» فرض کرده بودید، با کلمات دقیق بیان کنید. نویسندگان این را نمونه‌ای از اصل بزرگ‌تر کتاب می‌دانند: تفکر منفعل، خطا را پنهان می‌کند؛ توضیحِ فعال، آن را آشکار می‌کند.

برای چه کسی مفید است

• مهندسی که دو تا پنج سال تجربه دارد — بهترین نقطهٔ خواندن این کتاب؛ به‌قدر کافی کد نوشته‌اید که مسائلش را بشناسید، و هنوز عادت‌ها تثبیت نشده‌اند.
• کسی که تازه وارد تیم شده — واژگان مشترکی می‌دهد (DRY، متعامد، پنجرهٔ شکسته) که در بازبینی کد واقعاً به کار می‌آید.
• کسی که زبان عوض می‌کند — چون هیچ‌چیز کتاب به یک زبان گره نخورده، دقیقاً همان چیزی است که منتقل می‌شود.
• تیمی که کیفیت را از دست داده — فصل‌های مربوط به بدهی فنی و پنجرهٔ شکسته چارچوب خوبی برای بحث تیمی‌اند.

سؤالات پرتکرار

ویرایش اول یا ویرایش بیستمین‌سالگرد؟

ویرایش دوم، اگر انتخاب دارید. نمونه‌ها به‌روزتر و بخش‌های همزمانی و ابزارها بازنویسی شده‌اند. اما اگر نسخهٔ اول در دسترستان است، اصول اصلی تغییر نکرده‌اند و خواندنش هدر نمی‌رود.

چه تفاوتی با «کد تمیز» دارد؟

«کد تمیز» دربارهٔ نوشتن کد است و این کتاب دربارهٔ بودن یک مهندس. مارتین وارد جزئیات می‌شود — نام‌گذاری، طول تابع، ساختار کلاس — در حالی که هانت و توماس در سطح تصمیم و عادت می‌مانند. اگر یکی را می‌خوانید، این یکی زودتر از دیگری کهنه نمی‌شود.

برای برنامه‌نویس تازه‌کار مناسب است؟

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

DRY را می‌شود بیش از حد اعمال کرد؟

بله، و این رایج‌ترین سوءاستفاده از کتاب است. یکی کردنِ کدهایی که فقط اتفاقی شبیه‌اند، وابستگی‌ای می‌سازد که بعداً باید با هزینه بازش کنید. معیار درست، یکسان بودنِ دانش است نه یکسان بودنِ متن.

کاربردی‌ترین بخشش کدام است؟

فصل‌های اتوماسیون و برنامه‌نویسی تدافعی. اصول کلی الهام‌بخش‌اند، اما این دو بخش مستقیماً به کارهایی تبدیل می‌شوند که همین امروز می‌شود انجام داد: حذف یک مرحلهٔ دستی، صریح کردن یک فرض، شکستن زودهنگام به‌جای انتشار خطا.

اردک لاستیکی واقعاً کار می‌کند؟

برای اکثر برنامه‌نویسان بله، و دلیلش روان‌شناختی است نه جادویی. مغز وقتی چیزی را «فقط فکر» می‌کند اجازه می‌دهد فرض‌های سست بدون بررسی رد شوند؛ وقتی مجبورید همان چیز را با جمله‌های کامل و به ترتیب برای شنونده‌ای (حتی خیالی) توضیح دهید، مغز مجبور به دقت بیشتری می‌شود. نیازی به اردک واقعی نیست؛ یک همکار، یا حتی نوشتن توضیح در یک فایل متنی، همان اثر را دارد.