הבלוג של ינון פרק

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

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

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

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

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

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

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

יצירת אבסטרקציה בקוד שפותרת בצורה אלגנטית בעיה היום עלולה להיות Premature Optimization בגלל שאולי איתה יהיה לנו קשה להתמודד עם דרישות חדשות בעתיד.

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

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

בשורה התחתונה המפתח להבנה מהו Premature Optimization יהיה בחינת העלות של הפיצ'ר או המנגנון, כולל עלות הפיתוח או התחזוקה של אותו פיצ'ר, והאם התמורה שאקבל מאותו פיתוח שווה את המחיר.

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

ברוב המקרים זה לא נגמר טוב.

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

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

היום אני חושב שיש דרך טובה יותר.

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

1. ללמוד תכנות לבד מהאינטרנט פעם בשבוע, בקטנה.

2. לבנות לעצמך משהו שמעניין אותך, גם אם זה ייקח המון זמן.

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

4. לקחת את הלימוד בפרופורציה, לפחות עד שנהיה בטוחים.

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

"בלתי אפשרי" או "אני לא יכול לדמיין את זה"?

רעיונות בלתי אפשריים שווה לזרוק ולהפסיק לחשוב עליהם.

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

טיפ לחיים - בואו נעלה את רף ההוכחה לפני שמכריזים על רעיון "בלתי אפשרי". רוב הזמן "אני עדיין לא מצליח לדמיין את זה" יעבוד טוב יותר.

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

1. בדיקות עוזרות לבוס שלי להרגיש טוב.

2. בדיקות עוזרות לי להבין את הבעיה טוב יותר לפני שמתחיל לכתוב קוד.

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

4. בדיקות שומרות עליי מטעויות טפשיות שאעשה בעתיד שישברו מנגנונים שבניתי.

5. בדיקות מאפשרות לי לפתח פיצ'רים חדשים מהר יותר כי הרצת הבדיקות מהירה יותר מהרצת המערכת בסביבה האמיתית.

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

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

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

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

דרק סיברס אמר Hell Yeah Or No והרבה זמן שמעתי אותו אבל בראש שלי זה היה Hell Yeah or Not Now. אבל האמת שה No של דרק הרבה יותר עוזר לפוקוס. לא רוצה? תמשיך הלאה, מכל הלב. ההמתנה להזדמנויות טובות יותר רק מבלבלת.

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

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

האיש שחילק הוראות לא עצר לשאול אם מותר לו להגיד לי מה לעשות.

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

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

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

(ואם לא רודף אחריך נמר? נו תסמכו על המוח שלכם שימציא מספיק נמרים דמיוניים שרודפים אחריכם כדי שאף פעם לא יהיה משעמם).

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

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

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

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

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

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

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

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

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

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

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

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

1. באיזו תדירות אני מעביר או מקבל הערות ששינו את ה Design של הפיצ'ר בצורה משמעותית?

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

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

אם תהליך ה Code Review שלכם לא עובד טוב כמו שהייתם רוצים אל תתביישו לשנות אותו. מעבר לעומק על PR אחד בחודש נותן יותר ערך ממעבר חטוף על שלושה PR-ים כל יום.