خلاصه کتاب کد تمیز (مقدمه و فصل اول : کد تمیز)

26 بهمن 1399, خواندن در 15 دقیقه

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

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

حتی یه کد بد هم می‌تونه کار کنه، اما اگر کد تمیز نباشه می‌تونه یک سازمان رو به زانو دربیاره. Robert C. Martin یکی از متخصصان برجسته نرم‌افزار یک الگوی انقلابی را با کتاب کد تمیز یا Clean Code: A Handbook of Agile Software Craftsmanship ارائه می‌دهد. مارتین سعی کرده در این کتاب روش‌ها و تمرین‌هایی به شما بده تا مهارت‌های شما به عنوان یک برنامه‌نویس در نوشتن یک کد خوب افزایش پیدا کنه( اما باید توجه کنید که این اتفاق در صورتی می‌افتد که شما سخت تمرین کنید.)

خب شاید سؤال پیش بیاد که در طول خواندن این کتاب چه کارهایی رو انجام می‌دهید؟ شما کدهای زیادی را می‌خوانید و سپس در مورد درستی کد و همینطور اون چیزی که در رابطه با یک قطعه کد اشتباهه، به چالش کشیده خواهید شد.

 Clean code به سه بخش تقسیم میشه :بخش اول که شامل چندین فصل اول هست، اصول،‌الگوها و روش‌های نوشتن کد تمیز را توصیف می‌کنه و لازمه بگم که شما رو برای پارت دوم کتاب هم آماده ‌میکنه. در قسمت دوم، سطح کتاب بالاتر میره و تمرین‌هایی برای تمیز کردن یک قطعه کد به شما داده می‌شه- تبدیل یک قطعه کد که دارای مشکل هست به یک کد صحیح و سالم- و بخش سوم، به نتیجه‌ی نهایی می‌پردازه؛ در بخش نهایی تمامی دلایل ما برای تبدیل و تغییر در یک کد را ، به صورت لیست بیان می‌کنه، به عبارتی نحوه تفکر ما هنگام نوشت، خواندن و تمیز کردن کد رو توصیف می‌کنه.

 خلاصه کتاب کد تمیز – (مقدمه و فصل اول : کد تمیز)

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

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

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

فصل اول : کد تمیز

 خلاصه کتاب کد تمیز – (مقدمه و فصل اول : کد تمیز)

به دو دلیل شما در حال خواندن این کتاب هستید: یک: یک برنامه‌نویس هستید. دو: می‌خواهید برنامه‌نویس بهتری شوید. خوبه، ما به برنامه‌نویس‌های بهتر نیاز داریم.

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

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

( وسط بحث شیرین کتاب لازم دیدم اینجا یه نکته‌ای رو بگم: چند وقت پیش یکی از دوستانم سؤالی رو مطرح کرد؛ سؤالش این بود: برنامه نویس‌ها همیشه با زمانبندی مشکل دارن و همیشه تایم محدودی برای توسعه دارن اما بعضی وقت‌ها کارفرما از اون‌ها زمانبندیی رو درخواست می‌کنه که امکان نداره بهش برسن شما توی اینجور موارد چه جوابی می‌دین و یا چه کاری می‌کنید؟

خب  بیایین بررسی کنیم که جواب برنامه نویس‌ها چی می‌تونه باشه:

برنامه نویس‌ها معمولا دو جواب میدن:

۱. سعی می‌کنن که برسونن: اگر این جواب رو بدن یعنی الان به اندازه کافی تلاش نمی‌کنن که می‌تونن با کار بیشتر یه مورد رو برسونن.

۲. نه: که جواب درست هست. یه نه قاطعانه می‌تونه اطلاعات کافی به تیم لیدر و یا افراد بالادست و حتی مشتری بده که زمانبندی، امکان محقق شدن نداره.

خب حالا اون دسته که می‌گن سعی می‌کنم از چی می‌زنن:

۱. معمولا اولین چیزی رو که فدا می‌کنن کیفیت کار هست و اولین جایی که کیفیت فدا می‌شه تست‌ها هستن. (من با اون گروه که تست نمی‌نویسن اصلا کاری ندارم و در موردشون صحبت نمی‌کنم).

۲. کد تمیز نمی‌زنن (خیلی شلخته کد می‌زنن که فقط خروجی بگیرن).

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

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

تمام اینها فقط بخاطر یک نه گفتن اتفاق می‌افته. هر کاری می‌تونید بکنید این چند مورد را رعایت کنید :

۱. کد را تا می‌تونید تمیز و طبق اصول بنویسید.

۲. حتما و حتما برای محصول تست به اندازه کافی بنویسید و حتی شده TDD کد بزنید.

۳. قاطعانه نه بگید.

شماهم می‌تونید جوابای خودتون رو در رابطه با این سؤال در قسمت نظرات با ما به اشتراک بزارین.)

برمی‌گردیم به کتاب.

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

 خلاصه کتاب کد تمیز – (مقدمه و فصل اول : کد تمیز)

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

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

هنر کد تمیز ؟ 

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

کد تمیز چیست ؟

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

در اینجا از آقایان Bjarne Stroustrup مخترع زبان c++، گردی بوچ نویسنده Object Oriented analysis and Design with Applications، آقای Dave Thomas پدرخوانده استراتژی Eclipse ، میشل فیدرز نویسنده Working Effectively with Legacy Code  و Ron Jeffries نویسنده Extreme Programming Installed و #Extreme Programming Adventures in C ، سؤال شده.

مواردی که آقای Bjarne Stroustrup به آن‌ها اشاره دارد به شرح زیر است:

1. کد باید زیبا و کارآمد باشد.

۲.منطق برنامه باید سر راست باشد تا پنهان کردن باگ‌ها دشوار باشد.

۳.وابستگی حداقلی برای نگهداری برنامه.

۴.کنترل کامل بر خطاها طبق یک استراتژی تکه به تکه و عمل‌کردی بهینه.

همچنین ایشان ذکر می‌کنند که کد باید از نظر ظاهری و رفتاری دلپذیر باشد؛ همینقدر ساده! ظاهراً او فکر می‌کند خواندن یک کد تمیز لذت بخش است.( واقعاً هم یکی از لذت‌های دنیاس :)))) ).

مواردی که آقای گردی بوچ گفتن هم این‌هاست:

کد تمیز ، ساده و سر راست است؛ دقیقاً مثل یک نثر خوب. کد تمیز هرگز هدف طراح را مبهم بیان نمی‌کند. و در نهایت ایشون از عبارت crisp abstraction برای توصیف یک کد خوب استفاده می‌کنند. این یک کلمه با ضد و نقیض ولی جذاب است. در دیکشنری مک بوک من تعریف crisp یا (خشک) به این صورت است : قاطعانه و سرنوشت ساز، بدون تردید و جزيیات غیر ضروری. کد ما باید برخلاف حدس و گمان‌ها، واقعی باشد و همینطور فقط شامل چیزهای مهم و ضروری. خوانندگان ما باید قاطعیت ما را درک کنند.

خب میریم سر وقت مواردی که آقای Dave thomas مؤسس OTI و پدرخوانده استراتژی Eclipse عرض می‌کنن :

 ۱.Unit test

۲.Acceptance test

۳. دارای اسامی معنادار باشد.

۴. کد تمیز به جای اینکه راه‌های زیادی را برای انجام یک کار ارائه دهد، ‌یک راه را برای انجام یک کار دارد.

۵.کد تمیز حداقل وابستگی ممکن را دارد و یک API واضح و حداقلی را ارائه می‌دهد.

همچنین Dave تمیز بودن کد را با تست‌ها پیوند می‌زند و می‌گوید: کد بدون تست تمیز نیست، مهم نیست که چقدر زیبا و قابل خواندن باشد، اگر تست نشده باشد کثیف است.

نفر بعدی آقای میشل فیدرز هستند:

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

از نظر رون جفری :

۱. تمام تست‌ها را اجرا کند.

۲.بدون کد اضافه یا duplicate باشد.

۳.تمام ایده‌های طراحی موجود در سیستم‌ را بیان کند.

۴.تعداد موجودیت‌ها مثل کلاس‌ها، متدها، فانکشن ها و موارد مشابه را به حداقل می‌رساند.

۵.درای اسامی معنا دار است.

وی بیشتر از همه به Duplicate تمرکز دارد. می‌گوید وقتی کارها بارها و بارها انجام شد، نشانگر این است که ایده‌ای در ذهن ما وجود دارد که به خوبی در کد نمایش داده نشده است

همینطور بیان می‌کند که قطعه کدها باید کوچک باشد، مثلاً اگر یک آبجکت داریم باید به دو یا چند آبجکت تبدیل شود و اگر متد باشد از روش refactoring extract method برای اینکه کاری را که یک متد انجام می‌دهد را واضح‌تر بیان کند، استفاده کنیم.

( حالا که انقدر درباره تست صحبت کردیم خوبه که خارج از کتاب یه کم بیشتر به مفهوم و لزوم استفاده ازش تأکید کنم :

ممکنه  براتون سوال شده که TDD چی هست؟ TDD از ترکیب TFD یا همون Test First Design و Refactor هست. یعنی ما اول قبل از اینکه شروع کنیم به کد نویسی اول تست هارو طراحی می‌کنیم و بعد کد نویسی و بعدش هم رفاکتور میکنیم.

یه اشاره‌ای به Reafactor کنیم بعد ادامه TDD رو می‌گیم. Reafactor یه پروسه بهبود طراحی کد هست بدون اینکه رفتار کدها تغییر کنه ،مثل خوانا کردن کد یا کلاس بندی یا هر چیزی که مربوط به طراحی کدها بشه .

 بر میگردیم به TDD ، TDDشامل چندتا مرحله میشه :

1. اول یه تست نوشته میشه . (Add a test)

2.تست نوشته شده ازمایش میشه و چون هنوز کدی برای این تست نوشته نشده پس نتیجه Fail میشه (Run all tests and see if the new one fails)

3.نوشتن کدی که منجر به Pass شدن تست‌ها میشه، البته فقط به اندازه کافی کد مینویسیم که فقط این تست هارو pass کنیم .(Write some code)

4.اجرای تست‌ها و Pass شدن همه تست‌ها ( اگه تست نوشته شده pass شد میریم به مرحله بعدی در غیر این صورت برمیگردیم به مرحله قبل )(Run tests)

5. Refactor code

6.پیاده سازی یه تست جدید Repeat

به این روش Red-Green هم گفته میشه که فکر میکنم مشخصه که دلیلش چیه (قرمز نشانه fail شدن و سبز نشانه pass شدنه)

خب شاید الان با خودتون بگید که اصلا این کار به چه درد میخوره ؟؟!

 من سعی میکنم به چندتا از دلیل‌هاش اشاره کنم  :

1. به اندازه کافی کد مینویسید نه بیشتر.

2.هزینه باگ زدایی کاهش پیدا میکنه.

3نوشتن تست دست اخر سخته و البته میشه گفت به درد نمیخوره .

4.محصولی که تولید میکنید بهینه‌تر میشه .

و خب البته هدف اصلی این روش همون حذف کدهای اضافی و پیاده سازی بهینه نرم افزار در کمترین زمان هست.)

و درپایان توجه داشته باشید که این زبان نیس که برنامه‌ها را ساده جلوه می‌دهد بلکه این برنامه‌نویس است که باعث می‌شود زبان ساده به نظر برسد.

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

چه امتیازی به این مقاله می دید؟
خیلی بد
بد
متوسط
خوب
عالی

دیدگاه‌ها و پرسش‌ها

برای ارسال دیدگاه لازم است، ابتدا وارد سایت شوید.

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

آفلاین
user-avatar
فاطمه شیرزادفر @Fatemeh.shirzadfar
تجربه کلمه‌ای هست که همه برای توصیف اشتباهاتشون ازش استفاده میکنن، و من همیشه دنبال اشتباهات جدیدم! برنامه‌نویس هستم و لینوکس‌ دوست
دنبال کردن

گفتگو‌ برنامه نویسان

بخشی برای حل مشکلات برنامه‌نویسی و مباحث پیرامون آن وارد شو