نکات کلیدی
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 در جاوا) به جای تلاش برای پیادهسازی کنترل همزمانی سطح پایین خود استفاده کنید. این ابزارها برای الگوهای همزمانی رایج بهینهسازی و به طور کامل تست شدهاند.
تستهای جامع بنویسید. تست کد همزمان چالشبرانگیز اما حیاتی است. تستهایی بنویسید که:
- چندین رشته ایجاد کنند
- زمانبندی و برنامهریزی را تغییر دهند
- بارها اجرا شوند تا احتمال بروز مسائل متناوب افزایش یابد
- از ابزارهایی مانند تحلیلگرهای رشته و تحلیلگرهای استاتیک برای کمک به شناسایی باگهای احتمالی همزمانی استفاده کنید.
آخرین بهروزرسانی::
FAQ
What's Clean Code: A Handbook of Agile Software Craftsmanship about?
- Focus on Software Craftsmanship: The book emphasizes the importance of writing clean, maintainable code as a hallmark of professionalism in software development.
- Principles and Practices: It outlines various principles, patterns, and practices that help programmers write code that is not only functional but also easy to read and understand.
- Real-World Examples: Numerous examples of both good and bad code are included, demonstrating how to transform messy code into clean code through refactoring and disciplined practices.
Why should I read Clean Code by Robert C. Martin?
- Improve Coding Skills: Reading the book can significantly enhance your programming skills by teaching you how to write code that is easier to maintain and understand.
- Professional Development: It is a valuable resource for anyone looking to advance their career in software development, instilling a mindset of craftsmanship and quality.
- Practical Advice: The book provides practical advice that can be applied immediately in your coding practices, making it a useful guide for both novice and experienced programmers.
What are the key takeaways of Clean Code?
- Meaningful Names: The book stresses the importance of using intention-revealing names for variables, functions, and classes to enhance code readability and maintainability.
- Small Functions: Functions should be small and focused on a single task, adhering to the principle of "Do One Thing" to improve clarity and reduce complexity.
- Error Handling: Martin advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
What are the best quotes from Clean Code and what do they mean?
- "Clean code is a matter of discipline.": This quote emphasizes that writing clean code requires consistent effort and adherence to best practices, rather than relying on luck or talent alone.
- "Comments do not make up for bad code.": This highlights the idea that if code is poorly written, no amount of commenting can compensate for its lack of clarity and structure.
- "Leave the campground cleaner than you found it.": This metaphor encourages developers to improve the codebase with every change, ensuring that the code remains clean and maintainable over time.
How does Clean Code define clean code?
- Readable and Understandable: Clean code is defined as code that is easy to read and understand, allowing other developers to quickly grasp its purpose and functionality.
- Minimal Complexity: It should have minimal complexity, with each function and class focused on a single responsibility, making it easier to test and maintain.
- Well-Structured: Clean code is well-structured, following consistent formatting and naming conventions that enhance its clarity and reduce the cognitive load on the reader.
What is the Boy Scout Rule in Clean Code?
- Continuous Improvement: The Boy Scout Rule states that developers should "leave the campground cleaner than you found it," meaning that every time you work on code, you should strive to improve it.
- Small Changes Matter: This can be as simple as renaming a variable for clarity or refactoring a small function, which contributes to the overall cleanliness of the codebase.
- Professional Responsibility: Adhering to this rule reflects a professional attitude towards code quality and maintenance, fostering a culture of continuous improvement within a team.
What is the Single Responsibility Principle (SRP) in Clean Code?
- Definition of SRP: The SRP states that "a class should have one, and only one, reason to change." This means that each class should focus on a single responsibility or functionality.
- Benefits of SRP: Adhering to SRP leads to better organization of code, making it easier to understand, test, and maintain. It reduces the risk of changes in one area affecting unrelated parts of the code.
- Implementation Guidance: Martin provides practical advice on how to identify responsibilities and refactor classes to adhere to SRP, ensuring that code remains clean and manageable.
How does Clean Code address error handling?
- Use Exceptions: The book advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
- Separation of Concerns: Error handling should be separated from the main logic of the code, allowing developers to focus on the primary functionality without being bogged down by error-checking clutter.
- Provide Context: Exceptions should provide enough context to understand the source and nature of the error, making it easier to diagnose and fix issues when they arise.
What role does testing play in Clean Code?
- Foundation of Clean Code: Testing is considered a fundamental discipline in writing clean code. It ensures that the code behaves as expected and helps catch issues early in the development process.
- Fast and Reliable Tests: The book emphasizes that tests should be fast and reliable to encourage frequent execution. This helps maintain a clean codebase and reduces the risk of introducing bugs.
- Self-Validating Tests: Tests should be designed to be self-validating, meaning they should clearly indicate whether the code is functioning correctly. This reduces ambiguity and increases confidence in the code.
How does Clean Code suggest handling dependencies?
- Dependency Inversion Principle (DIP): The book explains that "high-level modules should not depend on low-level modules. Both should depend on abstractions." This principle encourages the use of interfaces and abstract classes to reduce coupling.
- Use of Dependency Injection: Martin recommends using dependency injection to manage dependencies, allowing for more flexible and testable code. This approach decouples the creation of dependencies from their usage.
- Benefits of Managing Dependencies: By managing dependencies effectively, developers can create systems that are easier to maintain and extend, leading to cleaner and more robust code.
What are some common code smells identified in Clean Code?
- Duplicated Code: This is a major code smell that indicates a lack of abstraction. The book advises eliminating duplication to improve maintainability and reduce errors.
- Long Methods: Methods that are too long can be difficult to understand and maintain. The book suggests breaking them down into smaller, more manageable functions.
- Excessive Comments: While comments can be helpful, excessive or redundant comments often indicate that the code itself is not clear. The goal should be to write self-explanatory code that requires minimal comments.
How can I apply the principles from Clean Code in my own projects?
- Start with Small Changes: Begin by applying the principles of clean code to small sections of your codebase. Refactor one class or function at a time to improve readability and maintainability.
- Write Tests First: Adopt Test-Driven Development (TDD) practices by writing tests before implementing new features. This ensures that your code is always covered by tests and helps maintain quality.
- Regularly Refactor: Make refactoring a regular part of your development process. Continuously look for opportunities to improve code structure and eliminate duplication, keeping your codebase clean and efficient.
نقد و بررسی
کتاب کد تمیز به عنوان یک مطالعه ضروری برای توسعهدهندگان نرمافزار شناخته میشود و دیدگاههای ارزشمندی در مورد نوشتن کد خوانا و قابل نگهداری ارائه میدهد. در حالی که به خاطر توصیههای عملیاش در مورد نامگذاری، طراحی توابع و تست مورد تحسین قرار گرفته است، برخی از خوانندگان آن را بیش از حد متمرکز بر جاوا و گاهی اوقات در توصیههایش افراطی میدانند. مطالعات موردی کتاب واکنشهای متفاوتی را به همراه داشته است، به طوری که برخی آنها را مفید و برخی دیگر کمتر تحت تأثیر قرار گرفتهاند. با وجود نقصهایش، بسیاری از توسعهدهندگان آن را یک مطالعه ضروری میدانند که به طور قابل توجهی شیوههای کدنویسی و درک آنها از هنر نرمافزار را بهبود بخشیده است.
Similar Books






