לפני כשמונה שנים כשהתחלתי את דרכי בעולם התכנות ניסיתי למצוא דרכים שונות על מנת להשתפר במקצוע אותו בחרתי.
הכיוון הראשון לפיתוח העצמי היה לימוד של טכנולוגיות חדשות, קריאה של אתרים בתחום הפיתוח כגון javaworld,theserverside, בהם מרבית הדיונים היו סביב טכנולוגיה – framwoek,feature ...
כישורי המתכנת נעים על צירים שונים של ידע:
טכנולוגיות, ארכיטקטורה,מתודולוגיות,הכרות עם השפה,כלים (בקרת תצורה,כלי קומפילציה, IDE...), Design ...
מרבית המתכנתים שמים את הדגש ההתפתחותי שלהם על הכרות עם טכנולוגיות נוספות. טכנולוגיות מככבות במודעות הדרושים והןמילות המפתח אותן מחפשות חברות ההשמה ולכן מתכנתים רבים שמים דגש על הרחבת הטכנולוגיות שקיימות באמתחתן. מקום שלא יספק למתכנת התנסות עם מגוון טכנולוגיות מאבד את כושרו למשוך אליו מתכנתים חדשים ולשמור קיימים.
אך אם נסתכל על מה שמרכיב את רוב זמן עבודתנו נראה כי אחוז שולי של הזמן מוקדש עבור שימוש בטכנולוגיות וב – third parties למינן ואילו למעשה תשעים אחוז של הזמן מוקדש לכתיבה של קוד סטנדרטי, אינטגראלי מהשפה שאמור להוציא לפועל רעיון עסקי.
מתי הקדשתם זמן לשפר את איכות כתיבת הקוד שלכם, ברמת המיקרו הנמוכה ביותר?
בכתיבה של קוד קריא, בשימוש נכון של OO...
הפוסט הזה לא יסקור טכנולוגיה חדשה או השוואת ביצועים. הפוסט הזה יוקדש לבסיס. אז " שלום כיתה א " קחו טוש , דף ציור וצבעי גועש והנה אנחנו מתחילים.
נניח שניגש אליכם עמית לעבודה ופונה אליכם עם המשפט הבא:
“Spouse of me this night today manufactures the unusual meal in a home. You will join?”
אתם יכולים להסיק 3 דברים:
1. הוזמנתם לארוחת ערב
2. צפוי לכם תענוג קולינארי
3. אנגלית היא לא שפת האם של העמית שלכם
במבחן התוצאה – התוצאה הושגה, המסר הועבר.רק שהדרך בה הועבר לא הייתה הדרך הסטנדרטית.
כאן מדובר במסר פשוט למדי, אבל מה קורה כאשר המסר הוא מאות או אלפי שורות , האם אז יוכל אדם , שמכיר המילים בשפה, אבל אינו " דובר השפה " להעביר את המסר על כוונתו המקורית ומבלי לגרום להתפוצצות וורידים במוח של חברו בשעה שזה ממלמל לעצמו על הזמן - WTF.
על מנת לדעת להשתמש בשפה עלינו לדעת:
1. מבנה השפה -דקדוק
2. אוצר מילים
3. כיצד נהוג ודרכים יעילות להגיד דברים
פוסטים שלמים שכתבתי באנגלית , עברו במאה אחוז את מבחן " בודק האיות " של Microsoft, אך אדם דובר אנגלית לא הבין על מה דברתי (אישית במקרה שלי זה אשמתם, האנגלית שלהם התרחקה מאוד מהאנגלית התקנית, להלן האנגלית שלי).
עלינו לדעת כיצד לחבר את המילים ולהעביר את המסר בצורה האפקטיבית ביותר לקורא.
בתור מתכנתי Java כולנו יודעים את מבנה השפה ואוצר המילים שקיימים בשפה, אך האם אנו יודעים להעביר את המסר בצורה יעילה. האם כאשר אנו קוראים קוד של אחרים (כמובן לא את שלנו J ) אנו מנסים שעות להבין מה אמור להיות כאן?
לפני למעלה מ-30 שנה הגו Yourdon and Constantine את המודל הבא ביחס לעלות תוכנה:
המחיר הכולל = מחיר פיתוח + מחיר תחזוקה
מחיר תחזוקה = מחיר הבנת הקוד הקיים + מחיר השינוי + מחיר בדיקה + מחיר deploy.
את רוב זמננו בתור מתכנתים אנו "מבלים" על קריאת והבנת קוד קיים. קיימת משמעות רבה לכתיבת קוד ברור, שיעביר את מטרתו בצורה היעילה והקלה ביותר.קריאה של קוד דומה בקצת למשחק " מלך הטריויה (Jeopardy) " , משחק שבו צריך המתמודד לנחש מה הייתה השאלה על פי "התשובות" אותו אומרים לו העמיתים, כך גם בקוד אנו מנסים להבין דרך הקריאה מה הייתה מטרת הכותב.
אם כן כיצד כותבים קוד יעיל?
לצערי קיימת התייחסות מועטה בספרות לרמת המיקרו, אך מספר ספרים בתחום זה אכן עושים את העבודה.
אפתח בספר "Effective Java" http://java.sun.com/docs/books/effective/, הספר נכתב על ידי Joshua Bloch , שקיום עובד עבור Google ובמשך שנים רבות עבד ב- sun והיה אחראי על כתיבת חלק מהספריות המוכרות כל כך לכולנו .הספר נכתב בהשראת ספר דומה בc++ בעל מבנה ומטרה זהה.הספר כבר הספיק לצאת במהדורה שנייה. לדעתי , הספר הינו ספר חובה הספר הינו חלק מהותי מארגז הכלים למתכנת וראוי מדי פעם לשוב ולקרוא בו.
Joshua Bloch לטעמי הינו אחד האנשים המעניינים בתחום ה- java והרצאות שלו מככבות בכנסי ה- javaone וכן חיפוש של "effective java" ב- youtube יוביל אתכם למספר הרצאות מענייניות שלו.
שני ספרים נוספים שלמעשה יצאו באותה תקופה וחולקים ביניהם נושאים משותפים הם הספרים :
1. Clean code , http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 , הספר נכתב על ידי Robert C. Martin , שהינו נשיא של חברת הייעוץ object mentor , שמומלץ לכם לבקר באתר שלהם - http://www.objectmentor.com/resources/omi_reports_index.html
2. Implementation-Patterns' , http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091, נכתב על ידי kent Beck, שהוא הכותב של Junit , ואיש java מאוד מעניין.
בדרך כלל מבואות ניתנים בסוף, כחלק אגב של הסקירה. בסקירה הזאת המקורות הן העיקר ואם עצרתן כאן דיינו.
אבל למי שעדיין כוחו בעיניו אנחנו ממשיכים.
אם אתם מתפלאים כי הזמנה חביבה שלכם לגברת שמולכם בסגנון "לטס גו ביץ", מזכה אתכם בסטירה , זה הזמן שלכם להירשם לבית ספר לשפות AAA, ככה זעקה פרסומת לפני שנים לבית ספר ללימוד שפות.
ידע המילים, ידע התחביר אינו מספק. יש גם לאגד את הדברים האלה בקונטקסט הנכון, בהיגוי הנכן, כדי להעביר את המסר בצורה יעילה ובטח שקהל היעד שלכם מבזבז את זמנו בעיקר על קריאה של דברים שכתבתם אי שם בשעה 2 לפנות בוקר , ברגע האחרון לפני שהגרסה נארזת ללקוח.
אם כן אז איך מדברים effective java ?
הדבר הראשון – שמות שמות שמות שמות ושוב שמות.
מתכנת מדי רגע צריך לתת שם , שם למשתנה חדש, שם למתודה, שם למחלקה, שם לpackage ...
השמות שתתנו יעזרו מאוד לבאים אחריכם לקרוא ולהבין את מה שכתבתם.
מתכנת שקורא קוד מתחיל מלמעלה למטה ואינו חפץ לקרוא כל שורה ושורה של קוד. מתן שמות נכונים ל – Packages ישמש אותו כמעין תוכן עניינים מוגדר ויעזור לו להבין היכן לחפש את מבוקשו, לכן אל תתקמצנו על היררכיית ה- packages והגדרתן בשמות ברורים.
תוך כדי קריאה של קוד פניה ל-class ששמו מוגדר וברור תחסוך מאיתנו את הצורך לצלול לתוכו על מנת להבין את ייעודו.
כנ"ל לגבי שמות משתנים ושמות מתודה.
אל תהיו קמצנים עם השמות , זה בסדר לתת שמות ארוכים , אך לא דומים אחד לשני , כי אז ייווצר בלבלול , שיצביעו על מטרת המשתנה, מחלקה ...
מכאן אתם ברשות עצמכם, אתם מוזמנים לקרוא את הספרים האלו. את מרבית ההמלצות שם כבר יישמתם לבד, רק שעכשיו הם כתובים בצורה יותר מסודרת.
הערה לסיום:
אל תניחו את האמירה הביקורתית בצד בזמן שאתם קוראים את הספרים האלה. לא כל מה שכתוב שם חייב להיות נכון. נסו אתם לשים את עצמכם בכל דילמה שמוצגת שם בצד הקורא את התוכנה ואת התוכנה שלכם, לא את הדוגמאות קוד הפשטניות שנהוג להציג בספרים ונסו לחשוב האם האמירה נכונה עבורכם או שבעולם התוכנה שלכם ראוי ליישם את הדברים אחרת.
אני אישית מצאתי כמה דברים שאיני מסכים איתם , אך עם הרוב אני מסכים ובכלל באופן כללי הדבר החשוב כאן הוא הניסיון לכתוב תוכנה כל הזמן מנקודת המבט של מי שעתיד לקרוא אותה או לדבג אותה שנים אחריכם, שכבר שכחו מה בכלל היו הדרישות.
עולם התוכנה הוא לא תמיד עולם מדעי ולא כל המלצה נכונה בכל מקום או בכל מקרה. לעניות דעתי אין דבר כזה קוד מושלם באופן אבסולוטי, או עקרונות מושלמים, שיקול הדעת הוא חשוב.
רשימות נוספות לקריאה:
אין תגובות:
הוסף רשומת תגובה