תורגם לעברית על-ידי אודי אשכנזי ונערך על-ידי חן שפירא.
הומר לשקפים (עם מעט עריכה ותיקונים) על-ידי שלומי פיש.
1. האם שמעתם על SEMA?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
האם שמעתם על SEMA? זו מערכת אזוטרית למדי למדידת האיכות של קבוצות תכנה.
לא, עצרו! אל תלחצו על קישור זה! ייקח לכם בערך שש שנים להבין אותו.
לכן המצאתי מבחן משלי, מאוד לא אחראי, דווקא רשלני במיוחד, במטרה למדוד את האיכות של קבוצות תכנה. החלק הכי טוב בו הוא שהוא לוקח בערך שלוש דקות. בזמן שתחסכו, תוכלו ללמוד רפואה.
2. מבחן יואל
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
האם אתם משתמשים במערכת בקרת תצורה (Source Code Control)?
האם אתם מסוגלים לבנות גרסה בצעד אחד?
האם אתם בונים גרסה כל יום?
האם יש לכם בסיס נתוני באגים?
האם אתם מתקנים באגים לפני כתיבת קוד חדש?
האם יש לכם לוחות זמנים מעודכנים?
האם יש לכם מפרט (Spec)?
האם יש למתכנתים סביבת עבודה שקטה?
האם אתם משתמשים בכלים הטובים ביותר שניתן לקנות?
האם יש לכם בודקים?
האם מועמדים לעבודה כותבים קוד בזמן הראיון?
האם אתם מבצעים בדיקות שימושיות ב"מסדרון"?
2.1. האם אתם משתמשים במערכת ניהול גרסאות?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
השתמשתי במערכות מסחריות, והשתמשתי ב- CVS, שהיא בחינם, ואני אומר לכם, CVS היא בסדר גמור.
אבל אם אין לכם מערכת ניהול גרסאות בכלל, תתאמצו מאד לגרום למתכנתים לעבוד כקבוצה.
המתכנתים לא יודעים מה עמיתיהם עשו. לא ניתן לסגת משגיאות בקלות.
הערה: קיימות כבר מערכות ניהול גרסאות מתקדמות יותר מ-CVS. יואל למשל כבר עבר להשתמש ב-Subversion.
2.2. האם אתם מסוגלים לבנות גרסה בצעד אחד?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
כלומר: כמה צעדים נדרשים על מנת לבנות מוצר מושלם מתמונת קוד עדכנית?
בקבוצות טובות, קיים תסריט יחיד אשר מביא את כל הקוד ממערכת ניהול הגרסאות "מנקי", בונה מחדש כל שורת קוד, מכין את כל ה-EXE, בכל התצורות, שפות וצירופי ifdef#, ויוצר את חבילות ההתקנה והמדיות הסופיות.
אם התהליך מורכב מיותר מצעד אחד, הוא נוטה לשגיאות.
ככל שמתקרבים למועד ההספקה, רוצים מחזורים מהירים של תיקון הבאג "האחרון", בניית ה- EXE הסופי וכו'.
אם נדרשים 20 צעדים לקמפל את הקוד, הרצת כלי בניית ההתקנה וכדומה, אתם הולכים להשתגע ולעשות שגיאות טיפשיות.
2.3. האם אתם בונים גרסה בכל יום?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
כאשר עובדים עם מערכת ניהול גרסאות, לפעמים מתכנת מכניס בטעות משהו ששובר את הגרסה.
למשל, הוא הוסיף קובץ חדש לתכנה, והכל מתקמפל מצוין על המחשב שלו, אבל הוא שכח להוסיף את הקובץ החדש למערכת ניהול הגרסאות.
שבירת הגרסה זה דבר כל כך רע (וכל כך נפוץ) שכדאי לבנות גרסה כל יום על מנת לוודא שדבר זה לא יקרה בלי שישימו לב אליו.
בקבוצות גדולות, דרך טובה לוודא תיקון מיידי של תופעות אלו היא לבנות גרסה כל יום בצהריים, למשל בזמן האוכל. כל אחד מכניס את מה שהוא יכול לפני האוכל. כשחוזרים מהאוכל, הגרסה בנויה.
אם הכל עבד, יופי!
אם הבניה נכשלה, מתקנים את הבעיה, אבל כולם יכולים להמשיך לעבוד עם הגרסה התקינה (הקודמת) של הקוד, מלפני הבניה.
בקבוצת ה- Excel, היה לנו כלל שמי ששבר את הגרסה קיבל "עונש" לפקח על בניית הגרסאות עד שמישהו אחר שבר אותה.
זה היה תמריץ טוב מדוע לא לשבור את הגרסה, ודרך טובה להעביר את כולם דרך תהליך בניית הגרסאות כך שכולם ידעו איך זה עובד.
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
הגרסה הראשונה של Word for Windows נחשבה פרוייקט "מצעד המוות".
הוא לקח נצח.
הוא נדחה עוד ועוד.
הקבוצה כולה עבדה שעות מטורפות והפרויקט נדחה שוב ושוב והלחץ היה נוראי.
כאשר הדבר הארור נגמר שנים מאוחר יותר, מיקרוסופט שלחה את כל הקבוצה לנופש בקאנקון, וישבה לעשות חשבון נפש רציני.
מה שהסתבר היה, שמנהלי הפרויקטים לחצו כל כך לשמור על לוח הזמנים, והמתכנתים פשוט מיהרו ופיתחו קוד גרוע במיוחד, מכיוון שתיקון באגים לא היה חלק מלוח הזמנים הרשמי.
הסיפור מספר על מתכנת אחד, שהיה צריך לכתוב פונקציה לחשב את גובהה של שורת טקסט, וכתב בפשטות ";return 12" וחיכה לדיווח באג.
בניתוח לאחר המוות, קראו לכך "מתודולוגיית אינסוף באגים".
כדי לתקן בעיה זו, מיקרוסופט אימצה שיטה הקרויה "מתודולוגית אפס באגים".
"אפס באגים" משמעו שבכל נקודת זמן, העדיפות הגבוה ביותר היא לתקן באגים לפני שכותבים קוד חדש.
באופן כללי, ככל שמחכים יותר זמן לפני שמתקנים באג, העלות (בזמן וכסף) לתקנו גבוהה יותר.
סיבה נוספת הקשורה לעובדה היא שיותר קל לחזות כמה זמן ייקח לפתח קוד חדש מאשר לתקן באג קיים.
אם יש לכם לוח זמנים והמון באגים פתוחים לתיקון, לוח הזמנים אינו אמין.
אבל אם תיקנתם את כל הבאגים הידועים , וכל מה שנותר הוא קוד חדש, לוח הזמנים יהיה מדויק יותר באופן מפתיע.
דבר נהדר נוסף בהקפדה על אפס באגים הוא שניתן להגיב במהירות רבה יותר לתחרות.
מתכנתים אחדים מכנים זאת שמירה על מוצר מוכן להספקה בכל רגע נתון.
אם המתחרה מציג תכונה נהדרת חדשה אשר גורמת לאובדן לקוחות, תוכלו לממש רק את תכונה הזו ולשחרר את המוצר מיידית, ללא צורך לתקן כמות גדולה של באגים צבורים.
2.6. האם יש לכם לוחות זמנים מעודכנים?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
מה שמביא אותנו לנושא לוחות הזמנים.
אם הקוד שלכם בכלל חשוב לעסק, קיימות סיבות רבות מדוע חשוב לדעת מתי הוא יהיה מוכן.
מתכנתים ידועים לשמצה על גישתם השלילית לקביעת לוחות זמנים.
"זה יהיה מוכן כאשר זה יהיה מוכן!" הם צועקים על אנשי העסקים.
לרוע המזל, זה פשוט לא מספיק טוב.
יש יותר מדי מאמצי תכנון שהעסק חייב לבצע זמן רב לפני אספקת הקוד: הדגמות, תערוכות, פרסום וכו'.
הדרך היחידה לעשות זאת היא על ידי הגדרת לוח זמנים, ושמירה על עדכניותו.
הסוגיה העקרונית הנוספת בהקפדה על קיום לוחות זמנים הוא שהיא מאלצת אתכם להחליט אילו תכונות במוצר אכן ימומשו, ולבחור את התכונות הפחות חשובות ולחתוך אותן ולא להידרדר ל- featuritis (הידועה גם כזחילת התכולה).
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
בספרות מתועדות תוספות פריון רבות שניתן להשיג על ידי מתן תנאי סביבה, שקט ופרטיות לעובדים.
הספר הקלאסי Peopleware בנושא ניהול תכנה סוקר תרומות אלו ביסודיות.
והנה הבעיה. אנו יודעים שעובדים באופן הטוב ביותר על ידי כניסה "לרצף", הידוע גם כלהיות "מרוכזים", ואז הם מתמקדים בעבודתם באופן מלא ומאבדים כל קשב לקורה סביבם.
הם מאבדים את תחושת הזמן ומייצרים תפוקה נהדרת דרך כוונה מושלמת.
זה העיתוי בו העבודה הפורה ביותר קורה.
סופרים, מתכנתים, מדענים ואפילו שחקני כדורסל יספרו לכם על "רצף".
הבעיה היא שהכניסה לרצף אינה קלה. כאשר מנסים למדוד אותה, נראה כי לוקח 15 דקות בממוצע להגיע לפריון מלא.
לעתים, אם אתם עייפים או שעשיתם כבר עבודה יצירתית רבה באותו יום, פשוט אינכם יכולים להתרכז ואתם מבזבזים את יתרת היום בלהסתלבט, לשוטט ברשת או לשחק טטריס.
הבעיה הנוספת היא הקלות שבה יוצאים מרצף.
רעש, שיחות טלפון, הליכה לאכול צהריים, הצורך לנסוע 5 דקות להביא קפה והפרעות מעובדים אחרים - בייחוד ההפרעות מעובדים אחרים - כולם מוציאים אותכם מרצף.
אם עובד אחר שואל אותכם שאלה, וגורם לכם להפרעה של דקה, אבל מוציא אותכם מרצף כך שלוקח לכם חצי שעה נוספת לחזור אליו, הפריון הכולל שלכם בבעיה רצינית.
2.9. האם אתם משתמשים בכלים הטובים ביותר שניתן לקנות?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
כתיבת קוד בשפה הדורשת קומפיילר היא אחד הדברים שעדיין לא ניתן לבצע בקלות על מחשב ביתי ממוצע. אם הקומפילציה לוקחת יותר ממספר שניות, השגת המחשב הכי חדש וחזק יחסוך לכם זמן. אם הקומפילציה לוקחת 15 שניות, המתכנתים ישתעממו בזמן שהמחשב רץ ויעברו לקרוא את The Onion, מה שישאב אותם פנימה ויהרוג שעות של פריון.
תיקון קוד GUI במערכת עם מסך אחד הוא דבר כואב עד כדי בלתי אפשרי. אם אתם כותבים קוד GUI, שני מסכים יהפכו את הדברים לפשוטים הרבה יותר.
מתכנתים רבים נאלצים בסופו של דבר להתעסק בגרפיקה לצורך אייקונים או סרגלי כלים, ולרובם אין עורך גרפי טוב בהישג יד. הניסיון להשתמש ב- Microsoft Paint לצורך זה הוא בדיחה, אבל זה מה שרוב המתכנתים נאלצים לעשות.
בעבודתי הקודמת, האדמיניסטרטור חזר ושלח לי תזכורות אוטומטיות שהתלוננו על כך שאני משתמש ביותר מ ... החזיקו חזק ... 220 מגהבייט של נפח אכסון על השרת.
הצבעתי בפניו על כך שבמחירי הכוננים הקשיחים היום, עלות נפח אכסון זה קטנה משמעותית מעלות נייר הטואלט בו אני משתמש.
בזבוז של יותר מ- 10 דקות על ניקוי הספרייה שלי יהיה בזבוז מדהים של פריון.
קבוצות פיתוח מעולות לא מענות את המתכנתים שלהן. אפילו תסכולים קטנים הנגרמים מכלים חלשים מצטברים, וגורמים למתכנתים להיות ממורמרים ומתוסכלים. מתכנת מתוסכל הוא מתכנת לא פורה.
בנוסף על כל זאת, מתכנתים משוחדים בקלות על ידי הדברים הכי חדשים ומגניבים. זה אפילו זול משמעותית ממתן משכורות תחרותיות על מנת להביא אותם לעבוד אצלכם!
2.10. האם יש לכם בודקי-תכנה?
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
אם אין לכם בקבוצה בודקים ייעודיים, לפחות אחד לכל שניים שלושה מתכנתים, אתם מספקים מוצרים מלאי באגים או שאתם מבזבזים כסף על ידי שימוש במתכנתים שעלותם 100$ לשעה לעשות עבודה שיכולה להתבצע על ידי בודקים ב- 30$ לשעה.
התקמצנות על בודקים היא חשבון כלכלי כל כך עקום שאני פשוט לא מסוגל להבין מדוע אנשים נוספים לא מבחינים בכך.
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.
ניתן לעבור לשקף הבא על-ידי המקשים "N" ו-"P".
האם תשכרו לעבודה קוסם מבלי שתבקשו ממנו להראות לכם מספר תרגילי קסם? בוודאי שלא.
האם תשכרו קייטרינג לחתונה שלכם מבלי שתטעמו את האוכל? אני בספק. (אלא אם כן זו הדודה רבקה, והיא תשנא אתכם עד קץ הדורות אם לא תתנו לה לעשות את הכבד הקצוץ המפורסם שלה.)
למרות זאת, בכל יום, מתכנתים מתקבלים לעבודה על בסיס קורות חיים מרשימים או כי המראיין נהנה לשוחח עימם. או ששואלים אותם שאלות טריוויה ("מה ההבדל בין CreateDialog ו-DialogBox?") אשר ניתן לענות עליהן על ידי הסתכלות בתיעוד.
לא אכפת לכם אם הם שיננו אלפי טריוויה על תכנות. אכפת לכם האם הם יודעים לכתוב קוד.
לחליפין, אפילו יותר גרוע, הם נשאלים שאלות "אהה!": סוג השאלות אשר נראות פשוטות אם יודעים את התשובה, אבל אם לא יודעים אותה הן בלתי אפשריות.
בבקשה, הפסיקו לעשות זאת. עשו מה שתרצו במהלך הראיון, אבל בקשו מהמרואיין לכתוב קצת קוד.
אפילו אם יכולות תכנון ממשקי המשתמש שלכם טעונות שיפור, כל עוד תקפידו לבצע מבחני שימושיות במסדרון, אשר אינם עולים מאומה, ממשק המשתמש שלכם יהיה טוב הרבה יותר.
3. תודה!
כדי לעבור לנקודה הבאה או הקודמת בשקף יש ללחוץ במקלדת על החיצים שמאלה וימינה.