Facebook Pixel
Searching...
فارسی
EnglishEnglish
EspañolSpanish
简体中文Chinese
FrançaisFrench
DeutschGerman
日本語Japanese
PortuguêsPortuguese
ItalianoItalian
한국어Korean
РусскийRussian
NederlandsDutch
العربيةArabic
PolskiPolish
हिन्दीHindi
Tiếng ViệtVietnamese
SvenskaSwedish
ΕλληνικάGreek
TürkçeTurkish
ไทยThai
ČeštinaCzech
RomânăRomanian
MagyarHungarian
УкраїнськаUkrainian
Bahasa IndonesiaIndonesian
DanskDanish
SuomiFinnish
БългарскиBulgarian
עבריתHebrew
NorskNorwegian
HrvatskiCroatian
CatalàCatalan
SlovenčinaSlovak
LietuviųLithuanian
SlovenščinaSlovenian
СрпскиSerbian
EestiEstonian
LatviešuLatvian
فارسیPersian
മലയാളംMalayalam
தமிழ்Tamil
اردوUrdu
Clean Code

Clean Code

A Handbook of Agile Software Craftsmanship
توسط Robert C. Martin 2008 464 صفحات
4.37
22k+ امتیازها
گوش دادن

نکات کلیدی

1. کد تمیز خوانا، ساده و بیانگر است

کد تمیز همیشه به نظر می‌رسد که توسط کسی نوشته شده که اهمیت می‌دهد.

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

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

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

2. نام‌های معنادار وضوح و نگهداری کد را افزایش می‌دهند

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

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

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

  • CamelCase برای نام کلاس‌ها (مثلاً CustomerOrder)
  • camelCase برای نام متغیرها و توابع (مثلاً totalAmount)
  • ALL_CAPS برای ثابت‌ها (مثلاً MAX_SIZE)

اجتناب از اطلاعات نادرست و نویز. از نام‌هایی که ممکن است گمراه‌کننده یا گیج‌کننده باشند، استفاده نکنید. به عنوان مثال، از استفاده از 'list' در نام متغیر اگر واقعاً یک لیست نیست، اجتناب کنید. همچنین از کلمات زائد یا بی‌معنی در نام‌ها، مانند 'data' یا 'info' که ارزشی اضافه نمی‌کنند، پرهیز کنید.

3. توابع باید کوچک، یک‌کاره و در یک سطح انتزاعی عمل کنند

توابع باید یک کار انجام دهند. باید آن را به خوبی انجام دهند. باید فقط آن را انجام دهند.

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

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

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

4. توضیحات باید حداقلی و واقعاً ضروری باشند

استفاده صحیح از توضیحات برای جبران ناتوانی ما در بیان خود در کد است.

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

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

  • توضیحات قانونی (حق نشر، مجوز)
  • توضیح نیت یا الگوریتم‌ها
  • هشدار از عواقب
  • توضیحات TODO (به صورت محدود استفاده شود)

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

5. قالب‌بندی صحیح خوانایی کد را بهبود می‌بخشد

قالب‌بندی کد درباره ارتباط است و ارتباط اولین وظیفه توسعه‌دهنده حرفه‌ای است.

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

  • تورفتگی
  • شکست خطوط
  • محل قرارگیری براکت‌ها
  • فاصله‌گذاری در اطراف عملگرها و کلمات کلیدی

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

  • مفاهیم مرتبط را نزدیک به هم نگه دارید
  • مفاهیم غیرمرتبط را جدا کنید
  • متغیرها را نزدیک به استفاده‌شان اعلام کنید
  • توابع وابسته را نزدیک به هم قرار دهید

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

6. اشیاء و ساختارهای داده اهداف متفاوتی دارند

اشیاء داده‌های خود را پشت انتزاعات پنهان می‌کنند و توابعی را که بر روی آن داده‌ها عمل می‌کنند، آشکار می‌کنند. ساختارهای داده داده‌های خود را آشکار می‌کنند و توابع معناداری ندارند.

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

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

قانون دمتر. برای اشیاء، از قانون دمتر پیروی کنید: یک متد باید فقط متدهای زیر را فراخوانی کند:

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

7. مدیریت خطا باید تمیز و آموزنده باشد

مدیریت خطا مهم است، اما اگر منطق را مبهم کند، اشتباه است.

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

پیام‌های خطای آموزنده ایجاد کنید. پیام‌های خطا باید زمینه کافی برای درک آنچه اشتباه رخ داده و کجا ارائه دهند. جزئیات مرتبط مانند:

  • چه عملیاتی در حال تلاش بود
  • چه خطای خاصی رخ داد
  • هر مقدار یا اطلاعات حالت مرتبط

ابتدا بلوک‌های try-catch-finally را بنویسید. هنگام نوشتن کدی که ممکن است استثناها را پرتاب کند، با نوشتن بلوک‌های try-catch-finally شروع کنید. این کمک می‌کند تا اطمینان حاصل شود که کد از ابتدا به خطاها مقاوم است و موارد خطا به درستی در نظر گرفته شده‌اند.

8. تست‌های واحد برای نگهداری کد تمیز ضروری هستند

کد تست به اندازه کد تولید مهم است.

ابتدا تست‌ها را بنویسید. از روش توسعه مبتنی بر تست (TDD) پیروی کنید:

  1. یک تست شکست‌خورده بنویسید
  2. حداقل کد را برای گذراندن تست بنویسید
  3. کد را بازسازی کنید در حالی که تست را گذرانده نگه دارید
    این رویکرد اطمینان می‌دهد که کد شما از ابتدا قابل تست است و به طراحی خوب کمک می‌کند.

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

  • خوانا
  • قابل نگهداری
  • قابل اعتماد

اصول F.I.R.S.T را برای تست‌ها دنبال کنید:

  • سریع: تست‌ها باید سریع اجرا شوند
  • مستقل: تست‌ها نباید به یکدیگر وابسته باشند
  • قابل تکرار: تست‌ها باید در هر محیطی قابل تکرار باشند
  • خود اعتبارسنجی: تست‌ها باید خروجی بولی (پاس/شکست) داشته باشند
  • به موقع: تست‌ها باید درست قبل از کد تولید نوشته شوند

9. کلاس‌ها باید کوچک، متمرکز و از اصل مسئولیت واحد پیروی کنند

اولین قانون کلاس‌ها این است که باید کوچک باشند. دومین قانون کلاس‌ها این است که باید از آن هم کوچک‌تر باشند.

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

هدف برای انسجام بالا. متدها و متغیرها درون یک کلاس باید به هم مرتبط باشند و با هم کار کنند تا مسئولیت کلاس را برآورده کنند. انسجام پایین اغلب نشان می‌دهد که یک کلاس سعی دارد کارهای زیادی انجام دهد و باید تقسیم شود.

اصل باز-بسته. کلاس‌ها را به گونه‌ای طراحی کنید که برای توسعه باز باشند اما برای تغییر بسته باشند. این اغلب شامل استفاده از انتزاعات و رابط‌ها برای اجازه دادن به افزودن عملکرد جدید بدون تغییر کد موجود است.

10. همزمانی نیاز به طراحی و پیاده‌سازی دقیق دارد

نوشتن برنامه‌های همزمان تمیز سخت است—بسیار سخت.

چالش‌های همزمانی را درک کنید. برنامه‌نویسی همزمان پیچیدگی‌هایی مانند:

  • شرایط مسابقه
  • بن‌بست‌ها
  • مسائل زنده‌بودن
  • تأثیرات عملکرد

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

از کتابخانه‌ها و چارچوب‌های موجود استفاده کنید. از کتابخانه‌ها و چارچوب‌های همزمانی به خوبی تست شده (مثلاً java.util.concurrent در جاوا) به جای تلاش برای پیاده‌سازی کنترل همزمانی سطح پایین خود استفاده کنید. این ابزارها برای الگوهای همزمانی رایج بهینه‌سازی و به طور کامل تست شده‌اند.

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

  • چندین رشته ایجاد کنند
  • زمان‌بندی و برنامه‌ریزی را تغییر دهند
  • بارها اجرا شوند تا احتمال بروز مسائل متناوب افزایش یابد
  • از ابزارهایی مانند تحلیل‌گرهای رشته و تحلیل‌گرهای استاتیک برای کمک به شناسایی باگ‌های احتمالی همزمانی استفاده کنید.

آخرین به‌روزرسانی::

نقد و بررسی

4.37 از 5
میانگین از 22k+ امتیازات از Goodreads و Amazon.

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

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

رابرت سیسیل مارتین که به عمو باب معروف است، یک مهندس نرم‌افزار برجسته و حامی روش‌های توسعه‌ی چابک است. او به عنوان رئیس شرکت آبجکت منتور، تیمی از مشاوران را رهبری می‌کند که در طراحی شیءگرا، الگوها، UML و روش‌های چابک تخصص دارند. تخصص مارتین به زبان‌ها و روش‌های برنامه‌نویسی مختلفی از جمله C++ و برنامه‌نویسی افراطی گسترش می‌یابد. او به عنوان سردبیر مجله‌ی C++ Report خدمت کرده و سخنران پرطرفداری در کنفرانس‌های بین‌المللی است. تأثیر مارتین در جامعه‌ی توسعه‌ی نرم‌افزار قابل توجه است و آموزش‌ها و کتاب‌های او بهترین روش‌ها برای کد تمیز و مهارت حرفه‌ای در نرم‌افزار را شکل داده‌اند.

Other books by Robert C. Martin

0:00
-0:00
1x
Dan
Andrew
Michelle
Lauren
Select Speed
1.0×
+
200 words per minute
Create a free account to unlock:
Bookmarks – save your favorite books
History – revisit books later
Ratings – rate books & see your ratings
Unlock unlimited listening
Your first week's on us!
Today: Get Instant Access
Listen to full summaries of 73,530 books. That's 12,000+ hours of audio!
Day 4: Trial Reminder
We'll send you a notification that your trial is ending soon.
Day 7: Your subscription begins
You'll be charged on Dec 1,
cancel anytime before.
Compare Features Free Pro
Read full text summaries
Summaries are free to read for everyone
Listen to summaries
12,000+ hours of audio
Unlimited Bookmarks
Free users are limited to 10
Unlimited History
Free users are limited to 10
What our users say
30,000+ readers
“...I can 10x the number of books I can read...”
“...exceptionally accurate, engaging, and beautifully presented...”
“...better than any amazon review when I'm making a book-buying decision...”
Save 62%
Yearly
$119.88 $44.99/yr
$3.75/mo
Monthly
$9.99/mo
Try Free & Unlock
7 days free, then $44.99/year. Cancel anytime.
Settings
Appearance