איך לכתוב קוד נקי

הפיכת הקוד שלך לנקי ויפה היא דרך מצוינת לעמוד בזמנים. רוברט מרטין תקף את המסמר על הראש עם אחת מההצהרות החריפות שלו: "המדד האמיתי היחיד לאיכות הקוד הוא יחידת What-The-F**ks/Minute. ."" במקור). תן לי להסביר מה זה אומר. בכל פעם שאני סוקר קוד, המוח שלי עובר אחד משלושת הרגשות:

• "WTF?! מה לעזאזל?!" (בגועל) - זה לא זה... הכל רע מאוד....
• "WTF?! מה לעזאזל?!" (בהתפעלות) - הממ, בחור חכם עשה את זה!
• "WTF?! מה לעזאזל?!" (ברוגז) - סוג של בלבול, על מה אנחנו מדברים בכלל?!

אז מה חשוב ומה בדיוק אנחנו מעריכים כשאנחנו רואים קוד כלשהו? זהו: הטוהר והיופי שלו. היכולת לכתוב קוד נקי ויפה היא אינדיקטור של מפתח מקצועי ביותר. הכשרה במיומנות זו מבוססת על שני מרכיבים – ידע ועבודה. ידע מלמד אותך דפוסים, עקרונות, פרקטיקות, היוריסטיות. אתה צריך אותם כדי לצמוח מקצועית. רק אתה חייב לספוג את הידע הזה כמו ספוג באמצעות תרגול מתמיד ועבודה קשה. בקיצור, כתיבת קוד נקי היא לא קלה. זו עבודה קשה וקפדנית, ואתה תצטרך לעבוד בה קשה. באמצעות ניסוי וטעייה, תשתפר על ידי חזרה על אותם שלבים שוב ושוב עד שתמצא את הפתרון הרצוי. פשוט אין דרך פשוטה יותר. להלן כמה טיפים שיעזרו לך ללמוד איך לכתוב קוד נקי.

מה בשם

קנדריק למאר (אמן היפ-הופ אמריקאי - הערת העורך) ציין פעם במדויק: "אם אני הולך לספר את הסיפור האמיתי, אני צריך להתחיל עם השם שלי". השמות בפיתוח תוכנה נמצאים בכל מקום. אנו שמות פונקציות, מחלקות, ארגומנטים, חבילות, תוכניות - הכל. אנו שמות קבצי מקור וספרי עיון וכל מה שקשור אליהם. אנחנו שמות דברים בלי סוף, וזה הופך לחלק קריטי בעבודה ליצירת קוד נקי. השם שאתה נותן למשהו צריך לשקף את הכוונה. למצוא שם טוב זה לא קל, זה לוקח זמן, אבל זה גם חוסך הרבה זמן כשצריך להתמודד עם הקוד והמצב מסתבך. אז היזהר מהתהליך הזה ואל תפחד לשנות שמות מאוחר יותר אם תמצא משהו מתאים יותר. כל מי שעוסק בקוד שלך יהיה אסיר תודה לך.

"פונקציה אחת" - דבר אחד

לואי הנרי סאליבן (אדריכל אמריקאי רציונליסט ומודרניסטי) אמר פעם: "הפונקציה קובעת את הצורה . " הוא אמר את זה על אדריכלות הבתים, אבל זה לא משנה את המהות. כל מערכת בנויה על שפה ספציפית לתחום שמתכנתים יוצרים כדי לתאר אותה במדויק. פונקציות פועלות כפעלים של השפה, וכיתות הן שמות עצם. לרוב, פונקציות הן ערך עליון בארגון של שפת תכנות, וכתיבתן נכונה היא המהות של יצירת קוד טוב. ישנם רק שני כללי זהב לכתיבת פונקציות איכותיות:

1. הם צריכים להיות קטנים
2. הם חייבים לעשות דבר אחד, משימה אחת, ולעשות אותה היטב

כלומר, הפונקציה שלך צריכה להיות קטנה ולא צריכה להכיל מבנים מקוננים. לפיכך, רמות הזחה של הפונקציה לא צריכות להיות יותר מאחת או שתיים. גישה זו הופכת את הקוד להרבה יותר קל לקריאה, הבנה והבנה. בנוסף, עלינו להיות בטוחים שהביטויים בתוך הפונקציה נמצאים באותה רמת הפשטה. ערבוב רמות הפשטה בתוך פונקציה תמיד יוצר הרבה בלבול ובסופו של דבר מוביל לקוד בלתי ניתן לניהול. המתכנתים הטובים ביותר מתייחסים לפונקציות כאל סיפורים שיש לספר, לא רק לקוד לכתוב. הם משתמשים בכלים של שפת התכנות שבחרו כדי ליצור גוש קוד עשיר, אקספרסיבי ונקי יותר שיכול למעשה לשמש כמספר סיפורים נהדר.

"תגובות לא מפצות על קוד גרוע"

ונוס וויליאמס, טניסאית אמריקאית ואלופה חמש פעמים בווימבלדון, הכתה את המסמר בראש כשאמרה: "כולם עוזבים את ההערות שלהם. כך מופיעות שמועות " . הערות הן כמו חרב פיפיות. הערה ממוקמת היטב היא דבר שימושי מאוד. מצד שני, שום דבר לא מבלבל מקום יותר מהערות קלות דעת וחסרות תועלת. אבל ההערות המזיקות ביותר הן אלו שמפיצות מידע מוטעה ושקרים. בקיצור, הערות הן סוג של רוע הכרחי. לא תמיד, אבל לרוב. למה? זה פשוט, ככל שההערה ישנה יותר, כך קשה יותר לתחזק אותה, ורוב המתכנתים, כידוע, לא תמיד משנים הערות יחד עם שינויים בקוד. הקוד זז ומתפתח. חלקים מהקוד מוזזים קדימה ואחורה, אך אין הערות. וזה הופך לבעיה!

"עיצוב קוד הוא תמיד בראש סדר העדיפויות"

זה נאמר על ידי לא אחר מאשר רוברט סי מרטין (רוברט ססיל מרטין), הלא הוא הדוד בוב, מפתח, מחבר ספרים רבים על פיתוח תוכנה, יועץ, מחבר שותף של המניפסט Agile, וכן הלאה. והוא הוסיף: "עיצוב קוד הוא סוג של תקשורת. ותקשורת היא בראש סדר העדיפויות של כל מפתח מקצועי". אין לזלזל בהצהרה לעיל, כי היא מדברת על אחד המאפיינים החשובים ביותר של מפתח מעולה. קוד מעוצב מאפשר לך להסתכל עמוק לתוך המוח שלך. אנחנו רוצים להרשים אנשים עם הניקיון שלנו, תשומת הלב לפרטים הקטנים, היכולת לארגן ולהביע את המחשבות שלנו בצורה ברורה. אבל אם, כאשר אנשים מסתכלים על הקוד, הם רואים איזשהו בלבול, שמזכיר ויניגרט, ללא התחלה או סוף, זה שולל את המאמצים שלך ומוריד את המוניטין של המפתח. אל תטיל בכך ספק! אתה רחוק מאוד מהאמת אם אתה חושב שהעיקר בעסק הזה הוא ש"הקוד פשוט עובד". ככל הנראה הפונקציונליות שתיצור היום תשתנה במהדורה הבאה, אך הקריאות של הקוד לא תשתנה. סגנון הקוד וקריאותו הטובה מקלים על תחזוקת הקוד לאורך זמן, גם לאחר שהקוד המקורי שונה ללא הכר.

ראשית צור בלוק "נסה-לתפוס-סוף סוף".

ז'ורז' קנגווילהם (היסטוריון של המדע, פילוסוף) ציין בצדק: "לעשות טעויות זה טבעי לאדם, אבל להתעקש על טעויות זה מהשטן . " פתרון בעיות הוא משהו שכל המתכנתים עושים. נתונים לא חוקיים עלולים להיכנס לקלט והתקנים עלולים להיכשל. וכמפתחים, אנחנו צריכים לוודא שהקוד עושה את מה שהוא אמור לעשות. הבעיה היא לא רק טיפול בשגיאות, אלא טיפול בשגיאות "נקי וקל לקריאה". תוכניות רבות מסתגלות לטיפול בשגיאות. אם אתה עושה זאת, הכל יורד לכאוס כזה שהמטרה וההיגיון של הקוד הראשי נהרס. זה לא בסדר, זה לא צריך להיות ככה. הקוד צריך להיות נקי ואמין, וטיפול בשגיאות צריך להיות שזור בצורה חלקה וטבעי בקוד. זהו אינדיקטור של מתכנת ברמה גבוהה. ואחת הדרכים להשיג זאת היא באמצעות קינון נכון וכיסוי של כל השגיאות בבלוקים של תפיסת נסיון. בלוקים אלה מגדירים את היקף הקוד שלך. כאשר אתה מבצע קוד בחלק ה-try של בלוק try-catch-finally, אתה מצהיר שהביצוע יכול לבטל בכל עת ואז להתחדש ב-catch. לכן, אנו ממליצים להתחיל עם try-catch-finally כשאתה כותב קוד. זה יעזור לקבוע למה המשתמש יכול לצפות מהקוד, ללא קשר למה שמשתבש בקוד במהלך הניסיון.

בואו נסכם את זה

ביטוי אחד יוצא דופן יעזור לנו לסכם את כל האמור לעיל. זהו חוש קוד או "תחושה של קוד משותף", מעין מקבילה של מתכנת לשכל הישר. במילותיו של רוברט מרטין: "כתיבת קוד נקי דורשת שימוש שיטתי בטכניקות קטנות רבות, המיושמות כתוצאה מתחושת "ניקיון" מדוקדקת ומעט כואבת. הטכניקות הקטנות הללו נקראות ביחד קוד-חוש . " לחלקנו יש "חוש קוד צליל" זה מההתחלה, בעוד שאחרים צריכים לפתח אותו באמצעות תרגול מתמיד. אינסטינקט זה עוזר לא רק לזהות את ההבדל בין קוד רע לטוב, אלא גם עוזר ביצירת אסטרטגיות שמטרתן להפוך קוד רע לטוב. קוד גרוע הורס הכל. אם כבר מדברים בצורה פיגורטיבית, אם אתה מקפיא את העוגה הכי טעימה עם חרא של כלבים, אז... אה... כמעט אף אחד לא יאהב את זה. חוש קוד עוזר למתכנת להשתמש בכלים הנכונים כדי להשיג את מטרתו ליצור קוד נקי. מתכנת שמבין מהו חוש קוד הוא אמן שיכול ליצור יצירת אמנות על מסך ריק שתיזכר לשנים רבות. כפי שסיכם זאת הרולד "הל" אבלסון, פרופסור למדעי המחשב ב-Mit ומנהל מייסד של Creative Commons וקרן התוכנה החופשית: "יש לכתוב תחילה כדי שאנשים יוכלו לקרוא אותן, ולאחר מכן כדי שיוכלו להיות הוצא להורג." מכונית" . מה אתה יכול לקרוא בנושא: "מדריך לאומנות תוכנה זריזה" - רוברט מרטין. "מדריך לאומדן זריז" - מייק קון על המחבר: רבי שנקר רג'אן הוא מנהל תוכניות IT גלובלי ממומבאי (הודו). בלוגר מפורסם, משורר הייקו, חובב ארכיאולוגיה וחובב היסטוריה. אתה יכול להתחבר אליו בטוויטר , בינוני , לינקדאין