הקרב בתעשיית התוכנה: Development vs. Marketing

הקרב בין מחלקת השיווק ([1]Marketing) למחלקת הפיתוח מתנהל כבר שנים, במשך דורות, אבות ובנים. אלה רוצים \"עוד פיצ\'רים ומהר\" אלו רוצים \"איכות, דיוק ושיטתיות\" (ע\"פ המפתחים. אנשי שיווק יספרו את הסיפור קצת אחרת). נקודת ההכרעה אינה נראית באופק.

האם זה קרב מחוייב המציאות? האם לא ברור שהפעם \"אנחנו\" צודקים?

שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ\'רים על חשבון איכות, מה אתה אומר לו?

תשובה פופולארית בקרב כמה אנשי פיתוח יכולה להיות: \"בלי דיבורים: אוחז בחפץ כהה וחובט בו. מטמין את הגופה בירקון. PM טוב הוא PM… שמעדיף איכות\"
תשובה קצת יותר מכובדת היא \"אם רוצים פיצ\'ר נוסף יש לבטל פיצ\'ר קיים או להאריך את הגרסה בזמן הנדרש, זמן פיתוח לא גדל על עצים, ועל איכות לא מתפשרים\".
התשובה שלי דווקא היא זו: \"זה לא ויכוח ביני לבין הPM. זו שאלה ארגונית שהארגון צריך לענות עליה\"
באופן אישי אני אעדיף להילחם על האיכות, אך אני מנסה להתעלות לפעמים על הנטייה הטבעית – ולראות את התמונה הכוללת. אם הארגון בוחר באיכות אז בוודאי יהיה קל לחזור לאופצייה מס\' 2.

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

Best Practices: פיתוח כנגד שיווק

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

DRY – אל תחזור על עצמך
Bake Quality In – איכות צריכה להיות בכל שלב בתהליך
Abstraction / Loose Coupling – צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
Naming / Clean Code – קוד \"ספרותי\" שמתאר את עצמו.
וכו\'

אנשי השיווק העתיקו מאיתנו, המפתחים, את הרעיון של Best Practices ויצרו רשימה משלהם. הנה כמה הרלוונטיים לדיון:

רגל בדלת
בניגוד לקונוטציה האגרסיבית של \"לדחוף את הרגל\" כדי לחסום דלת נסגרת (שמתאימה לתיאור של איש מכירות אגרסיבי במיוחד), \"רגל בדלת\" לרוב מתייחס לצורה המנומסת (האמריקאית אולי) של נקודת הכניסה לבית הלקוח. במקום לשאול: \"האם אתם רוצים לקנות שואב אבק חדש?\" יפתח איש המכירות בשאלה \"האם גם לכם האובך האחרון לכלך את הבית?\" – שאלה תמימה ולא מחייבת. \"כן בוודאי – פשוט נורא\" המשכתם, פתחתם את הדלת לרווחה ואפשרתם לאיש המכירות לחצות פיסית את קו הדלת ולהניח שם רגל. הקרבה המעטה הזו (והכניסה בהסכמה למרחב האישי שלנו) היא כבר נקודת פתיחה טובה בהרבה להצעה עסקית.
באופן דומה אנשי שיווק ירצו שתספקו להם פיצ\'ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר \"גם לך יש בעיות ABC\"? \"יש לנו דווקא משהו מעניין לדבר עליו\" – יפתחו דיון עם לקוח שזקוק לפ\'יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי\'צר כמו שצריך [2].

Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ\'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): \"The Suite Always Wins\". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר – יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג (\"One Stop Shop\") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני (\"Suite\").

ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ\'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) – זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ\'יצר X) – קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ\'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ\'יצרים במקום להתבונן על התמונה השלמה.

Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP – Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות \"יש\"/\"אין\" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ\'יצר שמוגדר כקריטי – יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו\'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו \"אין לו מספיק ידע\" כי \"צריך ידע ב CSS\" או CSS3 או XHTML (מול HTML – הבדל סמנטי) וכו\'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ\"כ נכונים על מנת להגיע למראיין המקצועי (כלומר – טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.

באופן דומה מנהלי מוצר רוצים להציג רשימה ארוכה של יכולות במוצר. לעיתים הם יאתרו פ\'יצרים שאותם לקוחות מבקשים אבל אף פעם לא משתמשים בהם. כיצד ייתכן שלקוח דורש פ\'יצר שהוא לא מתכוון להשתמש בו?

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

פי\'צר כזה מסומן כ Check-box Feature – תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון \"בטח – גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ\'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה – חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ\'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ\'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).

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

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

אנחנו בפיתוח מעדיפים לדייק בפרטים ולא \"לנפח\". אנו נעדיף לקרוא לאובייקט \"SnmpMessage\" ולא \"SystemWellBeingReport\" (קצת מוגזם – לא?). אנו נעדיף \"XmlParser\" ולא \"Cross-SystemTranslator\". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. \"הם חיים בעננים\" אנו מספרים על אנשי השיווק, \"רואים סרטים בעננים\", מוסיפים. קרוב לודאי שהסבר כמו \"הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים\" רק מעצים את תחושת הניכור.

סיכום
טעות נפוצה היא לחשוב ש\"המוצר מוכר את עצמו\" או ש\"מספיק מוצר טוב\". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות \"טיפש\" (או \"לא רציונלי\") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב – ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק – כ 40-60% מהתקציב. לא סתם.

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

בתחומים שבהם איכות היא חיונית להצלחה עסקית (למשל מכשור רפואי, ניהול כספים) – תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה (למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [5], מה שנקרא Compliance) – תהיה איכות נמוכה יותר [6].
הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם, והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).

אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות – אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ\'יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע\"י הלקוח. \"המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות\" הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ\'יצרים?

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

תודה לניר דרמר על ההערות המועילות על הפוסט.

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

[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד – אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.

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

[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.

[5] לדוגמא, כשאתם עושים ביטוח לרכב ומבקשים מכם לבדוק את האזעקה, אתם רק רוצים לקבל את האישור. האזעקה רק עצבנה והטרידה וכבר שמעתם סיפורים שהיא לא כ\"כ יעילה. מבחינת רבים מאיתנו עדיף שיתנו לנו אישור ושהאזעקה לא תפעל יותר לעולם. כמה הקפדה אתם צופים מיצרן האזעקות שנזרק מלקוחות כי המוצר שלו פעל מספר רב מדי של פעמים? בעיקר הקפדה שהאזעקה לא תפעל לשווא – אני מאמין.

[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל\"מהי איכות\". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.

Performance: דחיינות = מקצוענות?

הפוסט עודכן ב 16/10

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

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

הקדמה

פעם, עבדתי עם מתכנתת שקיבלה הערות על מסמך Design שכתבה ונראתה פגועה: \"כתבו לי שה-Design שלי ילדותי\". מה?? שאלתי – תראי לי. קראתי את ההערה והיא הייתה: \"premature optimization\".

Premature Optimization

\"Premature Optimization\" למי שלא הבין אינה קשורה לילדותיות, אלא לאופטימיזציה שלא הגיעה זמנה. הזקנים שביננו שלמדו פיתוח בשפת C יכולים עוד לזכור את הסנסיי (במקרה זה מרצה מזדקן למדעי המחשב שעסק במקור במתמטיקה) סופר לנו כל ביט וכל פעולת if. \"מה?, כתבת x/4? ברור ש x*0.25 זה מהיר יותר. בכלל הייתי מצפה ל x>>2\" – הם הכו בנו תורה (סלחו לי אם השיפט הוא לכיוון ההפוך, מרגיז אותי בכלל לבדוק).

בשנות השבעים, שהמחשב ביצע מאות פעולות בשנייה – הייתה לאופטימיזציה כזו חשיבות. טראומת הקוד-הלא-אופטימלי היה כ\"כ קשה שעד היום יש זכר לצלקות (במיוחד באקדמיה).

כיום, מחשב ביתי ממוצע מכיל 2 או 4 ליבות, בקצב של לפחות 2 מיליארד פעולות בשנייה (Ghz), עם instruction-set (כגון MMX או SSE – אליהם ניתן לגשת בעזרת ספריות מיוחדות בשפת C) שמבצעים פעולות ארוכות ומסובכות בצורה יעילה יותר. רק אזכיר שהיום לכל מחשב חדש יש גם (GPU – Graphical Processing Unit) אותו כרטיס גרפי שמובנה בלוח האם, בתוך ה CPU או על לוח נפרד. יחידות עיבוד אלה בנויות לביצוע פעולות מתמטיות פשוטות במקביליות גבוהה ויכולים להציג כח חישוב מפחיד.

דוגמא טובה לשימוש אינטנסיבי במעבד היא פיצוח ססמאות. הרי ממשלות, משטרות (וארגוני פשע) בונים מחשבי על בכדי לפצח מסרים מוצפנים של אוייביהם. בימנו המאיצים הגרפיים (GPU) התקדמו כ\"כ עד שהם מאפשרים פיצוח סיסמאות בקצב מהיר פי 20 – בעזרת חומרה במחיר זהה. בשל הכניסה של תכנות ל GPU לשימוש**, המליצו כבר גופי אבטחה לחייב את המשתמשים בסיסמא מינימלית באורך 12 תווים. אויי לא!

למה לעשות אופיטמיזציה?

אז מה ניתן להסיק? שחשיבה על יעילות היא לא חשובה? כן – ולא.

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

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

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

תחום הדפדפנים החל ברצינות באמצע שנות התשעים – כלומר, ידע רב הצטבר בתחום בחמש עשר השנים האחרונות.
אני זוכר מקרה שבו אפליקציית web שכתבנו הייתה איטית להחריד. לדף מלא לקח 56 שניות (!) לעלות על reference client hardware, שהיתה מכונה חלשה מהרגיל כדי לייצג את המשתמש עם המחשב שמיושן. המעבר מ explorer 6 ל explorer 7(שאז היה חדש) שיפר את טעינת הדף לפחות מ 12 שניות. מקור הבעיה היה קובץ javascript גדול במיוחד. ניתוח מקיף הראה שאספלורר 6 ביזבז יותר מ 40 שניות על פיענוח (parsing) של הקובץ בעוד מנוע פיענוח חדש באספלורר 7 הוריד את הזמן לשניות בודדות (הנה דוגמא לסדרי גודל).

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

הנה התבוננו במספרים מתוך מבחני ביצועים של האתר הראוי Tomshardware. המבחן בחן דפדפנים שונים על חומרה זהה שבבסיסה מעבד i7-750.

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

הנה פיירפוקס 3.6 וכרום 10 ו אקספלורר 9 (מרס 2011) מול פיירפוקס 7, כרום 14 ואקספלורר 9 עם מספר עדכונים (ספטמבר 2011). מוצרים לא לגמרי חדשים, שנוצרו ע\"י טובי המהנדסים:

הרצת JavaScript במבחן Kraken 1.1

מהההה???

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

הנה עוד מבט, כמה אפשר עוד לשפר ממוצר קיים ובוגר את זמן העלייה (startup time)?

בחצי השנה הזו Chrome הצליח להוריד את זמן העליה מ6 ל2 שניות – שליש מהזמן המקורי (תוך כדי שיפורים בזמן טעינת הדף) וגם Opera הותיק הציג שיפור חסר תקדים. שאר הדפדפנים נותרו עם 4 עד 5 שניות (בחומרה הנ\"ל).

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

http://www.tomshardware.com/reviews/internet-explorer-9-chrome-10-opera-11,2897-5.html

http://www.tomshardware.com/reviews/firefox-7-web-browser,3037-5.html

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

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

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

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

עוד נקודה היא קריאות הקוד: קוד אופטימלי הוא לרוב פחות קריא. נקודה זו רק מחזקת את הנקודה הקודמת – לא ארצה להשקיע בקריאת קוד קשה לקריאה במשך זמן פיתוח רק בכדי לגלות שהמוצר לא מעניין.
נקודה חשובה אחרונה היא עקרון פארטו שמתאר יפה מאוד את תחום הביצועים התוכנה: 80 אחוז מהשיפורים יושגו ב 20 אחוז מאזורי הקוד. אולי אפילו יותר. להשקיע ולהקשות את הקוד לקריאה ב 100% מהאזורים של הקוד – זו פשוט השקעה לא משתלמת. וב Performance כמו ב Performance יש תמיד הפתעות. שיפור במקום אחד יכול לפתוח מספר צווארי בקבוק ולהשיג שיפור משמעותי מאוד בעוד ששיפור אחר שנראה נהדר על הנייר לא ישפיע כ\"כ בפועל כי הקוד ייתקע במקום אחר. חשוב מאוד לבצע pilots של שיפורים ולעשות profiling שוב ושוב בתצורות שונות בכדי להבין את התנהגות ביצועי המערכת.

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

** כדי להשתמש ביחידות אלה יש לכתוב קוד ל instruction-set מיוחד, כגון CUDA. עקרון זה של כתיבת קוד כללי ל GPU נקרא GPGPU.

*** במקור המילה Hacker הייתה תיאור כבוד יקר-ערך. האקרים היו אותם מומחי מחשבים, יחידים במינם, שהבינו לעומק את ה Linux Kernel, דקויות של פרוטוקולי תקשורת וידעו לכתוב קוד יעיל שמתקיים על כמעט-אפס זיכרון או פעולות מעבד. מאז מחולקים באינטרנט כלים אוטומטים לפירוק אתרי-ענק לגורמים, שלא דורשים יותר מהקלדת כתובת ה IP של הקורבן. ההאקרים קראו למשתמשים אלו Script Kiddies בקול מלא בוז – אך השם לא כ\"כ תפס. על כל האקר אמיתי שמפצח פירצה וכותב ספרייה לנצל אותה, יש עשרות אלפי Script Kiddies שזכו בתהילה. טננבאום, ה\"אנלייזר\", הוא דוגמא טובה. עצוב.

בורסת הטכנולוגיה: איך מחליטים על השקעה בתחום לא מוכר?

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

כיצד אנו בוחרים ספריה/טכנולוגיה/מתודולוגיה?

אנשים טכנולוגיים נוטים להתבונן על הטכנולוגיה בפרטים:

איך ה Design או הארכיטקטורה של הספריה?
באיזו שפת תכנות היא כתובה? (חשוב!) "מה, בBoo? כנראה שאלו חבר'ה מביני עניין! אני כבר מחבב אותם"
איך נראים ה API?
כמה קצר ומרשים ה tutorial שאיתו אוכל להתחיל ולהתשמש בה (טעות אנושית נפוצה היא להניח שאם אפשר להרים Hello World בפחות מדקה, אנו עתידים לשבוע נחת מהספרייה…)
לבדוק את ה Roadmap ופ'יצרים עתידיים.

מתכנתים קצת יותר מנוסים יביטו על עוד כמה הבטים:

תיעוד ארכיטקטורה – כמה ברור מה קורה בפנים ואיך הספריה עובדת?
adoption וה community – האם נראה שהספריה תתמך עוד זמן רב או שהיא בנסיגה? כמה פעילות יש בפורומים?
בחינת רשימת הבאגים במערכת ניהול הבאגים (אם היא ציבורית) ולקבל מושג על רמת האיכות ואיזה סוג בעיות יש.
בחינת ה release notes האחרונים, כמה הם תכופים (כמה מהר נקבל עדכונים חשובים) וחיפוש אחר סימנים מעניינים. לדוגמא: ספריית client side שמדווחת על תמיכה ב windows 7 מעלה סימן שאלה על התלות ולמה רק עכשיו? דיווח על תיקון באג ב authentication ב SAML2 על Firefox יכול להיות סימן לבגרות. הכל כמובן תלוי ב context.

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

לשלוח מישהו שעליו סומכים עליו לעשות את הבדיקה (עדיף שזה יהיה אדם מנוסה)
שימוש בקשרים להשגת references חיים (כלומר מישהו שאפשר לתשאל אותו) – חשוב להתייחס לכל פידבק בהקשר הנכון.
Benchmarking – "אתה אומר ש Haskell שפה נהדרת, אך אף אחת מהחברות בתחום שלנו לא עובדת בה. זה גם נכון לחברות בתחומים דומים".
"היא שפה נהדרת" יענה המתכנת הנבון והצעיר "אתה יודע כמה בינוניות יש בתעשיה – זה שאחרים לא משתמשים בה לא אומר שומדבר".
"לא נראה לי" – סביר שתהיה החלטת המנהל, וכנראה בצדק [א]. הוא לא יודע כלום על Haskell, אבל מגמת התעשייה מכילה ידע שאלה האדם הבודד יכול להגיע רק לאחר חודשים ארוכים. אי הליכה בתלם משמעותה גם פחות Eco-System לעבוד איתו, כמובן (אפרט יותר בפוסט המשך).
חיפוש ובחינת נקודות מפתח מנחות – מה מאפיין את שפת Haskell? משולבת בעיקר באוניברסיטאות? (נאמר, אני לא יודע באמת). מה ניתן ללמוד מכך – מה מאפיין אוניברסיטאות?

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

בעיית חוסר היכולת להכנס לפרטים אינה חדשה. איזה פתרון יצר עולם ההשקעות לחוסר ההבנה של לקוחותיו? – אנליסטים! אותם מומחים שאומרים לנו "לקנות לקנות" או "למכור למכור" ואפילו קצת השתכללו עם השנים ועתה הם קובעים מחיר יעד למניה "לאחר הכניסה לשוק הזימבבואי, על מנת לשקף את שווי השוק האמיתי, מניית נייס צריכה להגיע למחיר של 23 דולר ו 14 סנט בדיוק!" [ב].

אנליסטים של עולם התוכנה

כמו שלשוק המניות יש אנליסטים שמסכמים כמות אדירה של נתונים להמלצה פשוטה, כך לשוק התוכנה יש את האנליסטים שלה. החברות המוכרות הן Gartner ו Forrester וקצת מאחור IDC ו Altimeter Group. תוצאות מחקרי השוק שלהן עולות אלפים רבים של דולרים למחקר ומכסים תחומים רבים, בעיקר ב IT. הרבה ביקורת קיימת על מחקרים אלו, אך רוב החברות בגודל בינוני-ומעלה עובדות לפחות עם אחד מהגופים הללו. אם תבדקו במחלקת ה PM רוב הסיכויים שתגלו שיש להם (או יש להם גישה) לחומר כתוב ויכולת לקבוע פגישת יעוץ עם אנליסטים מאחת מהחברות הנ"ל.

מצד שני יש את דו"ח הטכנולוגיה של חברת ThoughtWorks שמחולק בחינם ומכסה מספר מצומצם של טכנולוגיות, אך מתוך הכרות אינטימית של מובילים טכנולוגיים שהשתמשו בטכנולוגיות אלו בפועל. דו"ח זה נקרא Technology Radar והוא מיועד יותר למנהל הפיתוח / ארכיטקט / מנהל בכיר ופחות ל Marketing. תוכלו למצוא בדו"ח זה סיכום על מצבן על טכנולוגיות, כלים ומתודולוגיות כגון OAuth, HAML, DevOps או ESB. הדו"ח מדבר על מגמות ולא נכנס לפרטים. סקירת הדו"ח יכולה להיות מקור טוב לקבלת החלטות (אם הטכנולוגיה עליה אתם חושבים מכוסה) או לעקוב אחר טכנולוגיות וטכניקות חדשות שצוברות תאוצה.

קישור לדו"ח ה Technology Radar (מומלץ)

—

[א] באותה לוגיקה (לכאורה) יכול מנהל להחליט לזנוח SCRUM ולעבור לפתח ב Waterfall "כי שבעים אחוז מהתעשייה לא טועה" או להסיק שאין סיבה לא לפתח בקובול, "שפה מוכחת ורצופת הצלחות עסקיות". גם Benchmarking צריך להעשות נכון, קרי – להביט על מגמות ולעשות השוואות רלוונטיות.

[ב] האם האנליסט באמת יודע מה קורה בחברת נייס? הוא ניזון בעיקר ממסרים אופטימיים שמייצרת מחלקת יחסי הציבור של נייס. האם הוא מכיר את הלקוחות? טיפה. משוחח איתם פה ושם. וזימבבואה? הוא מצא אותה על המפה (אם הוא אנליסט טוב) וקרא כמה סקירות של… איך לא? אנליסטים אחרים שכתבו על השוק הזימבבואי. בערך2 כפול בערך3 = בערךבערך6, וככל שכמות המשתנים הלא מדוייקת גדל… כך התוצאה הסופית פחות מדוייקת.

איכות תוכנה – ארגז כלים (3)

המשך ל פוסט 2: איכות תוכנה – ארגז כלים

מחפשים כיצד לשפר את איכות התוכנה ומחפשים אחר ה Best Practices בתעשייה?

בטבלה למטה ריכזתי את הטכניקות העיקריות שעברו את מבחן ההוכחה בתעשייה. ציינתי גם התייחסות כמה אתם יכולים לצפות לשיפור באיכות הפנימית (IQ – Internal Quality) או החיצונית (EQ – External Quality). אנשים לדוגמה מופתעים ש Unit Tests לא תופס הרבה באגים – אבל זו עובדה מוכרת. לעומת זאת טכניקות כמו Code Inspection ו TDD פחות מוכרות ברחבי התעשייה – אבל מניסיוני הן אפקטיביות ביותר. שימו לב שהטכניקות הקלות יותר להטמעה הן אלו שנפוצות בקרב האירגונים – זה דבר טבעי.

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

בתחתית הטבלה ציינתי עוד כמה נקודות חשובות.

טכניקה	השפעה על איכות חיצונית EQ	השפעה על איכות פנימית IQ	כמות השקעה	קושי הטמעה	הערות
תהליכים – לרוב קורים לפני או בזמן הפיתוח. לא מסכנים את הקוד. יעילים בצורה מפתיעה.
CI	לא רלוונטי	בינונית	נמוכה	נמוך	הרצת בדיקה ואינטגרציה בצורה אוטומטית מיד אחרי כל שינוי קוד ולא בסוף גרסת הפיתוח. נקודת פתיחה טובה ובסיס לבדיקות רגרסיה.
Bug Tracking	גבוהה	נמוכה	נמוכה (לארגון)	נמוך	מעקב יסודי אחר כמות הבאגים וקצב הפתיחה / סגירה.עם המדידה באים הלחצים והרעיונות לשיפור. הכרחי!
Requirements Inspection & verification	גבוהה	עקיפה בלבד	בינונית	בינוני	לעתים קרובות לא נעשה או נעשה בצורה חפיפה. הכוונה להשקעה יסודית בבחינת ואימות הדרישות.
Formal Design Inspection	נמוכה	גבוהה	בינונית	גבוה	לעתים קרובות לא נעשה או נעשה בצורה חפיפה. בחינת אלטרנטיבות אמיתיות וסיבות על כל שינוי מהותי במערכת שנבע אפילו מתיקן באג – לא אותם מסמכים שמתארים את המובן מאליו מתובל ב interfaces וקוד!
Formal Code Inspection	גבוהה	גבוהה	בינונית	בינוני עד גבוה	קריאה אינטנסיבית של קוד ללא מחשב + דיון. זהו לא ה freestyle Code Review שעושים לעתים בארגונים.
Peer Review	נמוכה	בינונית	נמוכה	נמוך עד בינוני	ישיבה עם מתכנת או ראש צוות עד רבע שעה לפני check-in
בדיקות רגרסיה – מגבירים את הביטחון והיכולת לבצע refactoring בבטחה. כיסוי גבוה נדרש להשגת האפקט.
Unit-Tests	נמוכה	בינונית	גבוהה	גבוה	לכל class בקוד – בדיקה. נכתב ע\"י המפתח. קשה מאוד להטמעה בקוד שנכתב ללא unit tests
Integration / Component Tests	בינונית	נמוכה	בינונית	בינוני	בדיקה ל flow בקוד שכולל מספר classes. נכתב ע\"י המפתח.
Acceptance Tests	בינונית	זניחה	בינונית	בינוני עד גבוה	בדיקת black box למערכת עצמה, הזרקה של input ובדיקת התוצאות. נבדק לעתים קרובות ע\"י \"צוות אינטגרציה\"
GUI Tests	בינונית	זניחה	גבוהה	בינוני	בדיקת ה UI ע\"י כלים שמדמים browser (כמו Selenium). בדיקות קשות לתחזוקה אך הדרך האוטומטית לבדיקת GUI.
TDD	זניחה	גבוהה	בינונית	בינוני	טכניקה משופרת לכתיבת unit-test, משפר את המודולריות בקוד, יעילות כתיבת הבדיקות וכתיבת בדיקות יציבות יותר. כיף חיים!
אחרים
Risk-Based Testing	גבוהה	זניחה	גבוהה	נמוך	צוות QA שעובד בצורה נבונה ומתמקד בבדיקת הפונקציות החשובות והמורכבות של המערכת
Testing Tools	נמוכה	זניחה	בינונית	נמוך	השקעה בכלי עזר שיעזרו למפתחים ו QA לבדוק מהר יותר וטוב יותר. מאפשר למפתחים לבדוק יותר ולהתעייף פחות.
Stress Test	נמוכה	זניחה	בינונית	גבוה	העמדת המערכת בעומס גבוה לראות מה נשבר ראשון. לרוב מגלה מספר מצומצם של בעיות, אך בעיות שהיו קורים אצל לקוחות.
Alpha / Beta Test	בינונית	זניחה	נמוכה	גבוה (מחוץ לפיתוח)	להגיע ללקוח מהר עם מוצר לא גמור ולבדוק את המוצר אצלו ובעזרתו. מסייע לאימות Requirements שיכול להיות קריטי להצלחת המוצר!
Static Code Analysis	בינונית	נמוכה	נמוכה	נמוך	כלים אוטומטים שמנתחים את הקוד למצוא בעיות. PMD, Find bugs ו CheckStyle הם המפורסמים בג\'אווה, כאשר יש כלים כמו Sonar או פלאג-אינים כמו QA Plug שמרכזים את כולם ביחד.

להוסיף (חשוב!): Eat your own dogfood

עוד כמה הערות:

Formal code / design / requirement inspection – כמו שניסיתי לציין בטבלה יש הרבה ארגונים שעושים חלק מזה, אבל בצורה לא יסודית ולא יעילה. ראיתי המון מסמכי designs בחיים שחבל שנכתבו. הרבה ישיבות design או requirements review שהיו ריקות מתוכן כי לאלו שאמורים לעשות את הביקורת לא היה ידע מספק \"לעשות את העבודה\". לסיכום: קל ליפול בטכניקות הללו לביצוע בינוני בלי לשים לב.

בדיקות רגרסיה
הסוגים השונים של הבדיקות הן לא כ\"כ אלטרנטיבות אחת לשנייה, אלא יותר משלימות. רגרסיה טובה כוללת הרבה unit-tests, מספר לא מבוטל של integration ו acceptance tests ומעט GUI Tests (פרמידת הבדיקות). פוסט טוב שמסביר קצת יותר ניתן למצוא כאן.

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

כלי ניתוח קוד סטטים – הכלים הנ\"ל כוללים המון חוקים מיותרים. חשוב לסנן את החוקים החשובים ולהתמקד בהם, אחרת הדו\"חות המופקים יכולים להיות מטרד לא קטן –

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

בהצלחה!

איכות תוכנה – סוגי איכות (2)

המשך לפוסט ראשון בסידרה: איכות תוכנה – היכן מתחילים?

מחלקים איכות ל2 היבטים עיקריים:

(External Quality (EQ – איכות חיצונית, כל מה שמפריע ללקוח / משתמש. ניתן למדוד ע\"י מספר קריאות ה \"?!WTF\" בשנה שבוקעות מגרונם של לקוחות או משתמשים ברחבי העולם. לרוב הליקויים האלו יתבטאו בבאגים (דבר שהמוצר הבטיח אבל לא קיים) או שימושיות (usability).

(Internal Quality (IQ – איכות פנימית, איך המוצר נראה מבפנים למי שעובד עליו, מפתח אותו ומתחזק אותו. ניתן למדוד אותו ע\"פ מספר קריאות ה \"!?WTF\" של מפתחים ומנהלים בגוף הפיתוח, לרוב אנשים חדשים בארגון שעדיין לא הסתגלו למצב הקיים. מדובר בארכיטקטורה לא טובה, קוד מכוער ומסובך, פיצ\'פוצ\'ים רעים בקוד ובמועקה נפשית אמיתית בשעת ביצוע debug למערכת.

למרות שיש קשר בין EQ ו IQ, ייתכן EQ גבוה בעוד ה IQ אינו טוב.

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

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

מדוע איכות משתלמת
אפשר למצוא חומר רב בנושא, לכן אקצר:

איכות חיצונית רעה מרחיקה לקוחות, מקשה על מכירה חוזרת לאותו לקוח (לרוב אלו מכירות מאוד משתלמות) ומעסיקה את ה support.
איכות פנימית – עד רמה מסויימת מקצרת את זמני הפיתוח, התחזוקה, time to market ועוד. כלומר סה\"כ היא משתלמת כלכלית.
איכות פנימית מעל רמה מסויימת כבר אינה חוסכת אלא עולה יותר, אבל מאפשרת גמישות פיתוחית רבה התומכת בהשגת איכות חיצונית גבוהה. עבור מוצרים מסוימים או פונקציות מסוימות איכות ברמה כזו היא לא כלכלית.

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

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