رفتن به نوشته‌ها

Clean Code: قسمت اول – کدی که شما رو بدبخت خواهد کرد

نکاتی که در این رشته مطالب آورده شده است برداشت آزاد من از کتاب است و ترجمه‌ای در کار نیست. اما سعی کرده‌ام که ترتیب و مفهوم اصلی حفظ شود. در بعضی از قسمت‌ها از کد تمیز / کثیف استفاده کردم و در بعضی قسمت‌هابه تناسب از کد بد/ خوب استفاده کردم. 


کد بد

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

کد بد، تعریف ساده‌ای داره:

به کدی که شما رو بدبخت کند، کد بد میگویند.

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

به خاطر دارم که در شرکتی کار میکردم که سوییچ‌های بانکی تولید میکرد. زمانی که من به شرکت وارد شدم، نرم‌افزار شرکت در یکی از بانک‌های نه چندان بزرگ در حال استفاده شدن بود. شبکه شتاب بانک مرکزی، قانونی داره که اگر سوییچ بانکی متصل به شتاب درست وظیفه‌ خودشو انجام نده، بانک جریمه میشه. اون بانک در اون سالها در لیست جرایم همیشه جای ثابتی داشت، اون هم در جایگاه اول یا دوم. سیستم تقریبا غیر قابل دفاع بود. تنها دلیل این موضوع هم خود نرم‌افزار و کد تولید شده بود. کد غیر قابل تست، غیر قابل توسعه و پر ریسک! بعد از چهار سال شرکت تصمیم به باز طراحی این سیستم گرفت. بعد از دردسرهای زیاد، سیستم عملیاتی شد. در لیست جریمه‌های بانک مرکزی، از آخر دوم شد و بهبود قابل توجهی در تراکنش‌ها و زمان انجامشون داشت. اما بعد از چند ماه سیستم به طور کامل توسط بانک جایگزین شد.علت؟ سیستم قبلی تاثیر خودش رو گذاشته بود. ماه‌ها قبل بانک تصمیمش رو گرفته بود و شرکت جایگزین هم آماده بود. میدونید که بانک هزینه کردن براش خیلی کم خطرتر از هزینه‌نکردن هست.

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

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

چرا کد بد میزنیم؟

چون عجله داریم! بله، علت ساده‌ای برای یک مشکل بزرگ هست. اما حقیقت جز این نیست. اکثر کدهای بدی که تولید شده‌اند بیشتر به خاطر کمبود وقت بوده‌اند.

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

 هرگز نگویید بعدا

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

بعدا، یعنی هیچ وقت! 

چه کسی مسول است؟

بدون شک اولین مقصر فردی است که کد را تولید کرده است. اکثر برنامه‌نویس‌ها در زمانی که نسبت به کد بد بازخواست می‌شوند فقط یک دفاع دارند: مدیر از ما خواست! عمو باب در کتاب خودش نکته‌ای رو یادآوری میکنه که من وقتی با افراد با تجربه کار کردم متوجه شدم. قدرت نه گفتن!

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

مدیرها وظیفه دارند که برنامه‌ریزی کنند و از اون برنامه دفاع کنند. ابزارهای اونها برای رسیدن به این هدف برنامه‌نویس‌های تیمشون هستند. همونقدر که با اونها قدرتمند هستند، بدون تیم و منابع انسانیشون هیچ قدرتی ندارند. اونها میخوان که کار رو با بیشترین سرعت پیش ببرند. در مرحله اول باید این موضوع رو کاملا درک کنیم.

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

اما شاید مهم‌تر از نتایج بالا، ما خودمون رو با این کار نجات خواهیم داد. اگر تلاش کنیم کد بهتری رو ایجاد کنیم در آینده دردسر کمتری برای توسعه اون خواهیم کشید. پروژه‌های نرم‌افزاری مثل انباری خونه میمونه که اگر وسایل رو به درستی و سر وقت بچینیم و هر چند وقت یکبار نسبت به مرتب کردنشون اقدام کنیم، در هنگام نیاز به یک پیچ نیازی نیست جعبه بزرگ تلویزیون که تو اساس کشی قبلی پرتش کردیم روی همه وسایل رو جابجا کنیم! این کار هرچند که در اول راه سخت خواهد بود اما در طولانی مدت، منفعت بسیار زیادی ازش خواهید داید. در نتیجه نسبت به مسولیت خودمون باید بیشتر دقت کنیم.

بعضی‌ها تصور میکنند که اهمیت دادن به کد تمیز و پرهیز از ورود کدهای کثیف به سیستم باعث از دست رفتن زمان و عبور از deadLine ها میشه. در مورد این موضوع شاید بهتر باشه از این رویکرد نگاه کنیم که deadline ها با کد کثیف حتما رد خواهند شد اما با کد تمیز احتمال زیادی وجود داره که بتونیم با کمی تقریب زیاد یا کم به deadline ها هم برسیم. دلیل این موضوع هم در پاراگراف قبلی گفته شده! نیازی هست دوباره تاکید کنم؟

هنر برنامه نویس بودن

تا حالا معمار خوب دیدید؟ مکانیک یا نقاش چطور؟ این متخصص‌ها با دیدن یا گوش کردن به شما میگن که کجای کار ایراد داره و راه‌حل بهتر شدن رو دارن.  اونا کارشون رو خوب بلدن و این sense و ذائقه برای خوب بودن رو دارند. این حس رو به شما که ممکنه چیزی از حرفه اونها هم ندونید انتقال میدن. یک برنامه‌نویس با داشتن یک sense خوب برای کد تمیز هم دقیقا همین ویژگی‌ها رو داره.

بعضی‌ها از ابتدا این حس رو دارند. بعضی‌ها بعد از مدتی به دست میارند و بعضی‌ها برای شکوفایی این استعداد باید تلاش زیادی بکنند. (البته بعضی‌ها هم هستند که اشتباه برنامه نویس شدند از نظر من!) اما آیا هرکسی به راحتی میتونه این قابلیت رو به دست بیاره؟ قطعا نه.

بین برنامه‌نویسی که میتونه کد خوب تولید بکنه با کسی که حس و ذائقه داره تفاوت بسیار زیادی وجود داره. در واقع به نظر میاد که داریم در مورد دیدن یک نقاشی خوب و کشیدن اون نقاشی صحبت می‌کنیم. کسی چوب جادویی نداره و شما باید این مسیر رو جزیی از روند حرفه‌ای شدنتون در نظر بگیرید.

کد تمیز

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

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

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

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

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

کمپ را تمیزتر از حالت قبل ترک‌ کنید.

در واقع باید کد شما همیشه بعد از تغییر بهتر از کد قبلی نوشته شده باشه و اگر قسمت جدیدی رو بهش اضافه میکنید باید همون guideline ها رو رعایت بکنید. هیچ وقت سعی نکنید امضای خودتون رو در پروژه ایجاد کنید.

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

منتشر شده در clean code

نظر

  1. mohammad mohammad

    بسی لذت بردیم لطفا ادامه بدید.

  2. خیلی خوبه نوشته هاتون . مشتاق ادامه داستانیم

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Translate »