"כי זה ברור שלא".זו התשובה שאמורה הייתה עכשיו לצאת את גרונכם. מה הקשר בין מיוזעי-הידיים, חובשי הפלסטיק ומסובבי-המפות לבין אנשי המקלדת, רואי הצפונות, "סוף מעשה במחשבה תחילה" שכאלה? מסתבר שיש קשר...
בואו נתחיל מאיזה "אני מאמין" זריז - אי אפשר "לקבלן" עבודת פיתוח כי התוצאה הישירה של "שיטת" עבודה זו היא מספר נכויות לעתיד, כמו: קוד גרוע, יציבות רעועה של מוצר, תחזוקת קוד שתעלה בהמון שעות אדם וצמצום האפשרות לשימוש נוסף בקוד בצורה פשוטה ושקופה (מה קוראים האנשים reusable code).
ברגע שאתה מוצא עצמך, כמתכנת, מדלג על שלבים חשובים כמו Code Design, Code Review, ומאידך מוצא עצמך באופן די תכוף מבצע Re-Factoring לסוגיו, מתקן ריגרסיות וכיו"ב - דע לך שאתה נמצא בנחלת הקבלנים בין אם אתה אוהב את זה או לאו.
אני לא אומר שצריך לקודד עם ראייה עשור קדימה ולעשות Code Review לכל הגדרת משתנה, אבל אסור בא' הידיעה "לקבלן" פיצ'רים. אם אילו לקוחות שבאים עם הדרישה ל"עכשיו ומיד" אפשר להסביר להם שבכדי שמוצר יהיה יותר גמיש לדרישותהם העתידיות, עדיף לשלם עוד מעט זמן כעת, מאשר לשלם בגדול אח"כ. אם זו ההנהלה הדורשת זה הרבה יותר פשוט (או כך לפחות זה אמור להיות). יש להסביר כי קמצנות בזמן פיתוח היום תחזור כבומרנג מאוחר יותר. אין גם על מה להתווכח - זה בדוק, זה קורה, זו המציאות.
זה גם די נורא לראות קוד שהוא ה"בייבי" שלך מקבל טוויסט לצד המעוות והופך לערימה של כיסאות שבורים, המגדל של המלך צב-צב, שכולנו יודעים מה קרה לו בסוף (ומי שלא, בושה...).
מה שכן, אני יודע שאני מתאר כאן עולם די אוטופי, שהרי תמיד יהיו לקוחות גרידיים ותמיד תהיה הנהלה אטומה. מה עושים אם כן? אין לי ממש תשובה... זהו בהחלט דיון שאפשר לנהל פה. בינתיים כל שנותר לי להמליץ עליו הוא להוריד את כובע המגן הפלסטי שכופים עלינו ולהסביר לדורשים שתכנות זה מעט מעבר ל"צריך את הפיצ'ר הזה עד הזמן ההוא". בין אם הם יבינו או לא, זו כבר שאלה אחרת. מה שכן, תמיד צריך לזכור שלמרות שמתכנתים הם לא קבלנים, הם בהחלט פרוצות שילכו לכל המרבה בכסף :).
את זה תמיד טוב לזכור...
ברגע שאתה מוצא עצמך, כמתכנת, מדלג על שלבים חשובים כמו Code Design, Code Review, ומאידך מוצא עצמך באופן די תכוף מבצע Re-Factoring לסוגיו, מתקן ריגרסיות וכיו"ב - דע לך שאתה נמצא בנחלת הקבלנים בין אם אתה אוהב את זה או לאו.
אני לא אומר שצריך לקודד עם ראייה עשור קדימה ולעשות Code Review לכל הגדרת משתנה, אבל אסור בא' הידיעה "לקבלן" פיצ'רים. אם אילו לקוחות שבאים עם הדרישה ל"עכשיו ומיד" אפשר להסביר להם שבכדי שמוצר יהיה יותר גמיש לדרישותהם העתידיות, עדיף לשלם עוד מעט זמן כעת, מאשר לשלם בגדול אח"כ. אם זו ההנהלה הדורשת זה הרבה יותר פשוט (או כך לפחות זה אמור להיות). יש להסביר כי קמצנות בזמן פיתוח היום תחזור כבומרנג מאוחר יותר. אין גם על מה להתווכח - זה בדוק, זה קורה, זו המציאות.
זה גם די נורא לראות קוד שהוא ה"בייבי" שלך מקבל טוויסט לצד המעוות והופך לערימה של כיסאות שבורים, המגדל של המלך צב-צב, שכולנו יודעים מה קרה לו בסוף (ומי שלא, בושה...).
מה שכן, אני יודע שאני מתאר כאן עולם די אוטופי, שהרי תמיד יהיו לקוחות גרידיים ותמיד תהיה הנהלה אטומה. מה עושים אם כן? אין לי ממש תשובה... זהו בהחלט דיון שאפשר לנהל פה. בינתיים כל שנותר לי להמליץ עליו הוא להוריד את כובע המגן הפלסטי שכופים עלינו ולהסביר לדורשים שתכנות זה מעט מעבר ל"צריך את הפיצ'ר הזה עד הזמן ההוא". בין אם הם יבינו או לא, זו כבר שאלה אחרת. מה שכן, תמיד צריך לזכור שלמרות שמתכנתים הם לא קבלנים, הם בהחלט פרוצות שילכו לכל המרבה בכסף :).
את זה תמיד טוב לזכור...
3 comments:
תנסה לראות את הדברים מהצד השני.
לעיתים מזמין העבודה יודע את המגבלות הן בכסף והן בזמן ולוקח החלטה שאם צריך maintenence הוא ישלם בזמן. לא כל קוד צריך לעמוד בתנאים של N.A.S.A . כתבתי מספיק "דמואיים" שבסוף יצאו כמוצר.
כאשר המוצר מספק מספיק כסף אפשר לשפר.
צריך לזכור המוצר אינו הקוד של המתכנת, המוצר הוא דרישות הלקוח.
אתה צודק שמדובר במוצרים בסדרי גודל של "דמואים שיכולים לצאת כמוצרים".
אני מדבר בעיקר על אפליקציות - enterprise שאמורות מאוחר יותר לעשות אינטגרציה עם מוצרים שונים וטכנולוגיות שונות. מוצרים שהפיתוח שלהם נפרש על פני שנים ולא שבועות עבודה (לא שאני אומר שעל אלו אתה מדבר).
אני לא חושב שכל קוד צריך לעמוד בתנאי NASA (שבנינו, זה לא תנאים מי יודע כמה, ע"ע "מעבורות והתרסקויות"), אבל עדיין- הלקוח או ההנהלה לא תמיד מבינים את ההשלכות של Quick and Dirty, ואח"כ יש להם פרצוף של המפטי-דמפטי לאחר הנפילה.
I love the turtle!!Awesome stories for the whole family!
Post a Comment