כדי להיות מתכנת טוב, יהיה עליכם לעמוד במספר סטנדרטים מלבד כתיבת קוד.
בין השאר מצופה ממתכנת שידע גם לפתור בעיות מורכבות, שיוכל לעבוד בצוות בשיתוף פעולה ושהקוד שלו יהיה רלוונטי גם כאשר הוא יעזוב או יעבור לתפקיד אחר.
בפוסט הזה נתרכז בנושא איכות הקוד.
הקוד צריך להיות קריא וברור לאחרים. זה אומר תיעוד ברמת הפונקציה וברמת הקוד, אם יש צורך.
חלק יטענו שככל שהקוד יותר ברור, כך יש פחות צורך להסביר אותו בתיעוד.
הפונקציות צריכות להיות קצרות ככל הניתן וגנריות ככל הניתן כדי שיוכלו לטפל במספר רב של מקרים.
כפל קוד, מן הסתם, ידוע כמשהו שכדאי להמנע ממנו בכל מחיר.
האובייקטים צריכים להיות ממוקדים ולא להיות עמוסים ביותר מדי שורות קוד.
פונקציות או Class ארוכים הם סימן לכך שיש לפצל אותם למקרים פרטיים ולקרוא להם.
הטקסט צריך להופיע עם אינדנציות נוחות לקריאה.
הקוד צריך להיות כתוב מתוך מחשבה שבעתיד ירצו לשנות אותו. לשם כך הוא נדרש להיות בנוי כך שיהיה קל לתחזק אותו בעתיד. כמו למשל, להוסיף לו פונקציות או לחבר לו אובייקטים חדשים. אם הקוד מכיל קבצים ארוכים כאורך הגלות שקשה להבין את הקשר ביניהם - תוספת לקוד כזה תהיה סיוט.
במקרים מסויימים כדאי לבנות קודם תשתית Framework ולהשתמש בה בקריאות חוזרות. כך שינויים ב-Framework יתפסו עבור כל שאר הקוד.
"Magic Numbers" הם Big no no ומקור לבאגים.
בתוך קוד לא אמורה להיות השמה ישירה למספר כלשהו או ל-string מכיון שבפעם הבאה שהערך הזה יצטרך להשתנות, מישהו יצטרך לערוך חיפושים על כל הקוד כדי למצוא איפה השינוי נדרש או יותר גרוע, לשנות רק חלק מהמקומות.
במידה האפשר, עדיף להסתמך על ארגומנטים מפונקציות אחרות או מהמשתמש, גם אם זה כרוך בבדיקות תקינות של הערכים.
אם יש צורך במספר רב של השמות, עדיף לרכז את כולם במקום אחד בצורה נוחה.
זה יכול להיות בתוך מבני נתונים של קוד כמו אובייקטים או Lists או בתוך קבצי data כגון JSON או XML.
כל קוד כתוב צריך לעבור בדיקה. ברוב המקרים מצופה מהמתכנת לכתוב את הטסטים שיבדקו את הקוד שכתב.
זה יכול להיות asserts שבודקים תנאים בקוד וזורקים exceptions כאשר התנאים לא מתקיימים או פונקציות של unit test שיריצו בדיקות על הקוד בהתאם למה שהוא אמור לבצע.
מתכנת טוב יודע לכתוב מספיק unit tests שיבדקו את הקוד שלו ביסודיות מספקת. זה מפתח קריטי לאפשר שינויים גדולים בקוד מבלי לשבור אותו או לייצר באגים חדשים בתוך הקוד.
המהדרים יבצעו גם mocking לפי הצורך, כאשר מדובר בקוד המתקשר עם שירותים חיצוניים כמו web services.
לסיכום -
זהו הבסיס של הרעיון. הנושא נסקר בהרחבה באתרים ובלוגים בכל מיני רמות. החל מקונבציות שונות לבחירת שמות למשתנים ועד לפורמטים שונים של תיעוד.
בין השאר מצופה ממתכנת שידע גם לפתור בעיות מורכבות, שיוכל לעבוד בצוות בשיתוף פעולה ושהקוד שלו יהיה רלוונטי גם כאשר הוא יעזוב או יעבור לתפקיד אחר.
בפוסט הזה נתרכז בנושא איכות הקוד.
Readability
חלק יטענו שככל שהקוד יותר ברור, כך יש פחות צורך להסביר אותו בתיעוד.
הפונקציות צריכות להיות קצרות ככל הניתן וגנריות ככל הניתן כדי שיוכלו לטפל במספר רב של מקרים.
כפל קוד, מן הסתם, ידוע כמשהו שכדאי להמנע ממנו בכל מחיר.
האובייקטים צריכים להיות ממוקדים ולא להיות עמוסים ביותר מדי שורות קוד.
פונקציות או Class ארוכים הם סימן לכך שיש לפצל אותם למקרים פרטיים ולקרוא להם.
הטקסט צריך להופיע עם אינדנציות נוחות לקריאה.
Maintainability
במקרים מסויימים כדאי לבנות קודם תשתית Framework ולהשתמש בה בקריאות חוזרות. כך שינויים ב-Framework יתפסו עבור כל שאר הקוד.
"Magic Numbers" הם Big no no ומקור לבאגים.
בתוך קוד לא אמורה להיות השמה ישירה למספר כלשהו או ל-string מכיון שבפעם הבאה שהערך הזה יצטרך להשתנות, מישהו יצטרך לערוך חיפושים על כל הקוד כדי למצוא איפה השינוי נדרש או יותר גרוע, לשנות רק חלק מהמקומות.
במידה האפשר, עדיף להסתמך על ארגומנטים מפונקציות אחרות או מהמשתמש, גם אם זה כרוך בבדיקות תקינות של הערכים.
אם יש צורך במספר רב של השמות, עדיף לרכז את כולם במקום אחד בצורה נוחה.
זה יכול להיות בתוך מבני נתונים של קוד כמו אובייקטים או Lists או בתוך קבצי data כגון JSON או XML.
Testability
זה יכול להיות asserts שבודקים תנאים בקוד וזורקים exceptions כאשר התנאים לא מתקיימים או פונקציות של unit test שיריצו בדיקות על הקוד בהתאם למה שהוא אמור לבצע.
מתכנת טוב יודע לכתוב מספיק unit tests שיבדקו את הקוד שלו ביסודיות מספקת. זה מפתח קריטי לאפשר שינויים גדולים בקוד מבלי לשבור אותו או לייצר באגים חדשים בתוך הקוד.
המהדרים יבצעו גם mocking לפי הצורך, כאשר מדובר בקוד המתקשר עם שירותים חיצוניים כמו web services.
לסיכום -
זהו הבסיס של הרעיון. הנושא נסקר בהרחבה באתרים ובלוגים בכל מיני רמות. החל מקונבציות שונות לבחירת שמות למשתנים ועד לפורמטים שונים של תיעוד.
אין תגובות:
הוסף רשומת תגובה