ניתוח מטלת קידוד מראיון עבודה

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

התוכנית הינה מורכבת מפנייה למאגר נתונים , ניהול טופס וכד לא משהו לא שיגרתי  (לדוגמא ניהול תור של סדרן של תחנת מוניות ) כאשר הטכנולוגיות בהן המעומד יכול להשתמש הינן פתוחות לגמרי כל שפת תכנות שהיא  החל מ  Cobol  , turbo c  וכלה ב groovy  , כל טכנולוגית ui  שהוא ירצה :Wpf , QT , MFC  וכל סוג מאגר נתונים שהוא ירצה (כבר נתקלתי במועמד שהשתמש ב Neo4j ולקח את הפתרון לכיוון מאוד יפה ) כמובן אם מועמד ינסה לפתור את הבעיה תוך שימוש ב Hbase  אני ארים גבות ככה שיונית לוי תוכל רק לקנא .

בסה”כ לא היו הרבה מועמדים שהשתמשו בטכנולוגיות איזוטריות רובם פתרו את התרגיל או ב #C עם sql server  או בjava אפשר היה לספור על יד אחת את אילו שפתרו את התרגיל ב python , ruby וכד

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

כאשר אני בודק את התרגיל שמועמד קודד אני שם דגש על הדברים האילו :

Maintainability

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

שמות של משתנים :

Foreach ( var next in myList)

לאומת

Foreach ( Taxi nextTexyWaitingInLine in mTexiesInLineList)

שמות של פונקציות

פונקציה ששמה מתחיל  ב Get  או ב Check  לא יכולה לבצע שינוי state  .

GetNoOfWatingTexiesInLine לדוגמא יכולה לשמש רק לצורך הבאת מספר המוניות בתור .אסור לה להציג התראה שאין אף מונית יותר בתור.

שם של פונקציה אמור לשקף את מה שהיא עושה   .

פונקציה בשם UpdateTime  ב class  : של Taxi מה תפקידה בכח ????

לאומת UptadeTaxiArrivalToLineTime

אני פחות שם דגש על תעוד של הקוד כי זה שבר שכל מעומד ירצה להרשים באמצעותו

האם המועמד הינו מפתח תוכנה או סתם code monkey?

המנעות מGOD anti pattern - כלומר חלוקה גרנולרית של התוכנית ל class ים במידה הנכונה. לא סתם class של Taxi שמכיל את כל ה state וה logic בתרגיל אלא חלוקה נכונה של הפתרון ל class ים .לדוגמא class של תחנה שמכיל reference לqueue של ה מוניות .וחשיבה יוצרת של שאלות כדוגמת איזה Entity צריך לענות : איזה מונית הבאה בתור לקבל נסיעה ?

כאשר מועמד שמציג פיתרון מבוסס על Domain driven design  עם כל הפינוקים של הפרדה בין entities  , values  ו services  , שיכבת applicaition  שמתזמרת את שיכבת ה Doamin  וכד מקבל בונוס שמן.

Cohesion גם ברמת הפונקציה וגם ברמת הclass , class בשם Helper שמכיל פונקציות ללא כל קשר בניהם הינה דוגמא קיצונית לכך .

הקפדה על עקרונות : Dry , KISS וYAGNI – האם צריך שTaxi ירש מCar שתירש מvehicale ? (מי צריך או אי פעם יצטרך את זה )

עקרונות solid בעיקר SRP

מתי משתמשים ב function ומתי ב property ב class .

 

הקפדה על קוד יציב וחזק

הבנה היכן פונקציה יכולה להיכשל וטיפול נכון בכישלון אפשרי .

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

Logging !!!

מועמד אשר מצרף unit test  מקבל אצלי נקודות זכות .

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