نکات کلیدی
1. کد تمیز برای توسعه پایدار نرمافزار ضروری است
"کد تمیز همیشه به نظر میرسد که توسط کسی نوشته شده که اهمیت میدهد."
کیفیت کد مهم است. کد تمیز فقط درباره زیباییشناسی نیست؛ بلکه درباره ایجاد نرمافزاری است که به راحتی قابل فهم، نگهداری و توسعه در طول زمان باشد. وقتی کد تمیز است، کار با آن لذتبخش میشود و بار شناختی بر روی توسعهدهندگان کاهش مییابد و به آنها اجازه میدهد تا بر حل مشکلات تمرکز کنند به جای اینکه به رمزگشایی پیادهسازیهای پیچیده بپردازند.
بدهی فنی هزینهبر است. نادیده گرفتن تمیزی کد منجر به انباشت بدهی فنی میشود که میتواند به شدت توسعه آینده را مختل کند و باعث توقف پروژهها شود. با نوشتن مداوم کد تمیز، تیمها میتوانند از مشکلات پیادهسازیهای عجولانه و نامرتب جلوگیری کنند و اطمینان حاصل کنند که نرمافزار آنها به تغییرات نیازها قابل تطبیق باقی میماند.
ویژگیهای کد تمیز:
- خوانا و بیانگر
- به خوبی سازماندهی شده و ساختار یافته
- پیروی از کنوانسیونهای ثابت
- آسان برای فهم و تغییر
- به طور کامل تست شده
2. نامهای معنادار برای خوانایی و نگهداری کد حیاتی هستند
"نام یک متغیر، تابع یا کلاس باید به همه سوالات بزرگ پاسخ دهد."
نامها نیت را منتقل میکنند. انتخاب نامهای مناسب برای متغیرها، توابع و کلاسها یکی از مهمترین جنبههای نوشتن کد تمیز است. نامهای خوب باید به وضوح هدف و رفتار عنصر کد را که نمایندگی میکنند، منتقل کنند و فهم عملکرد کد را برای سایر توسعهدهندگان (از جمله خودتان در آینده) آسانتر کنند.
از اختصارات پیچیده پرهیز کنید. در حالی که ممکن است وسوسهانگیز باشد که از نامهای کوتاه و اختصاری برای صرفهجویی در تایپ استفاده کنید، این اغلب منجر به سردرگمی و کاهش خوانایی میشود. به جای آن، نامهای توصیفی و بدون ابهام را انتخاب کنید که به طور کامل معنا و هدف عنصر کد را منتقل کنند. به یاد داشته باشید که IDEهای مدرن کار با نامهای طولانیتر را از طریق تکمیل خودکار و ابزارهای بازسازی آسان میکنند.
راهنماییهایی برای انتخاب نامهای خوب:
- از نامهای نیتافزا استفاده کنید
- از اطلاعات نادرست یا نامهای گمراهکننده پرهیز کنید
- تمایزات معنادار ایجاد کنید
- از نامهای قابل تلفظ استفاده کنید
- از نامهای قابل جستجو استفاده کنید
- از کدگذاریها یا پیشوندها (مانند Hungarian notation) پرهیز کنید
- نامها را در سطح مناسب انتزاع انتخاب کنید
3. توابع باید کوچک، متمرکز و یک کار را به خوبی انجام دهند
"توابع باید یک کار انجام دهند. باید آن را به خوبی انجام دهند. باید فقط آن را انجام دهند."
کوچک زیباست. توابع را کوتاه و متمرکز بر یک وظیفه یا مفهوم نگه دارید. ایدهآل این است که توابع بیش از 20 خط نباشند و بیشتر آنها بسیار کوتاهتر باشند. این کار آنها را آسانتر برای فهم، تست و نگهداری میکند. وقتی یک تابع بیش از حد بزرگ میشود یا سعی میکند کارهای زیادی انجام دهد، نشانهای است که باید به توابع کوچکتر و متمرکزتر تقسیم شود.
اصل مسئولیت واحد. هر تابع باید یک هدف واضح و واحد داشته باشد. اگر خود را در حال استفاده از کلماتی مانند "و" یا "یا" برای توصیف کاری که یک تابع انجام میدهد میبینید، احتمالاً کارهای زیادی انجام میدهد و باید به چندین تابع تقسیم شود. این رویکرد نه تنها کد را خواناتر میکند بلکه آن را قابل استفاده مجدد و آسانتر برای بازسازی میکند.
ویژگیهای توابع خوب:
- یک کار انجام میدهند
- نامهای توصیفی دارند
- تعداد کمی از آرگومانها را میپذیرند (ایدهآل هیچ تا سه)
- از آرگومانهای پرچم استفاده نمیکنند
- هیچ اثر جانبی ندارند
- اصل مسئولیت واحد را دنبال میکنند
- در یک سطح انتزاعی عمل میکنند
4. نظرات باید به صورت محدود و فقط در مواقع ضروری استفاده شوند
"استفاده صحیح از نظرات برای جبران ناتوانی ما در بیان خود در کد است."
کد باید خود توضیحدهنده باشد. سعی کنید کد خود را به قدری واضح و بیانگر کنید که نیازی به نظرات برای توضیح آنچه انجام میدهد نداشته باشد. کد خوب با نامها و ساختار واضح اغلب در انتقال نیت مؤثرتر از نظرات است. وقتی احساس میکنید نیاز به نوشتن یک نظر دارید، ابتدا بررسی کنید که آیا میتوانید کد را بازسازی کنید تا خودآشکارتر شود.
نظرات میتوانند قدیمی شوند. یکی از خطرات تکیه بر نظرات این است که با تکامل کد، ممکن است قدیمی شوند و منجر به سردرگمی و سوءتفاهم شوند. با تمرکز بر نوشتن کد واضح و خودمستند، خطر گمراه کردن توسعهدهندگان آینده (از جمله خودتان) با نظرات قدیمی را کاهش میدهید.
استفادههای مناسب از نظرات:
- نظرات قانونی (حق تکثیر و غیره)
- توضیح نیت وقتی که نمیتوان آن را در کد بیان کرد
- روشنسازی الگوریتمها یا فرمولهای پیچیده
- هشدار از عواقب
- نظرات TODO (به صورت محدود)
- Javadoc برای APIهای عمومی
5. قالببندی صحیح خوانایی و درک کد را افزایش میدهد
"قالببندی کد درباره ارتباط است و ارتباط اولین وظیفه توسعهدهنده حرفهای است."
ثبات کلیدی است. یک سبک قالببندی ثابت را در سراسر کد خود ایجاد و رعایت کنید. این شامل کنوانسیونهایی برای تورفتگی، شکست خطوط، فضای خالی و سازماندهی عناصر کد است. قالببندی ثابت باعث میشود توسعهدهندگان بتوانند به سرعت کد را اسکن و درک کنند، بار شناختی را کاهش داده و بهرهوری را بهبود بخشند.
قالببندی عمودی مهم است. کد خود را به صورت عمودی سازماندهی کنید تا خوانایی را افزایش دهید. مفاهیم مرتبط را نزدیک به هم نگه دارید و مفاهیم غیرمرتبط را جدا کنید. از خطوط خالی برای ایجاد "پاراگرافها" در کد خود استفاده کنید، جملات مرتبط را گروهبندی کرده و افکار مختلف را جدا کنید. این سازماندهی عمودی به خوانندگان کمک میکند تا به سرعت ساختار و جریان کد را درک کنند.
راهنماییهای قالببندی:
- تورفتگی ثابت (فضاها یا تبها)
- شکست خطوط و فضای خالی مناسب
- تراز عمودی عناصر مرتبط
- گروهبندی منطقی کد مرتبط
- کنوانسیونهای نامگذاری ثابت
- محدود کردن طول خط (مثلاً 80-120 کاراکتر)
- قرار دادن صحیح آکولادها و پرانتزها
6. مدیریت خطا باید کامل و جدا از منطق اصلی باشد
"مدیریت خطا مهم است، اما اگر منطق را مبهم کند، اشتباه است."
جداسازی نگرانیها. کد مدیریت خطا باید از منطق اصلی توابع شما جدا شود. این جداسازی باعث میشود هم مسیر خوشحال و هم مدیریت خطا واضحتر و آسانتر برای درک باشد. استفاده از استثناها برای مدیریت خطاها را در نظر بگیرید، زیرا آنها به شما اجازه میدهند منطق اصلی را تمیز و بدون شلوغی نگه دارید.
خاص و آموزنده باشید. وقتی خطاها رخ میدهند، پیامهای خطای واضح و خاصی ارائه دهید که به شناسایی مشکل و راهحلهای احتمالی کمک کند. از پیامهای خطای عمومی که کاربران یا توسعهدهندگان دیگر را در حدس زدن درباره آنچه اشتباه رفته است، رها میکنند، پرهیز کنید. علاوه بر این، ثبت اطلاعات خطای دقیق برای اهداف اشکالزدایی را در نظر بگیرید.
بهترین روشهای مدیریت خطا:
- از استثناها به جای کدهای بازگشتی استفاده کنید
- پیامهای خطای آموزنده ایجاد کنید
- کلاسهای استثنا را بر اساس نیازهای فراخواننده تعریف کنید
- مقدار null را برنگردانید
- مقدار null را ارسال نکنید
- با استثناها زمینه را فراهم کنید
- APIهای شخص ثالث را برای مدیریت استثناهای خاص آنها بپوشانید
7. تستهای واحد برای حفظ کیفیت کد و تسهیل تغییرات حیاتی هستند
"کد تست به اندازه کد تولید مهم است."
تستها اطمینان را فراهم میکنند. مجموعهای جامع از تستهای واحد اطمینان میدهد که کد شما همانطور که انتظار میرود کار میکند و به شما اجازه میدهد بدون ترس از شکستن عملکرد موجود، تغییراتی ایجاد کنید. تستها به عنوان یک شبکه ایمنی عمل میکنند، رگرسیونها را شناسایی کرده و اطمینان میدهند که کد شما همچنان به درستی عمل میکند.
تستها را ابتدا بنویسید. با پیروی از رویکرد توسعه مبتنی بر تست (TDD)، تستها را قبل از پیادهسازی کد واقعی بنویسید. این تمرین به شما کمک میکند تا طراحی و نیازهای کد خود را قبل از ورود به پیادهسازی بررسی کنید. همچنین اطمینان میدهد که کد شما از ابتدا قابل تست است، طراحی بهتر و کد ماژولارتر و کماتصالتر را ترویج میکند.
ویژگیهای تستهای واحد خوب:
- سریع: تستها باید به سرعت اجرا شوند
- مستقل: تستها نباید به یکدیگر وابسته باشند
- قابل تکرار: تستها باید هر بار نتایج یکسانی تولید کنند
- خوداعتبارسنجی: تستها باید خروجی بولی (قبول/رد) داشته باشند
- به موقع: تستها باید درست قبل از کد تولید نوشته شوند
- خوانا و قابل نگهداری
- پوشش موارد حاشیهای و شرایط مرزی
8. کلاسها باید کوچک، متمرکز و به اصل مسئولیت واحد پایبند باشند
"اولین قانون کلاسها این است که باید کوچک باشند. دومین قانون کلاسها این است که باید از آن هم کوچکتر باشند."
اصل مسئولیت واحد. هر کلاس باید یک و تنها یک دلیل برای تغییر داشته باشد. این اصل شما را تشویق میکند تا کلاسهای کوچک و متمرکزی ایجاد کنید که آسانتر برای فهم، تست و نگهداری باشند. وقتی یک کلاس سعی میکند کارهای زیادی انجام دهد، تغییر آن دشوار میشود و بیشتر مستعد خطا میشود.
انسجام حیاتی است. به دنبال انسجام بالا در کلاسهای خود باشید، به این معنی که متدها و ویژگیهای یک کلاس باید به شدت مرتبط باشند و با هم کار کنند تا هدف کلاس را برآورده کنند. انسجام پایین اغلب نشان میدهد که یک کلاس سعی میکند کارهای زیادی انجام دهد و باید به چندین کلاس کوچکتر و متمرکزتر تقسیم شود.
راهنماییهایی برای ایجاد کلاسهای خوب:
- کلاسها را کوچک نگه دارید (هدف 100-200 خط)
- اصل مسئولیت واحد را دنبال کنید
- انسجام بالا بین متدها و ویژگیها را حفظ کنید
- تعداد متغیرهای نمونه را محدود کنید
- ترکیب را به ارثبری ترجیح دهید
- از تزریق وابستگی برای مدیریت وابستگیها استفاده کنید
- اصل باز-بسته را دنبال کنید (باز برای توسعه، بسته برای تغییر)
9. سیستمها باید با مرزهای تمیز و جداسازی نگرانیها طراحی شوند
"یک معماری سیستم بهینه شامل دامنههای ماژولار شده نگرانی است که هر کدام با اشیاء ساده جاوا (یا دیگر) پیادهسازی شدهاند."
مرزهای واضح. سیستم خود را با مرزهای واضح بین اجزا یا ماژولهای مختلف طراحی کنید. این جداسازی به هر بخش از سیستم اجازه میدهد تا به طور مستقل تکامل یابد و فهم، تست و نگهداری اجزای فردی را آسانتر میکند. از رابطها و کلاسهای انتزاعی برای تعریف این مرزها و پنهان کردن جزئیات پیادهسازی استفاده کنید.
مدیریت وابستگی. وابستگیها بین بخشهای مختلف سیستم خود را به دقت مدیریت کنید. از تزریق وابستگی و وارونگی کنترل برای جدا کردن اجزا و ماژولارتر کردن آنها استفاده کنید. این رویکرد تغییر یا جایگزینی بخشهای سیستم را بدون تأثیر بر دیگران آسانتر میکند.
استراتژیهایی برای طراحی سیستم تمیز:
- از معماری لایهای استفاده کنید (مثلاً ارائه، منطق کسبوکار، دسترسی به داده)
- اصل وارونگی وابستگی را اعمال کنید
- از الگوهای طراحی برای حل مشکلات رایج استفاده کنید
- انتزاعات را برای پنهان کردن جزئیات پیادهسازی ایجاد کنید
- از برنامهنویسی جنبهگرا برای نگرانیهای متقاطع استفاده کنید
- یک معماری پلاگین برای قابلیت توسعه پیادهسازی کنید
- پیکربندی را از کد جدا کنید
10. بهبود مستمر از طریق بازسازی کلید حفظ کد تمیز است
"عمل نوشتن کد تمیز تمرینی است در گرفتن چیزی که کار میکند و تمیز کردن آن تا زمانی که با قوانین مطابقت داشته باشد."
بازسازی مداوم است. کد تمیز در یک مرحله به دست نمیآید بلکه از طریق بهبود مستمر و بازسازی حاصل میشود. همانطور که بینشهای جدیدی به دست میآورید یا نیازها تغییر میکنند، آماده باشید تا کد خود را بازبینی و اصلاح کنید. بازسازی منظم به جلوگیری از انباشت بدهی فنی کمک میکند و کد شما را قابل نگهداری نگه میدارد.
قانون پیشاهنگ. قانون پیشاهنگ را دنبال کنید: "محیط اردوگاه را تمیزتر از آنچه یافتید ترک کنید." هر زمان که روی یک قطعه کد کار میکنید، تلاش کنید تا آن را بهبود بخشید، حتی اگر فقط یک بهبود کوچک باشد. با گذشت زمان، این بهبودهای کوچک به دستاوردهای قابل توجهی در کیفیت و نگهداری کد منجر میشوند.
تکنیکهای بازسازی:
- استخراج متد: متدهای طولانی را به متدهای کوچکتر و متمرکزتر تقسیم کنید
- تغییر نام: نامهای متغیرها، متدها و کلاسها را بهبود بخشید
- جابجایی متد: متدها را به کلاسهای مناسبتر منتقل کنید
- استخراج کلاس: کلاسهای بزرگ را به کلاسهای کوچکتر و متمرکزتر تقسیم کنید
- درونخطی کردن متد: کد را با حذف انتزاعات غیرضروری ساده کنید
- جایگزینی شرطی با چندریختی
- معرفی شیء پارامتر: پارامترهای مرتبط را گروهبندی کنید
- حذف تکرار: کد تکراری را حذف کنید
آخرین بهروزرسانی::
FAQ
What's The Robert C. Martin Clean Code Collection about?
- Focus on Clean Code: The collection emphasizes writing clean, maintainable code and provides practical techniques for software craftsmanship.
- Two Main Parts: It includes Clean Code: A Handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers.
- Professionalism in Programming: The book advocates for a professional attitude towards coding, encouraging responsibility and excellence.
Why should I read The Robert C. Martin Clean Code Collection?
- Improve Coding Skills: It offers insights that can significantly enhance your programming skills by teaching you how to write better code.
- Practical Advice: The book provides pragmatic methods and practices that distinguish software craftsmen from average programmers.
- Long-term Benefits: Adopting its principles can reduce the total cost of ownership of your code, making it easier to maintain and extend.
What are the key takeaways of The Robert C. Martin Clean Code Collection?
- Clean Code Principles: Essential principles include meaningful naming, small functions, and proper error handling.
- Professional Conduct: Emphasizes professionalism, including taking responsibility for your code and effective team communication.
- Continuous Improvement: Encourages a mindset of continuous improvement, urging regular refactoring and enhancement of code.
What is the definition of "clean code" in The Robert C. Martin Clean Code Collection?
- Clarity and Simplicity: Clean code is easy to read and understand, clearly expressing the programmer's intent.
- No Duplication: It should contain no duplication, reducing complexity and potential errors.
- Single Responsibility Principle: Each function and class should have a single responsibility, making it easier to maintain and modify.
What is the Boy Scout Rule mentioned in Clean Code?
- Leave Code Cleaner: The rule states, "Leave the campground cleaner than you found it," meaning improve code every time you work on it.
- Small Improvements Matter: Even minor changes, like renaming a variable, contribute to overall code cleanliness.
- Promotes Team Responsibility: Encourages all team members to maintain high code quality standards, preventing code rot.
What are the Three Laws of TDD in The Clean Coder?
- Failing Test First: You may not write production code until you have written a failing unit test, ensuring tests drive development.
- Minimal Test Code: Write only enough of a unit test to fail, keeping tests focused and relevant.
- Production Code for Tests: Write only enough production code to pass the currently failing test, promoting incremental development.
How does Clean Code suggest handling errors?
- Use Exceptions: Advocates using exceptions rather than return codes for error handling, keeping main logic clean.
- Define Context: Provide context in error messages to help identify the source and nature of errors.
- Separate Error Handling: Keep error handling separate from main logic for clearer, more maintainable code.
What is the Single Responsibility Principle (SRP) in The Clean Coder?
- Definition of SRP: A class or method should have only one reason to change, focusing on a single task or responsibility.
- Benefits of SRP: Leads to more modular, easier-to-test code, reducing bugs and simplifying the codebase.
- Implementation in Practice: Encourages refactoring to ensure adherence to SRP, improving overall code quality.
How does The Clean Coder address testing?
- Advocacy for TDD: Strongly advocates Test-Driven Development as a methodology for writing reliable code.
- Testing Strategies: Discusses unit, integration, and acceptance tests, emphasizing a comprehensive testing suite.
- Continuous Testing: Encourages frequent test runs to ensure new changes don't break existing functionality.
What are some common code smells mentioned in The Clean Coder?
- Long Methods: Indicate a function is doing too much; suggests breaking them into smaller methods.
- Duplicated Code: Major code smell; emphasizes the DRY principle to reduce redundancy.
- Inappropriate Comments: Comments should explain why, not what; encourages writing self-explanatory code.
How does The Clean Coder suggest handling pressure and deadlines?
- Time Management Techniques: Break tasks into smaller pieces and prioritize work to stay focused under pressure.
- Communication with Stakeholders: Emphasizes clear communication about timelines and expectations.
- Maintaining Quality Under Pressure: Warns against sacrificing quality for deadlines, advocating for high standards.
What role does collaboration play in The Robert C. Martin Clean Code Collection?
- Team Dynamics: Collaboration is essential for effective software development; being a loner is unprofessional.
- Knowledge Sharing: Encourages helping each other and sharing knowledge to enhance team skills.
- Pair Programming: Advocates for pair programming to improve code quality and foster collaboration.
نقد و بررسی
مجموعهی کد پاک رابرت سی. مارتین عمدتاً نقدهای مثبتی دریافت کرده است و میانگین امتیاز ۴.۴۸ از ۵ را به خود اختصاص داده است. خوانندگان این کتاب را برای توسعهدهندگان نرمافزار ضروری میدانند و از بینشهای ارزشمند آن در مورد شیوههای کدنویسی و رفتار حرفهای تمجید میکنند. بسیاری آن را به عنوان یک کتاب ضروری میدانند و از راهنماییهای آن در زمینهی کد پاک و مهارتهای فنی قدردانی میکنند. برخی آن را به دلیل داشتن نظرات شخصی و قدیمی بودن در بخشهایی مورد انتقاد قرار میدهند. تمرکز کتاب بر روی جاوا و پارادایمهای خاص برنامهنویسی مورد توجه قرار گرفته است. به طور کلی، این کتاب برای برنامهنویسان تازهکار و با تجربه مفید تلقی میشود، اگرچه برخی پیشنهاد میکنند که با دیدی انتقادی به آن نگریسته شود.
Similar Books







