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

מקום שלישי - מהדר Microsoft C

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

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

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

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

הלקח נלמד

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

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

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

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

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

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

מקום שני: פרסום ברשתות חברתיות

כשעבדתי בגוגל על ​​פרסום ברשתות חברתיות (זוכרים את Myspace?), כתבתי משהו כזה ב-C++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

הלקח נלמד

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

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

זה מה ש לאמר על תומס ווטסון, ראש יבמ האגדי:

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

ווטסון שאל מה השתבש.

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

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

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

מקום ראשון: App Inventor API

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

כמה שיותר גרוע יותר טוב

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

איך זה צריך להיות: העיצוב צריך להיות פשוט ביישום ובממשק. פשטות הממשק חשובה יותר מפשטות היישום.

כמה שיותר גרוע, יותר טוב: העיצוב צריך להיות פשוט ביישום ובממשק. פשטות היישום חשובה יותר מפשטות הממשק.

בואו נשכח מזה לרגע. לצערי, שכחתי מזה שנים רבות.

ממציא אפליקציות

כשעבדתי בגוגל, הייתי חלק מהצוות ממציא אפליקציות, סביבת פיתוח מקוונת לגרור ושחרר למפתחי אנדרואיד שאפתנים. זה היה 2009, ומיהרנו לשחרר את גרסת האלפא בזמן כדי שבקיץ נוכל לקיים כיתות אמן למורים שיוכלו להשתמש בסביבה בעת לימוד בסתיו. התנדבתי ליישם ספרייטים, נוסטלגי לאופן שבו נהגתי לכתוב משחקים ב-TI-99/4. למי שלא יודע, ספרייט הוא אובייקט גרפי דו מימדי שיכול לנוע ולקיים אינטראקציה עם רכיבי תוכנה אחרים. דוגמאות לספרייטים כוללות חלליות, אסטרואידים, גולות ומחבטים.

הטמענו App Inventor מונחה עצמים ב-Java, אז יש שם רק חבורה של אובייקטים. מכיוון שכדורים וספרייטים מתנהגים בצורה מאוד דומה, יצרתי מחלקה מופשטת של ספרייט עם מאפיינים (שדות) X, Y, Speed ​​​​(מהירות) ו- Heading (כיוון). היו להם אותן שיטות לזיהוי התנגשויות, הקפצה מקצה המסך וכו'.

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

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

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

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

סוף סוף תיקנתי את הבאג הזה רק לאחרונה, עשר שנים מאוחר יותר. "תוקנו", לא "תוקן", כי כפי שאומר יהושע בלוך, ממשקי API הם נצחיים. לא הצלחנו לבצע שינויים שישפיעו על תוכניות קיימות, הוספנו את המאפיין OriginAtCenter עם הערך false בתוכניות ישנות ו-true בכל התוכניות העתידיות. משתמשים עשויים לשאול שאלה הגיונית: מי בכלל חשב למקם את נקודת ההתחלה במקום אחר מלבד המרכז. למי? למתכנת אחד שהתעצל ליצור API רגיל לפני עשר שנים.

לקחים

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

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

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

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

מסקנה

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

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

מקור: www.habr.com