نکات کلیدی
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) پیروی کنید:
- یک تست شکست‌خورده بنویسید
- حداقل کد را برای گذراندن تست بنویسید
- کد را بازسازی کنید در حالی که تست را گذرانده نگه دارید
این رویکرد اطمینان می‌دهد که کد شما از ابتدا قابل تست است و به طراحی خوب کمک می‌کند.
تست‌ها را تمیز نگه دارید. همان استانداردهای تمیزی را که برای کد تولید خود اعمال می‌کنید، برای کد تست خود نیز اعمال کنید. تست‌های تمیز:
- خوانا
- قابل نگهداری
- قابل اعتماد
اصول F.I.R.S.T را برای تست‌ها دنبال کنید:
- سریع: تست‌ها باید سریع اجرا شوند
- مستقل: تست‌ها نباید به یکدیگر وابسته باشند
- قابل تکرار: تست‌ها باید در هر محیطی قابل تکرار باشند
- خود اعتبارسنجی: تست‌ها باید خروجی بولی (پاس/شکست) داشته باشند
- به موقع: تست‌ها باید درست قبل از کد تولید نوشته شوند
9. کلاس‌ها باید کوچک، متمرکز و از اصل مسئولیت واحد پیروی کنند
اولین قانون کلاس‌ها این است که باید کوچک باشند. دومین قانون کلاس‌ها این است که باید از آن هم کوچک‌تر باشند.
کلاس‌ها را متمرکز نگه دارید. یک کلاس باید یک مسئولیت واحد و به خوبی تعریف شده داشته باشد. اگر نمی‌توانید هدف یک کلاس را در حدود 25 کلمه بدون استفاده از "و" یا "یا" توصیف کنید، احتمالاً کارهای زیادی انجام می‌دهد.
هدف برای انسجام بالا. متدها و متغیرها درون یک کلاس باید به هم مرتبط باشند و با هم کار کنند تا مسئولیت کلاس را برآورده کنند. انسجام پایین اغلب نشان می‌دهد که یک کلاس سعی دارد کارهای زیادی انجام دهد و باید تقسیم شود.
اصل باز-بسته. کلاس‌ها را به گونه‌ای طراحی کنید که برای توسعه باز باشند اما برای تغییر بسته باشند. این اغلب شامل استفاده از انتزاعات و رابط‌ها برای اجازه دادن به افزودن عملکرد جدید بدون تغییر کد موجود است.
10. همزمانی نیاز به طراحی و پیاده‌سازی دقیق دارد
نوشتن برنامه‌های همزمان تمیز سخت است—بسیار سخت.
چالش‌های همزمانی را درک کنید. برنامه‌نویسی همزمان پیچیدگی‌هایی مانند:
- شرایط مسابقه
- بن‌بست‌ها
- مسائل زنده‌بودن
- تأثیرات عملکرد
کد مرتبط با همزمانی را جدا نگه دارید. کدی که با همزمانی سروکار دارد را جدا کنید. این کار باعث می‌شود که هم بخش‌های همزمان و هم غیرهمزمان سیستم شما راحت‌تر قابل درک، تست و نگهداری باشند.
از کتابخانه‌ها و چارچوب‌های موجود استفاده کنید. از کتابخانه‌ها و چارچوب‌های همزمانی به خوبی تست شده (مثلاً java.util.concurrent در جاوا) به جای تلاش برای پیاده‌سازی کنترل همزمانی سطح پایین خود استفاده کنید. این ابزارها برای الگوهای همزمانی رایج بهینه‌سازی و به طور کامل تست شده‌اند.
تست‌های جامع بنویسید. تست کد همزمان چالش‌برانگیز اما حیاتی است. تست‌هایی بنویسید که:
- چندین رشته ایجاد کنند
- زمان‌بندی و برنامه‌ریزی را تغییر دهند
- بارها اجرا شوند تا احتمال بروز مسائل متناوب افزایش یابد
- از ابزارهایی مانند تحلیل‌گرهای رشته و تحلیل‌گرهای استاتیک برای کمک به شناسایی باگ‌های احتمالی همزمانی استفاده کنید.
آخرین به‌روزرسانی::
نقد و بررسی
کتاب کد تمیز به عنوان یک مطالعه ضروری برای توسعه‌دهندگان نرم‌افزار شناخته می‌شود و دیدگاه‌های ارزشمندی در مورد نوشتن کد خوانا و قابل نگهداری ارائه می‌دهد. در حالی که به خاطر توصیه‌های عملی‌اش در مورد نام‌گذاری، طراحی توابع و تست مورد تحسین قرار گرفته است، برخی از خوانندگان آن را بیش از حد متمرکز بر جاوا و گاهی اوقات در توصیه‌هایش افراطی می‌دانند. مطالعات موردی کتاب واکنش‌های متفاوتی را به همراه داشته است، به طوری که برخی آن‌ها را مفید و برخی دیگر کمتر تحت تأثیر قرار گرفته‌اند. با وجود نقص‌هایش، بسیاری از توسعه‌دهندگان آن را یک مطالعه ضروری می‌دانند که به طور قابل توجهی شیوه‌های کدنویسی و درک آن‌ها از هنر نرم‌افزار را بهبود بخشیده است.
