Key Takeaways
1. כתוב קוד נקי, קריא וניתן לתחזוקה
המדד היחיד התקף לאיכות קוד: WTFs/דקה
קריאות היא בראש סדר העדיפויות. קוד נקי צריך להיות מובן בקלות על ידי מפתחים אחרים. הוא צריך להיות פשוט, אלגנטי וחף מהסחות דעת. שאף לכתוב קוד שמביע בבירור את כוונתו מבלי להזדקק להערות נרחבות. השתמש בשמות משתנים ופונקציות משמעותיים, שמור על פונקציות קטנות וממוקדות, וארגן את הקוד בצורה לוגית.
תחזוקה מאפשרת אבולוציה. קוד שקשה לשנות הופך לנחלה. עיצוב את הקוד שלך כך שיהיה גמיש ומודולרי כדי שיוכל להתאים לדרישות משתנות. עקוב אחרי עקרונות כמו DRY (אל תחזור על עצמך) ו-SOLID כדי ליצור מערכות רופפות קשר, אך בעלות Cohesion גבוהה. בצע רפקטורינג ללא רחמים כדי לשפר את מבנה הקוד מבלי לשנות את ההתנהגות.
קוד נקי משתלם. אמנם כתיבת קוד נקי דורשת יותר מאמץ בהתחלה, היא חוסכת זמן וכאבי ראש משמעותיים בטווח הארוך. קוד נקי קל יותר לניפוי שגיאות, הרחבה ותחזוקה. הוא מאפשר למפתחים לעבוד בצורה יעילה יותר ומפחית את הסיכון להיכנס באגים במהלך שינויים. הפוך את הקוד הנקי לחלק מרכזי מהפרקטיקה שלך בפיתוח.
2. עקוב אחרי קונבנציות שמות משמעותיות
שם של משתנה, פונקציה או מחלקה, צריך לענות על כל השאלות הגדולות. הוא צריך להסביר מדוע הוא קיים, מה הוא עושה ואיך הוא משמש.
השתמש בשמות שמגלים כוונה. בחר שמות שמעבירים בבירור את המטרה וההתנהגות של משתנים, פונקציות ומחלקות. הימנע משמות באות אחת או קיצורים לא ברורים. השתמש בשמות שניתן להגות בקלות ושניתן לחפש בקלות. לדוגמה:
- רע: d (זמן שחלף בימים)
- טוב: elapsedTimeInDays
היה עקבי ומדויק. השתמש בקונבנציות שמות עקביות בכל הקוד שלך. היה מדויק כדי להימנע מאמביגואיות - לדוגמה, השתמש בהבחנות משמעותיות כמו getActiveAccounts() ו-getActiveAccountInfo(). הימנע מקידודים או קידומות שמוסיפים רעש ללא ערך. שמות מחלקות צריכים להיות שמות עצם, ושמות שיטות צריכים להיות פעלים.
אורך השם צריך להתאים להיקף. השתמש בשמות ארוכים ומפורטים יותר עבור משתנים ופונקציות עם היקפים גדולים יותר. שמות קצרים מקובלים עבור היקפים קטנים ומקומיים. אורך השם צריך להיות פרופורציונלי להיקף השימוש שלו. אופטימיזציה לקריאות והבנה בהקשר שבו השם משמש.
3. שמור על פונקציות קטנות וממוקדות
פונקציות צריכות לעשות דבר אחד. הן צריכות לעשות זאת היטב. הן צריכות לעשות זאת בלבד.
קטן זה יפה. פונקציות צריכות להיות קטנות - בדרך כלל באורך של 5-10 שורות. הן צריכות להתאים למסך אחד ולהיות מובנות מיד. הוצא קוד לפונקציות עזר עם שמות טובים במקום לכתוב פונקציות ארוכות ומורכבות. פונקציות קטנות קלות יותר להבנה, לבדיקה ולתחזוקה.
עשה דבר אחד היטב. לכל פונקציה צריכה להיות מטרה אחת ברורה. אם פונקציה עושה מספר דברים, הוצא את אלה לפונקציות נפרדות. סימנים לכך שפונקציה עושה יותר מדי כוללים:
- רמות רבות של אבסטרקציה
- מספר קטעים או בלוקים של קוד
- פרמטרים רבים
שמור על רמת אבסטרקציה אחת. ההצהרות בתוך פונקציה צריכות להיות כולן באותה רמת אבסטרקציה. אל תערבב לוגיקה ברמה גבוהה עם פרטים ברמה נמוכה. הוצא פעולות ברמה נמוכה לפונקציות נפרדות. זה משפר את הקריאות על ידי שמירה על פונקציות ממוקדות ופשוטות מבחינה רעיונית.
4. תרגל עיצוב וארגון נכון
עיצוב קוד הוא על תקשורת, ותקשורת היא סדר העדיפויות הראשון של המפתח המקצועי.
עיצוב עקבי חשוב. השתמש בהזחה, הפסקות שורה ורווחים עקביים בכל הקוד שלך. זה משפר את הקריאות ומפחית את העומס הקוגניטיבי. הסכם על סטנדרטים לעיצוב עם הצוות שלך והשתמש בכלים אוטומטיים כדי לאכוף אותם. הנחיות עיצוב מרכזיות כוללות:
- הזחה נכונה
- מיקום עקבי של סוגריים
- הפסקות שורה לוגיות
- רווחים מתאימים
ארגן את הקוד בצורה לוגית. קבץ קוד קשור יחד והפרד קוד לא קשור. השתמש בשורות ריקות כדי ליצור הפסקות "פסקה" בין קטעים לוגיים. הנח פונקציות קשורות זו ליד זו. שמור על קבצים ממוקדים על רעיון או רכיב אחד. חלק קבצים גדולים לקבצים קטנים וממוקדים יותר כאשר זה מתאים.
עקוב אחרי קונבנציות סטנדרטיות. הקפד על קונבנציות סטנדרטיות לשפה ולקהילה שלך. זה עושה את הקוד שלך למוכר ונגיש יותר למפתחים אחרים. לדוגמה, ב-Java:
- שמות מחלקות משתמשים ב-PascalCase
- שמות שיטות משתמשים ב-camelCase
- קבועים משתמשים ב-ALL_CAPS
5. נהל תלותים והימנע משכפול
שכפול עשוי להיות שורש כל הרע בתוכנה.
הסר שכפול. קוד משוכפל הוא הזדמנות שהוחמצה לאבסטרקציה. כאשר אתה רואה שכפול, הוצא את הקוד המשותף לפונקציה או מחלקה שניתן לעשות בה שימוש חוזר. זה משפר את התחזוקה על ידי ריכוז הלוגיקה ומפחית את הסיכון לשינויים לא עקביים. סוגי שכפול שיש לשים לב אליהם:
- בלוקים של קוד זהים
- אלגוריתמים דומים עם וריאציות קלות
- שרשראות switch/case או if/else חוזרות
נהל תלותים בזהירות. צמצם תלותים בין מודולים כדי להפחית את הקשר. השתמש בהזרקת תלות והיפוך שליטה כדי להפוך את הקוד שלך למודולרי יותר וניתן לבדיקה. עקוב אחרי עקרון ההיפוך של תלות - תלה באבסטרקציות, לא בקונקרציות. זה עושה את הקוד שלך לגמיש יותר וקל יותר לשינוי.
השתמש בעקרון הידע המינימלי. מודול לא צריך לדעת על הפנימיות של האובייקטים שהוא מניפולטיבי. זה מפחית את הקשר בין מודולים. לדוגמה, השתמש בחוק דמטר - שיטה צריכה לקרוא רק לשיטות על:
- האובייקט שלה
- אובייקטים המועברים כפרמטרים
- אובייקטים שהיא יוצרת
- אובייקטים ישירים שלה
6. נהל שגיאות בצורה אלגנטית
ניהול שגיאות הוא חשוב, אבל אם הוא מטשטש לוגיקה, זה לא נכון.
השתמש בהחרגות במקום קודי שגיאה. החרגות הן נקיות יותר ואינן מסיחות את הדעת מהלוגיקה המרכזית של הקוד שלך. הן מאפשרות ניהול שגיאות להיות מופרד מהמסלול החיובי. כאשר אתה משתמש בהחרגות:
- צור הודעות שגיאה אינפורמטיביות
- ספק הקשר עם החרגות
- הגדר מחלקות החרגה על פי הצרכים של הקורא
אל תחזיר null. החזרת null מובילה לשגיאות מצביעים null ומסיחה את הדעת עם בדיקות null. במקום זאת:
- החזר אוספים ריקים במקום null עבור רשימות
- השתמש בדפוס אובייקט null
- השתמש ב-Optional ב-Java או Maybe בשפות פונקציונליות
כתוב משפטי try-catch-finally קודם. התחל עם ה-try-catch-finally כאשר אתה כותב קוד שעשוי לזרוק החרגות. זה עוזר להגדיר את ההיקף והציפיות עבור הקוד הקורא. זה מבטיח שהמשאבים מנוהלים ומשוחררים כראוי, גם בתרחישי שגיאה.
7. כתוב בדיקות יחידה מקיפות
קוד בדיקה חשוב בדיוק כמו קוד ייצור.
עקוב אחרי שלוש החוקים של TDD. פיתוח מונחה בדיקות (TDD) משפר את איכות הקוד ועיצובו:
- כתוב בדיקה נכשלת לפני כתיבת כל קוד ייצור
- כתוב רק מספיק מהבדיקה כדי להדגים כישלון
- כתוב רק מספיק קוד ייצור כדי לעבור את הבדיקה
שמור על בדיקות נקיות וניתנות לתחזוקה. החל את אותם סטנדרטים של איכות קוד על הבדיקות שלך כמו על קוד הייצור שלך. בצע רפקטורינג ושפר את קוד הבדיקות באופן קבוע. בדיקות מסודרות היטב משמשות כעדות ומאפשרות רפקטורינג חסר פחד של קוד הייצור.
שאף לכיסוי בדיקות מקיף. כתוב בדיקות שמכסות מקרים קצה, תנאי גבול ותסריטי שגיאה - לא רק את המסלול החיובי. השתמש בכלי כיסוי קוד כדי לזהות פערים בכיסוי הבדיקות. זכור שכיסוי של 100% לא מבטיח קוד ללא באגים, אבל הוא מספק ביטחון ברפקטורינג ושינויים.
8. בצע רפקטורינג באופן מתמשך
השאר את הקמפינג נקי יותר ממה שמצאת אותו.
בצע רפקטורינג באופן הזדמנותי. שפר את מבנה הקוד בכל פעם שאתה עובד על קטע קוד. עקוב אחרי חוק הצופה: השאר את הקוד טוב יותר ממה שמצאת אותו. שיפורים קטנים והדרגתיים מצטברים עם הזמן ומונעים ריקבון קוד. טכניקות רפקטורינג נפוצות כוללות:
- הוצאת שיטות או מחלקות
- שינוי שמות לבהירות
- פישוט תנאים מורכבים
- הסרת שכפול
בצע רפקטורינג בבטחה עם בדיקות. תמיד היה לך סט בדיקות מוצק לפני רפקטורינג. בצע שינויים קטנים והדרגתיים והריץ בדיקות בתדירות גבוהה. זה נותן לך ביטחון ששינויים שלך לא מפרים פונקציות קיימות. השתמש בכלי רפקטורינג אוטומטיים כאשר הם זמינים כדי להפחית את הסיכון להיכנס שגיאות.
שמור על איזון בין רפקטורינג לספק ערך. אמנם רפקטורינג מתמשך הוא חשוב, אל תיתן לו לשתק את ההתקדמות. שאף ל"טוב מספיק" במקום שלמות. התמקד במאמצי רפקטורינג באזורים הבעייתיים ביותר או באזורים שמשתנים לעיתים קרובות בקוד. תקשר את ערך הרפקטורינג למעורבים כדי להבטיח תמיכה בשיפור הקוד המתמשך.
9. החל עקרונות תכנות מונחה אובייקטים ופונקציות
אובייקטים מסתירים את הנתונים שלהם מאחורי אבסטרקציות ומציגים פונקציות שפועלות על הנתונים הללו. מבני נתונים חושפים את הנתונים שלהם ואין להם פונקציות משמעותיות.
השתמש בעקרונות תכנות מונחה אובייקטים בחוכמה. החל עקרונות כמו אינקפסולציה, ירושה ופולימורפיזם כדי ליצור עיצובים גמישים ומודולריים. עקוב אחרי עקרונות SOLID:
- עקרון האחריות היחידה
- עקרון פתוח-סגור
- עקרון החלפת ליסקוב
- עקרון הפרדת ממשקים
- עקרון ההיפוך של תלות
נצל את מושגי התכנות הפונקציונלי. אפילו בשפות מונחות אובייקטים, טכניקות תכנות פונקציונליות יכולות להוביל לקוד נקי יותר:
- פונקציות טהורות ללא תופעות לוואי
- נתונים בלתי ניתנים לשינוי
- פונקציות בדרגה גבוהה
- הרכבת פונקציות
בחר את הגישה הנכונה לבעיה. לפרדיגמות מונחות אובייקטים ופונקציות יש כל אחת יתרונות וחסרונות. השתמש בעיצוב מונחה אובייקטים כאשר אתה צריך לדגם תחומים מורכבים עם התנהגות. השתמש בגישות פונקציונליות עבור טרנספורמציה של נתונים וצינורות עיבוד. רבות מהשפות המודרניות תומכות בגישה היברידית, המאפשרת לך להשתמש בכלי הטוב ביותר עבור כל חלק במערכת שלך.
10. שקול קונקרנציה בזהירות
קונקרנציה היא אסטרטגיית הפחתת קשרים. היא עוזרת לנו להפריד בין מה שמתבצע לבין מתי זה מתבצע.
הבן את אתגרי הקונקרנציה. תכנות קונקרנטי מביא עמו מורכבות ופוטנציאל לבאגים עדינים. בעיות נפוצות כוללות:
- מצבי תחרות
- Deadlocks
- אותות חסרים
- בעיות נראות בזיכרון
הפרד את הדאגות הקונקרנטיות. שמור את הקוד הקשור לקונקרנציה נפרד מקוד אחר. זה מקל על ההבנה והבדיקה. השתמש באבסטרקציות כמו Executors, Futures ו-Actors כדי לנהל קונקרנציה במקום לעבוד עם חוטים גולמיים.
העדף אובייקטים בלתי ניתנים לשינוי ופונקציות טהורות. אובייקטים בלתי ניתנים לשינוי ופונקציות טהורות בטוחות באופן טבעי לחוטים. הם מסלקים רבות מהבעיות הקונקרנטיות על ידי הימנעות ממצב משתנה משותף. כאשר מצב משתנה הכרחי, השתמש בטכניקות סנכרון מתאימות ושקול להשתמש במשתנים אטומיים או באוספים קונקרנטיים.
Last updated:
FAQ
What's "Clean Code: A Handbook of Agile Software Craftsmanship" about?
- Focus on Clean Code: "Clean Code" by Robert C. Martin emphasizes writing code that is easy to read, understand, and maintain.
- Professionalism in Coding: It argues that clean code is a hallmark of professionalism in software development.
- Practical Advice: The book provides guidelines, examples, and case studies to help developers write clean and efficient code.
Why should I read "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Improve Coding Skills: It teaches how to write code that is clean, efficient, and maintainable.
- Learn from Experts: Part of the Robert C. Martin series, known for its technical and pragmatic approach.
- Long-term Benefits: Writing clean code reduces maintenance costs and makes you a more valuable developer.
What are the key takeaways of "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Code Readability: Emphasizes that code should be easy to read and understand.
- Single Responsibility Principle: Advocates for each class or function to have one reason to change.
- Continuous Improvement: Encourages developers to continuously improve their code, following the Boy Scout Rule.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" define clean code?
- Elegance and Efficiency: Clean code is described as elegant and efficient, with minimal dependencies.
- Readable and Maintainable: It should read like well-written prose, making the designer's intent clear.
- Focused and Single-minded: Each function, class, and module should have a single, clear purpose.
What is the Single Responsibility Principle in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- One Reason to Change: A class or module should have one, and only one, reason to change.
- Improves Cohesion: Ensures that classes are cohesive, with closely related methods and variables.
- Facilitates Maintenance: Makes the code easier to maintain and extend, reducing the impact of changes.
What is the "Boy Scout Rule" mentioned in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Suggests leaving the codebase cleaner than you found it.
- Small, Incremental Changes: Encourages making small improvements, like renaming variables or breaking up functions.
- Professional Responsibility: Presented as a professional responsibility to ensure maintainability.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" approach Test-Driven Development (TDD)?
- Fundamental Discipline: TDD is crucial for writing clean, reliable code.
- Three Laws of TDD: Write a failing test first, write code to pass the test, then refactor.
- Benefits: Helps catch bugs early and improves code design.
What are "code smells" according to "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Definition: Indicators of potential problems that hinder readability or maintainability.
- Examples: Long methods, large classes, and duplicated code.
- Addressing Smells: Provides heuristics and refactoring techniques to improve code quality.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" suggest handling exceptions?
- Prefer Exceptions: Use exceptions instead of error codes for better context and management.
- Provide Context: Include meaningful messages and context when throwing exceptions.
- Avoid Checked Exceptions: Suggests using unchecked exceptions for cleaner code.
What role do unit tests play in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Ensure Code Quality: Unit tests ensure code works as intended and remains maintainable.
- Test-Driven Development: Advocates writing tests before production code.
- Clean and Readable Tests: Tests should be as clean and readable as production code.
What is the role of refactoring in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Refactoring improves code structure and readability without changing functionality.
- Techniques: Provides techniques like Extract Method and Rename Variable to enhance code quality.
- Fearless Refactoring: With comprehensive tests, developers can refactor confidently.
What are the best quotes from "Clean Code: A Handbook of Agile Software Craftsmanship" and what do they mean?
- "Clean code does one thing well." Emphasizes focus and clarity in code.
- "Leave the campground cleaner than you found it." Encourages continuous improvement of the codebase.
- "You know you are working on clean code when each routine you read turns out to be pretty much what you expected." Highlights the importance of readability and predictability.
Review Summary
קוד נקי מקבל בעיקר ביקורות חיוביות על עקרונותיו לכתיבת קוד קריא וניתן לתחזוקה. הקוראים מעריכים את העצות המעשיות בנוגע לשמות, פונקציות ובדיקות. המיקוד של הספר בשפת Java וכמה הנחיות מחמירות מדי הם ביקורות נפוצות. רבים רואים בו קריאה הכרחית למפתחים, אם כי ישנם כאלה שמוצאים אותו פחות מועיל למתכנתים מנוסים. המקרים הממחישים ודוגמאות הרפקטורינג זוכים לשבחים מכמה, אך אחרים מבקרים אותם כיותר מדי. בסך הכל, המבקרים מסכימים שהספר מציע תובנות יקרות ערך על איכות הקוד, גם אם לא כל ההמלצות ישימות באופן אוניברסלי.
Similar Books
