Things They Don’t Teach You @ School
•Download as PPTX, PDF•
0 likes•334 views
Algorithms and data structures are important, and the Dirichlet function can stretch your imagination. But real-world developers have to deal with so much stuff you don't learn at school. This talk is built around three major pillars: technology trends that affect the software industry, development processes and tools, and interpersonal relationships. We'll talk about how real developers operate, what drives business relationships at work, what tools are mandatory for professional collaboration, and much more.
Recommended
More Related Content
Viewers also liked
More from Dina Goldshtein
More from Dina Goldshtein (17)
Recently uploaded
Recently uploaded (20)
Things They Don’t Teach You @ School
- 1. Things They Don’t Teach You @ School Dina Goldshtein, she codes; blogs.microsoft.co.il/dinazil
- 2. Agenda Technological Trends Development Process (Inter)personal Skills
- 4. Web Applications NoSQL Cloud
- 7. NoSQL
- 9. Before Project Requirements Definition System Design Development Methodology
- 11. During Project Source Control Automation Code Reviews
- 12. Source Control
- 13. Automation
- 14. Code Reviews
- 15. Personal Skills
- 16. Personal Proactivity Adaptability Self Learning Time Management
- 17. Inter-Personal Diplomacy Open Mindedness Saying No
- 18. Summary Dina Goldshtein dinazil@gmail.com blogs.microsoft.co.il/dinazil www.notes-heaven.com Technology Process People
Editor's Notes
- שלום בנות, היום אירגנו לכן הרצאה מיוחדת לכבוד שבוע היזמות העולמי. בכל רחבי העולם מתקיימות השבוע הרצאות ופעילויות שמקדמות יזמים ויזמות. גם כאן באוניברסיטה החלטנו לנסות לקרב קצת את הסטודנטיות לתחום ולכן בכוונה בחרנו לדבר על הנושא שאתן רואות כבר בכותרת – "דברים שלא מלמדים באוניברסיטה". עכשיו, אני לא אנסה לשכנע אתכן שמה שמלמדים באוניברסיטה הוא לא טוב או לא שימוש, אבל הוא ממש לא הכל ולא מספיק. קוראים לי דינה גולדשטיין, אני בוגרת מדעי המחשב כאן בעברית. אני מודה שהתקופה ההיא כבר חלפה לה מזמן, את התואר הראשון סיימתי כבר לפני יותר מחצי עשור (טוב, זה לא כזה הרבה אבל חצי עשור נשמע יותר מ-5 שנים). בכל מקרה, אני מתארת לעצמי שלא הרבה מאוד השתנה מאז שלמדתי ואני מקווה שהדברים שאספר היום יהיו שימושיים עבורכן. כיום אני עובדת בחברה בשם ברייטסורס. אנחנו ממוקמים בהר חוצבים והמוצר שלנו הוא תחנות כח. תחנות כח סולריות. אז אמנם המוצר שלנו הוא לא תוכנה אלא חומרה (ועוד איזו חומרה!) אבל נדמה לי שבימינו אין הרבה תחומים שאין בהם מתכנתים וגם אצלנו יש קבוצה לא קטנה בכלל של כאלה, משהו כמו 70 איש, הרבה מהם סטודנטים שלמדו כאן או לומדים כאן עכשיו. טוב, לא באתי כדי לספר על עצמי או לפרסם את ברייטסורס, למרות שאשמח לספר עוד אחרי זה למי שמתעניינת, באתי לספר לכן על הסודות האפלים שהאוניברסיטה מסתירה מכן
- כמו כל דבר בחיים (ובצבא) ההרצאה שלנו תתחלק לשלושה חלקים. אלה התחומים שראיתי לנכון להתייחס אליהם היום. אני בטוחה שעל כל אחד מהם אפשר לדבר כמה שעות, אם לא כמה ימים, אבל הזמן שלנו בכל זאת מוגבל אז בחרתי את הדברים שנראו לי הכי חשובים, מהניסיון שלי בלימודים ובעבודה. התייעצתי גם עם עוד חברים וחברות וזה מה שיצא. אנחנו נתחיל מהתפתחויות ומגמות טכנולוגיות. זה לא סוד, ואני מקווה שזה לא מפתע אתכן, שהאוניברסיטה נמצאת כמה שנים בפיגור מבחינת טכנולוגיה. אני מעריכה שזה פשוט הסתדר ככה היסטורית וגם האקדמיה מעדיפה לקדש את התיאוריה בעוד שהפרקטיקה קצת משתרכת מאחור. המצב היום הרבה יותר טוב מאשר כשאני למדתי, יש קורסים על אינטרנט ועל פיתוח mobile אבל אלה קורסים אזוטריים שאינם חובה ויחסית מעט תלמידים נחשפים אליהם. חוץ מזה, הקיום של הקורסים תלוי במזל ואם נמצא באותה שנה איזה הייטקיסט שמוכן תרום מזמנו לכך. היום אני אספר לכן בקצרה על מגמות טכנולוגיות מהשנים האחרונות. חלק מהטכנולוגיות לא מאוד חדשות וקיימות כבר מזה זמן מה אך נהיו פופולריות בממדים עצומים רק בשנים האחרונות. לאחר מכן, נדבר על תהליך הפיתוח עצמו. גם זה משהו שלמעשה לא נוגעים בו בלימודים כמעט בכלל. התרגילים קטנים (למרות שזה בטח לא נראה לכן ככה עכשיו ) ומוגדרים היטב. אני לא מכירה אף קורס שבו מקבלים משימה לא מוגדרת היטב שנמשכת כמעט כל השנה. החיים האמיתיים שונים מזה מאוד. אגב, בהקשר הזה ראוי לציין את הקורס על פיתוח אנדרואיד שהצטרף לשנתון כבר לפני כמה שנים והוא נותן טעימה קטנה מאיך שהדברים מתנהלים בפועל. לסיכום, אדבר גם על נושא ההתנהלות בתוך חברה. כסטודנטים מצופה מאיתנו (לרוב) לשבת לעשות את התרגילים לבד. ברור שיש שיתופי פעולה כאלה ואחרים בין התלמידים, אבל זה לא תמיד מה שהאוניברסיטה מכוונת אליו. גם כשעושים תרגילים ביחד בהגדרה, זה שונה מהעבודה האמיתית במובן הזה שבלימודים כולם עובדים (לבד או לחוד) בדיוק על אותו הדבר. בחיים האמיתיים כל עובד בדרך כלל אחראי על חלק אחר מהמערכת ולכן שיתופי הפעולה הם לא בדיוק מה שאנחנו רגילות אליו מהלימודים. יתרה מזאת, כשאנחנו מתחילות לעבוד אנחנו מוצאות את עצמינו הרבה פעמים באינטראקציה לא רק עם מתכנתים, אלא גם עם אנשים לא טכניים, לקוחות, אנשי תמיכה טכנית והמפגשים האלה עלולים להיות לפעמים, איך להגיד את זה, מיוחדים...
- אנחנו נדבר קצת על מגמות טכנולוגיות בעולם הפיתוח. יש הרבה מאוד נושאים שאפשר להתמקד בהם, אבל באמת קצרה היריעה מלהכיל את הכל.
- אנחנו נסתכל ספציפית על הנושא של אפליקציות ווב, מסדי נתונים לא רלציוניים ומחשוב ענן. אלה שלושה טרנדים חמים מאוד שיעשו טוב לקורות החיים שלכן
- באוניברסיטה אנחנו לומדות לכתוב תכניות שרצות במחשב האחד שלנו. למעשה, רוב הזמן אנחנו כותבות תכניות מסוג console application – תכניות שרצות במסך השחור הזה, המעצבן, בלי כפתורים, בלי ממש משתמש, רק אנחנו מול המסך והמקלדת. אנחנו לומדות שבפועל הרבה מאוד תכניות צריכות להיות בעלות ממשק משתמש אך קשה לבדוק אותו אוטומטית והאוניברסיטה מעדיפה להתמקד בעיקר – שהוא האלגורתמים או הרעיונות העמוקים, מאשר בתפל – התעסקות עם כפתורים וחלונות. וזה בסדר גמור. האמת אין סיבה להסתבך עם ממשק משתמש כאשר לומדים על מבני נתונים או על מנגנוני סנכרון. אבל על הדרך גם התעלמנו ממגמה כללית שמתפתחת בעולם כבר הרבה זמן – תופעת אפליקציות הווב – אתרי אינטרנט שלמים שרצים כאילו היו התקנה של כמה ג'יגות לפחות. דוגמאות לכך הן online visual studio, google docs, משחקים, דואר אלקטרוני, צפייה בוידאו או בטלוויזיה. אלה דוגמאות לתוכנות שפעם היינו צריכות התקין, לתחזק ולעדכן ועכשיו אפשר פשוט להיכנס לאתר אינטרנט אחד ולעבוד. זה מדהים בעיניי. האינטרנט הוא חלק כל כך חשוב וגדול מהחיים שלנו ובכל זאת לא מלמדים אותנו איך האינטרנט עובד, על פיתוח לאינטרנט, על אבטחת המידע שלנו באינטרנט. אגב, באופן אישי, אני לא כל כך מחבבת את התחום (וזה עוד בלשון המעטה) אבל אי אפשר להתעלם ממנו. חשוב לציין שכדי לפתח אפליקציות מודרניות בווב צריך להכיר לא רק את שפת התכנות JavaScript אלא מערכת שלמה של כלים, תשתיות, ספריות ושפות שמאפשרות פיתוח אפליקציות מורכבות בעולם הווב. מה שהיה מתאים לאתרים בשנות ה-90 שדרשו בסך הכל כמה שורות סקריפט כדי לעשות אנימציה נחמדה או למלא ספר מבקרים, לא מתאים לאפליקציות ענק כמו ג'ימייל או פייסבוק שיש להן מאות אלפי שרות קוד שרץ בצד הלקוח (בדפדפן). אלה מערכות שלמות עם ארכיטקטורה, עיצוב, תשתיות וספריות, עם מורכבות לא פחות גדולה מאשר בצד השרת או באפליקציות לקוח קלאסיות. ואם כבר מדברים על אינטרנט, אני רוצה להזכיר בקצרה פיתוח שרת-לקוח. כמו שאמרתי, אנחנו רגילות לכתוב תכניות שרצות במחשב שלנו וזהו. אבל בפועל חישובים שונים יכולים לקרות במקומות שונים ולא חייבים תמיד לקרות רק במחשב האחד שלנו. למשל, יכול להיות שיש חישובים מאוד מסובכים שלמשתמש הקצה אין בכלל חומרה שעומדת בהם, או שהחישובים האלה צריכים להתבסס על מידע שהגיע ממקורות שונים, או שהחישובים האלה הם סוד אלגוריתמי של החברה (ולכן, למשל לא רוצים לבצע אותם ב-JavaScript בדפדפן שפתוח לכולם לראות). דוגמה קלאסית לכך היא ניווט. האפליקציה של waze מקבלת מאיתנו נתונים ומעבירה את החישוב לשרת מרוחק שמרכז את הנתונים שהגיעו מכל הלקוחות, גם כי החישוב מסובך והמכשירים הניידים שלנו לא בעלי כח חישוב מספיק וגם כי השרת אוגר בתוכו את כל הנתונים. זה לא הגיוני לשלוח לכל המכשירים את כל הנתונים כל הזמן. הפרוצדורה נהיית הרבה יותר יעילה כאשר העבודה מחולקת לחלקים – איסוף המידע בצד הלקוח ועיבוד הנתונים בצד השרת. יתרון נוסף של ארכיטקטורת שרת-לקוח היא היכולת לרכז את כל הלוגיקה במקום אחד ולהציג אותה במגוון פלטפורמות וצורות. למשל, אם נסתכל עוד פעם על דוגמת הניווט, אז אלגוריתם הניווט צריך להיות ממומש פעם אחת בלבד ובשפה אחת בשרת של החברה. ואז אפשר לכתוב אפליקציות לכל פלטפורמות המובייל, לאתרי אינטרנט וכו'. דמיינו לעצמכן שצריך היה לממש את הלוגיקה של הניווט בכל פעם מחדש, לכל סוג של טלפון או מערכת הפעלה...
- ואם אנחנו כבר מדברות על שרתים ופיזור עבודה, זה מביא אותנו באופן ישיר לטכנולוגיה הבאה והיא הענן. הענן היא לא ממש טכנולוגיה אחת אלא יותר מושג רעיוני – גישה חדשה למחשוב בסקאלה גדולה מאוד, בעיקר בכל מה שקשור לאינטרנט ועיבוד מידע. אחד מהעקרונות הבסיסיים של הענן הוא הגמישות – יכולת עבודה תחת עומסים משתנים. למשל, יש אתר שאנחנו משתמשים בו בעבודה כדי להזמין משלוחים של אוכל לארוחת צהריים. כל יום בשעה 11 מערכת ההזמנות נסגרת ומי שלא הזמין אוכל יצטרך להישאר עם טוסט במטבח. הצרה היא שבשעה 10:45 המערכת קורסת תחת עומס המשתמשים והרבה אנשים לא מצליחים להזמין ארוחת צהרים על אף שהם היו בסדר וניסו לבצע את ההזמנה בזמן. זה קצת כמו הגשת תרגילים במערכות הפעלה בחצות. לפחות בתקופתי המערכת הייתה קורסת באופן קבוע סביב חצות. בכל מקרה, אתר ההזמנות הזה (וגם מערכת הגשת התרגילים) נמצא בסיטואציה מאוד מיוחדת. ברוב שעות היום אין לו כמעט משתמשים אבל החל מהשעה 10 בבוקר מספר המשתמשים עולה ועולה עד שמגיע לשיא זמן קצר לפני 11. מן הסתם המסקנה היא שהשרתים לא עומדים בעומס וצריך יותר שרתים או שרתים חזקים יותר. אלא שכל החומרה הזאת עולה כסף ואם ישדרגו אותה אז רוב הזמן היא תעמוד ללא יותר מדי עבודה ותתבזבז. עכשיו דמיינו מצב שבו אפשר לקנפג את מספר השרתים שיהיה נמוך במהלך הלילה ואז יעלה בשעות הבוקר עד שיגיע לשיא בין 10 ל-11. הנה דוגמה למערכת כזאת: קונים מלא שרתים ולא מדליקים אותם כשלא צריך. זה חוסך בחשמל ואולי גם בבלאי של רכיבים. אבל הבעיה היא שעצם קניית החומרה היא יקרה מאוד. במקום זה הענן מאפשר את ההרחבה הזאת בצורה פשוטה ובלי צורך לקנות חומרה באופן אישי. הרעיון הוא שמישהו אחר קנה חומרה, ממש מלא חומרה, ממש ממש ממש ממש מלא חומרה, והוא יכול לתת את החומרה הזאת לפי הצורך ללקוחות שונים. יש כל מיני ספקי ענן, למשל מיקרוסופט ואמאזון. להן יש חוות שרתים ענקיות בכל רחבי העולם והם מספקים שירותים כאלה. מה שיפה בדבר הזה הוא גם שהלקוחות לא משלמים על הזמן ועל החומרה שהם לא משתמשים בהם. לרוב ספקי שירות הענן יש כל מיני תכניות, קצת כמו תכניות סלולר, ובהרבה מקרים זה יכול להיות הרבה יותר זול מאשר קניית חומרה, תחזוק שלה וכו'. שימו לב שהדוגמה שנתתי כאן היא במחזורים של יום אבל הסקאלות יכולות להיות שונות. למשל, יכול להיות שיש לנו מערכת שהעומס עליה קטן יותר בסופי שבוע או במהלך חגים או לפי עונות שנה (נניח מערכת הזמנות של ספורט ימי). הענן נותן תשתית גמישה לניהול ושימוש בחומרה. יתרון נוסף של שימוש בענן הוא הקטנת החיכוך וקיצור תהליכים. אנחנו חוסכים כסף לא רק בגלל שלא קונים את החומרה אלא גם על כל מה שמתלווה לחומרה הזאת – מקום פיסי לשמור אותה, אנשי מערכות שיתקינו, יקנפגו ויתחזקו אותה. חוץ מזה, הרבה פעמים בחברות גדולות תהליך הרכש של חומרה גדולה יכול לקחת זמן רב מאוד, שבועות במקרה הטוב אבל בדרך כלל חודשים (אני אישית כבר נואשתי מלקבל אצלינו דיסק קשיח חדש. עכשיו דמיינו חוות שרתים שלמה!). כאשר עובדים עם הענן אפשר תוך 5 דקות להקים חוות שרתים עם כמה מחשבים שרוצים. יחד עם כל הפלא הטכנולוגי הזה מגיעים גם אתגרים חדשים: אבטחה, רגולציה של מיקום שמירת המידע, מערכות ישנות שצריך להתממשק איתן, קרבה גיאוגרפית ללקוח. יש פה הרבה דברים מעניינים שעוד נותרו פתוחים ואפשר לחקור!
- NoSQL (Not Only SQL) היא תנועה יחסית חדשה בתחום אחסון המידע. הרעיון הוא שיש סוגים מסויימים של מידע או מאפיינים מסויימים של מידע שהמבנה הטבלאי הקלאסי אינו מתאים להם. המוטיבציה למבנה אחר יכולה להיות פשטות העיצוב, יכולת הרחבה אופקית ושליטה גדולה יותר על זמינות המידע (כפועל יוצא מההרחבה האופקית). יש כל מיני דרכים לשמור נתונים שלא בצורה של טבלה או שורות. הדרכים המקובלות: אוסף זוגות – כלומר נתונים ששמורים לפי מפתח כלשהו ולכל מפתח מתאים ערך אוסף מסמכים – יש כל מיני פורמטים שהמסמכים האלה יכולים להיות שמורים בהם אבל יש פורמט שנקרא JSON שהוא די מקובלת ואלה מכן שמכירות JavaScript בוודאי מכירות אותו טבלאות, אך כאלה שבהן המידע ששמור ברציפות בדיסק הוא דווקא העמודות ולא השורות גרפים (למשל כמו מה אנחנו רואות בתמונה בשקף כאן) מידע בינארי יש עוד כל מיני דרכים לשמור מידע אבל בכל מקרה הפואנטה היא שמאחר שכל השיטות האלה שונות זו מזו גם הביצועים שלהן וההתאמה שלהן לפרוייקטים ולדרישות שונות היא שונה. יש מקרים שבהם מסד נתונים טבלאי קלאסי הוא מושלם! אבל יש מקרים שלא. דוגמה שמאוד אוהבים לתת בהקשר הזה היא רשתות חברתיות. כשיש הרבה יחסים בין אובייקטים ורוצים להיות מסוגלים לבצע שאילתות מורכבות על היחסים האלה מבנה טבלאי מתחיל להיות קצת מסורבל. במקרה כזה מסד נתונים שמראש שומר את הנתונים שלו בתור גרף יכול להיות מאים הרבה יותר. ואכן יש מסד נתונים כזה שנקרא Neu4j וזה בדיוק מה שהוא עושה. יתרה מזאת, יש לו שפת שאילתות מיוחדת שמתאימה לביצוע שאילתות על גרפים ועל יחסים מורכבים. זה לא שלא ניתן היה לדמות את הנתונים האלה באמצעות טבלאות ואת השאילתות באמצעות SQL אבל המבנה הגרפי הופך את שמירת המידע ליעילה יותר ואת כתיבת השאילתות לפשוטה יותר. עוד דוגמה היא שמירה של מחירים של מניות. נניח שבכל יחידת זמן אנחנו שומרים את המחירים של כל המניות. זה ידע מאוד מובנה ומבנה טבלאי אכן מתאים במקרה הזה. אלא שבמסד רצלציוני רגיל הנתונים נשמרים ביחד לפי שורות. בדרך כלל אנחנו מעוניינים לקבל את הנתונים עבור מניה ספציפית לאורך זמן ולכן השמירה הפיסית לפי שורות יוצרת לנו פרגמנטציה גדולה בנתונים. מוטב היה לשמור את העמודות ביחד. כל עמודה מתאימה למניה מסויימת וממויינת לפי זמן. זה מאפשר לנו להביא נתונים של מניה ספציפית ביעילות מאוד גבוהה. אז למקרה הזה אנחנו יכולים להשתמש במסד נתונים עמודאי (columnar), למשל Cassandra. אחת הסיבות העיקריות שבגללן מסדי נתונים לא רלציוניים צברו תאוצה היא גודל המידע ופיזורו על פני יותר משרת אחד. מסדים רלציוניים בנויים חזק מאוד סביב ההנחה שכל המידע יושב בשרת אחד, ומנוהלות טרנזאקציות שיכולות לפעול על הרבה נתונים במהירות כי כולם יושבים על שרת אחת. אבל החל מכמות מסויימת של מידע ההנחה שאפשר לעשות הכל על שרת אחד פשוט קורסת. זה יכול להיות 500 ג'יגה, זה יכול להיות 500 טרה, אבל בשלב כלשהו צריך הרבה מאוד שרתים כדי לאחסן ולגשת ביעילות לכל הנתונים. ושם מסדי נתונים רלציוניים פשוט לא טובים – רק תחשבו על לעשות שאילתא שדורשת לעשות join בין טבלאות שיושבות במחשבים שונים, או טרנזאקציה שצריכה לעדכן שורות שנמצאות בעשרים שרתים שונים. למעשה, אפילו המושגים של טרנזאקציה או join יכולים לא להתאים לכמויות גדולות במיוחד של מידע, מה שמוביל לצורך לחשוב על עיבוד מידע, שאילתות, חתכים, דו"חות וכו' בצורה שונה לגמרי מאשר במסדי נתונים שאנחנו רגילים אליהם מהלימודים. למשל, הרבה פעמים במקום להריץ שאילתא כשצריך את התוצאה שלה (ולא קודם לכן) עושים אינדוקס ראשוני של המידע כדי שאפשר יהיה לבצע את השאילתא בזמן סביר ללא עיכוב. התחום הוא תחום מרתק ומאוד שונה ממה שלומדים באקדמיה, למעט אולי הקורס databases on the internet, שאני לא יודעת אם הוא עדיין קיים.
- הדבר הבא שאני רוצה לדבר עליו הוא תהליך הפיתוח עצמו. הרבה אנשים אומרים שזה אפילו יותר חשוב מהטכנולוגיה ויכול להיות שזה נכון. בניגוד למקצועות "הנדסיים" יחסית, שיש בהם חוקים וכללים ותקנות, בעולם התוכנה המצב הוא די מערב פרוע. אין איזשהו גוף תקינה מקצועי שקובע למי מותר לעצב תוכנה ולעשות ארכיטקטורה, ואין הסמכה גורפת לגבי האופן שבו צריך להתנהל פרוייקט תוכנה. אבל יש כמה דברים שברור שצריך לדבר עליהם, כמה דברים שעולם התוכנה מתדיין עליהם כבר במשך יותר מ-50 שנה וזה מה שאני רוצה להציג לכן. ברוב במקרים, הפרוייקטים שאתן עושות באוניברסיטה לא מאפשרים להתנסות באמת בתהליך פיתוח תוכנה כפי שהוא מתנהל בחברות מסחריות גדולות.
- כשמדברים על ניהול פרוייקט אפשר לחלק את הדבר לשניים: הזמן שלפני תחילת הפרוייקט וההתכוננות אליו והזמן שתוך כדי פיתוח הפרוייקט.
- לפני הפרוייקט אנחנו צריכות בכלל להבין מה הפרוייקט, מה הצרכים, מי הלקוחות. באוניברסיטה נותנים לנו הגדרת תרגיל והיא הדרישות. אבל בחיים האמיתיים אף אחד לא נותן לנו מסמך מסודר וכתוב בו את כל מה שצריך לעשות. טוב, זה לא לגמרי מדויק, בסוף צריך להיות מסמך מסודר כזה והמתכנתים אכן מקבלים אותו אבל מישהו שהוא מתוך החברה ולא איזה גוף ראשוני צריך לייצר את המסמך. בשביל זה צריך לדבר על לקוחות ולהבין את הצרכים. זה תהליך איסוף הדרישות. אבל זה לא רק לדבר עם לקוחות. למעשה התהליך יכול להיות מורכב. צריך להבין בכלל מיהם האנשים שצריך לדבר איתם, צריך לנתח את הדרישות, לוודא שאין בהן סתירות פנימיות ולוודא שאכן ניתן לבצע אותן. מסמך הדרישות צריך להיות מסודר וכל דרישה צריכה להיות ניתנת למדידה, בדיקה ומעכב. צריך לקשר בין הדרישות לבין צרכי הביזנס ודעת לזהות הזדמנויות. צריך לדעת לדרג את הדרישות לפי קושי מימוש ולפי חשיבות. בסה"כ ניתן לומר שהתהליך מורכב משלושה חלקים: איסוף הדרישות מלקוחות, זה יכול להתבצע למשל באמצעות ריאיונות או focus groups שבהן מציגים כל מיני רעיונות ורואים איך המשתמשים מגיבים ומה מוצא חן שימושי ומה לא ניתוח הדרישות ווידוא שהן ברורות, מלאות, קוניסיסטנטיות וחד משמעיות כתיבת הדרישות. יש כל מיני דרכים לעשות את זה. למשל בצורה של "מקרים ותגובות" – כשעושים כך וכך צריך לקרות כל או כך, או באמצעות משהו שנקרא user story- ממש כותבים סיפור קצת מנקודת המבט של המשתמש, מה הוא רצה לעשות, מה הוא עשה, מה קרה כו'. כתיבת דרישות הוא לא משהו שהמפתחים בדרגים הנמוכים עושים. בדרך כלל זה יהיה תפקיד מנהל הפרוייקט לרכז את הנושא הזה. אבל למפתחים חשוב לדעת שקיים תהליך כזה ושלמעשה לא מתחילים לעבוד לפני שברור מה צריך לעשות. מצד שני, כמובן שאי אפשר לחכות עד שהמסמך יהיה מושלם כי אז לא יקרה כלום. מה שקורה הוא שעובדים באיטרציות והדרישות מתפתחות עם הזמן. מתחילים עם איזשהו אב טיפוס ומתגלגלים משם. עוד על איסוף דרישות כאן: http://en.wikipedia.org/wiki/Requirements_analysis לאחר שיש לנו דרישות וברור לנו מה בסופו של דבר צריך להיות המוצר אפשר להתחיל לעבוד. אבל אי אפשר להתחיל לעבוד סתם ככה בלי לתכנן. כי אנחנו נמצא את עצמינו לא מוכנים לבעיות שעלולות לצוץ או שלא נוכל להרחיב את המערכת בצורה נוחה. תהליך העבודה חייב להתחיל על system design, בלי כתיבת קוד. אלא הסתכלות רוחבית גלובלאלית על המערכת, הבנה של ההיחידות הלוגיות, הממשקים ביניהן וכו'. אבל גם דברים כמו שפת תכנות ובחירה של מערכת הפעלה הן החלטות חשובות שיש לבצע לפני תחילת העבודה. האדם שעושה את התפקיד הזה נקרא הארכיטקט של המערכת. לעשות דיזיין למערכת גדולה זו ממש אמנות וגם ובדרך כלל מפתחים מאוד מנוסים עושים את זה. אין תשובה אחת נכונה. זה הרבה פעמים עניין של העדפה אישית ותחושות. כן יש מודלים ו-design patterns שהתפתחו עם השנים ואפילו אפשר לקרוא עליהם תיאוריה וספרים שלמים, אבל לרוב, לדעתי אין כמון ניסיון מעשי בתחום הזה. ככל שתעבדו ותתכננו יותר פרוייקטים אתן תקבלנה ניסיון של איזו שיטה מתאימה לאיזה פרוייקט ואיזה דיזיין נוח לצרכים מסויימים ולא לאחרים. יש גם כמה עקרונות גיזיין גלובליים שתמיד כדאי לפעול לפי הם אבל אני חושבת שלא ניכנס לזה היום ואולי נעשה על זה הרצאה בעתיד. עוד על ארכיטקטורה של מערכות: http://en.wikipedia.org/wiki/Software_design במקביל לאיסוף הדרישות והדיזיין צריך להחליט מהי מתודולגיית הפיתוח שנשתמש בה בפיתוח הפרוייקט. כאן הכוונה היא בעיקר לאופן ניהול הפרוייקט, סט הכלים, העקרונות, התהליכים והפעילות שלפיהם מפותחת ומתוחזקת מערכת התוכנה. זהו ענף חדש ואין עדיין הסכמה לגבי מהי המתודולוגיה הכי טובה. המון חוקרים עושים ניסויים וכותבים מאמרים בנושא. אני חושבת שבגדול שיטות שונות מתאימות לתעשיות שונות. למשל, בתחום הבטחוני או הרפואי המשמעות של טעות היא הרבה יותר חמורה מאשר במקרה של אתר אינטרנט. על כן, סביר ששיטות העבודה בתחומים האלה תהיינה שונות. בגדול אפשר לחלק את שיטות העבודה לשני סוגים: מתודולגיות קוויות: פיתוח תוכנה מדומה לתהליך חד כיווני שמתחיל ונגמר. השלבים מתבצעים בטור, אחד אחרי השני ובכל שלב יש מיקוד במשימה עיקרית אחת ואין חזרה אחרוה. קודם כותבים דרישות, אחר כך עושים דיזיין ואז ממשים ובסוף בודקים ומוציאים החוצה. זוהי שיטה יחסית ישנה ולא כל כך מקובלת היום בעיקר כי היא לא גמישה וקשה לחזור אחורה ולעשות שינויים – מה שבפועל נחוץ מאוד הרבה פעמים. ארגונים ותיקים שעוסקים במוצרים old school כמו נשק או מערכות רפואיות יותר מתאימים לדבר הזה משום שהדרישות מאוד נוקשות ולא נוטות להשתנות.וגם ברור מתי המוצר מתחיל ומתי נגמר. לפיתוח אתר אינטרנט, לעומת זאת, או אפילו סתם אפליקציית צד לקוח כלשהי זה בדרך כלל לא מתאים כי הדרישות משתנות הרבה עם הזמן והלקוחות מגלים באגים ומבקשים פיצ'רים והתוכנה צריכה לעבור אבולוציה במהלך ימי חייה. - מתודולוגיות איטרטיביות: הרעיון הוא בעצם כמו המתודולוגיות הקוויות אלא שכל התהליך חוזר על עצמו שוב ושוב. למעשה זה אומר שאפשר לחזור אחורה בתהליך וזה חשוב מאוד בעולם דינאמי שבו הדרישות משתנות. זה גם מאפשר לפתח את המערכת בחלקים, מהחלקים החשובים אל החלקים הפחות חשובים ובכל שלב להוציא ללקוות משהו שאפשר לעבוד איתו. מערכת שלמה ועובדת אך עם פחות פיצ'רים (בניגוד למקרה הקודם שבו זה או הכל או כלום). כשאני הייתי בלימודים עדיין עשיתי סמיר עם דרור פייטלסון על פיתוח תוכנה. זה היה נחמד ולמדנו הרבה שיטות וקראנו מאמרים אבל כמובן שאין כמו הניסיון אז כמובן שגם פה אני עומדת ומרצה לכן על תיאורה, אבל חשוב שתכירו שבכלל יש תחום כזה שמדבר על שיטות פיתוח והיא תחום די מפותצח ויש הרבה אנשים שחוקרים אותו. יום אחד כשתהיו מנהלחות תצטרכו לחשוב מהי הדרך הכי טובה להוביל את הפרוייקטים שלכן. אבל אני מקווה שעד אז כבר יהיה לכן מספיק ניסיון בהשתתפות בפרוייקטים כדי שתרגישו בעצמכן מה היתרונות והחסרונות של כל שיטה. עוד על מתודולוגיות פיתוח: http://en.wikipedia.org/wiki/Software_development_process
- עכשיו שאנחנו מוכנות ותיכננו את כל שלבי הפרוייקט ואיך התוכנה אמורה לעבוד וכו' אנחנו יכולות להתחיל לעבוד, כלומר ממש לכתוב קוד. אבל כדי לעשות גם את זה בצורה טובה וקונסטרוקטיבית חשוב להכיר כמה משפחות כלים שיכולות לעזור לנו לעשות עבודה יותר טובה. ספציפית, אנחנו נדבר על source control, על אוטומציה של תהליכים ועל –code reviews.
- אני רוצה להתחיל בסיפור. כשהייתי בשנה ב' קיבלנו תרגיל במערכות הפעלה. זה היה בשלב כבר די מתקדם והיו שם הרבה thread-ים וסנכרונים וכו'. זה היה די מסובך. הזוג שלי ואני עבדנו על זה כל היום כאשר אחרי שעות רבות של עבודה לפתע קרס המחשב והכל הלך לאיבוד. טוב, דבר ראשון אכלנו חבילת שוקולד וחבילת במבה. ועכשיו מה עושים? טוב, ספציפית באותו היום הלכנו לאוניברסיטה וכתבנו את התרגיל מחדש. בגלל שזה היה באותו היום והתרגיל לא היה מאוד גדול הכל עדיין ישב לנו בראש והסתדרנו. אבל בכללי ברור שיש כאן בעיה. עוד דוגמה. זה דווקא לא לקוח מהמציאות אבל זה לגמרי יכול לקרות. נניח שאתן עובדות על תרגיל די גדול עם די הרבה פיצ'רים. אתן מפתחות פיצ'ר אחרי פיצ'ר והכל נראה בסדר. והנה פתאום מימשתן עוד איזו יכולת ופתאום שום דבר לא עובד. אבל הרי אתמול הכל היה בסדר!!! אנחנו רוצים איכשהו לחזור אחורה בזמן ולהשוות את מה שהיה אתמול למה שיש לנו היום. זה יאפשר לנו לצמצם את המקומות שבהן יכול להיות שהבאג קרה. אחת התובנות החשובות ביותר מהעשורים האחרונים קשורה לנושא ניהול קוד המקור. כשבנאדם אחד עובד על פרוייקט של אלף שורות קוד, הוא לא צריך יותר מדי בלגאן וניהול. מקסימום אפשר מדי פעם לעשות זיפ של כל הקוד ולשים בדרופבוקס, בקטע של גיבוי ולא מעבר לזה. אבל תחשבו רגע על מוצר תוכנה גדול באמת. משהו באמת באמת גדול. נניח, מערכת הפעלה כמו ווינדוז. או דפדפן כמו כרום. כמה שורות קוד לדעתכם יש בווינדוז? ההערכה היא שסדר גודל של 80 מיליון שורות קוד. יש אלפי מפתחים שעובדים על מיליוני שורות קוד בכל יום! אני מניחה שאתם מבינים שאי אפשר לנהל את הדבר הזה בעזרת זיפים בדרופבוקס, נכון? רק לסבר את האוזן, לוקח משהו כמו 24 שעות רק לקמפל את ווינדוז אם עושים את זה ממש מאפס. אז נגיד שמישהו הכניס קוד שלא מתקמפל. עכשיו צריך לחכות שעות עד שתהיה גרסה שעובדת ואפשר לעשות איתה משהו. מה שאני מנסה להגיד הוא שבקרת תצורה או ניהול קוד מקור הם נושאים מאוד חשובים בפרוייקט גדול. יש הרבה מאודכלים שמאפשרים לנהל גרסאות ושינויים בקוד מקור, למזג שינויים ממפתחים שונים, לעבוד על ענפים שונים בפרוייקט בלי להשפיע על ענפים אחרים, ועוד הרבה מאוד מתודולוגיה שקשורה לכך. כמה דוגמאות למוצרים כאלה: Git, Mercurial, ClearCase, TFS, Perforce ויש עוד הרבה מאוד - בדרך כלל לכל כלי יש גישה משלו ודרך עבודה מועדפת, וחלקם מתאימים יותר לפרוייקטים מסוג מסוים.
- נושא מאוד חשוב נוסף הוא אוטומציה של תהליכים. שוב, בפרוייקט גדול יכול להיות שמתבצעים מאות שינויים מדי יום. לא סביר שכל שינוי כזה יהיה צריך להיות מלווה בתהליך ידני של קומפילציה, בדיקות, הפצה וכו'. לכן, בשנים האחרונות יש דגש מאוד חזק על תהליכים אוטומטיים של בדיקות, הפצה, וניטור מתמיד של המוצר. הרבה חברות אינטרנט משנות את האתר שלהן עשרות פעמים ביום, כך ששינוי שמתכנת עושה בבוקר יכול להיות ממש תוך כמה שעות כבר להופיע בדף הראשי של פייסבוק למשל. גם אם המצב לא דרמטי כל כך, את תהליך הבדיקה והאריזה של המוצר רצוי מאוד לעשות אוטומטית כדי לא לבזבז זמן ולהימנע מטעויות אנוש. למשל, אצלנו בברייטסורס יש שרתים שכל תפקידם הוא לקמפל, להריץ בדיקות, ולארוז את המוצר כדי שאפשר יהיה להתקין אותו ולהמשיך לבצע עליו בדיקות ידניות. הבדיקות האוטומטיות חוסכות הרבה מאוד זמן יקר כי הן מאפשרות לזהות בקלות ובלי מעורבות אנושית טעויות ותקלות שמתרחשות מדי יום. השרתים שמבצעים את התהליך הזה ברקע מאפשרים למתכנתים לעבוד בשקט כשהם יודכים שכל השינויים שלהם בדקים בצורה אוטומטית בסביבה נקייה שמזהה בעיות. אבל אפשר לעשות עוד המון דברים נוספים בצורה אוטומטית. למשל, לפני כמה חודשים הטמעתי בחברה תהליך אוטומטי שמנסה לזהות בעיות ובאגים שמתרחשים בשטח. זה מאפשר לחסוך זמן כדי לא להסתכל על כל בעיה בנפרד בצורה ידנית, אלא לקבל דו"ח מרוכז שאומר שהנה, קומפוננטה מסויימת של צוות כך וכך אחראית לבעיה שנתקלנו בה אתמול בשטח.
- לבסוף, מרכיב מאוד חשוב שלא מתעכבים עליו יותר מדי באוניברסיטה הוא code review. בפרוייקט תוכנה שמכבד את עצמו, אין דבר כזה שמתכנת כותב קוד ומכניס אותו למערכת בלי שזוג עיניים אחד לפחות יעבור עליו בנוסף. כמות הבאגים שמתגלים בצורה כזאת היא עצומה והתהליך עצמו לא לוקח הרבה זמן. יש משהו מדהים בתופעה הזאת: מספיק שאת מסבירה למישהי אחרת את הקוד שכתבת, מה רצית לעשות, איך המחלקות והמתודות עובדות, ופתאום את מגלה – אפילו בעצמך! – באגים או בעיות דיזיין. בהרבה מקרים אפילו, הידיעה שיהיו אנשים נוספים שיקראו את הקוד שלך כבר גורמת לך לכתוב אותו יותר טוב מלכתחילה ולהימנע מקיצורי דרך או קוד מכוער, דברים שלא היית עושה לבד במקרים מסויימים. יש כל מיני דרכים לעשות code reviews. לחלקי קוד לא מאוד ארוכים או שינויים קטנים אפילו לא צריך להיפגש. יש כל מיני כלים שמראים את ההבדלים בין שתי גרסאות ומאפשר לכל אחד offline בזמנו החופשי להעיר הערות. אבל כשיש שינויים מאוד גדולים בקוד או שינויי design מומלץ ממש להיפגש בחדר ולהראות את הקוד יחד עם הסברים.
- והנה אנחנו מגיעות לשליש האחרון של ההרצאה להיום – יחסי אנוש, או כישורים רכים באופן כללי. הכישורים האלה מאוד חשובים לעבודה שלנו כמתכנתות בעולם האמיתי. כשעובדים בצוות שיש בו אנשים יותר מקצועיים ופחות מקצועיים, מתכנתים ולא מתכנתים, אנשי ביזנס ואנשי בדיקות, מנהלים בכירים ויועצים משפטיים, מאוד חשוב לתת דגש לצדדים האנושיים של תהליך הפיתוח והעבודה בחברת תוכנה. בהרבה מאוד מקרים הרצונות של כל הצדדים האלה מתנגשים – המנהלים רוצים הרבה פיצ'רים, המתכנתים מתעצבנים שאין זמן לעשות את כולם בצורה טובה, אנשי ה-IT חוסמים את הגישה לפורומים של מתכנתים והיועצים המשפטיים אוסרים עליכם להשתמש באיזה קוד שמצאתם באינטרנט (שבמקרה דווקא כן היה פתוח). ועם כל האנשים האלה צריך להסתדר ובנימוס. זה קשה, תאמינו לי...
- הדבר אולי הכי חשוב הוא להגדיל ראש. באוניברסיטה מש מעודדים אתן לא לעשות את זה. אם משהו לא מופיע בתרגיל, אז לא צריך לעשות אותו. אם משהו שמופיע בתרגיל לא נראה לכן הכי הגיוני או מתאים, זה ל משנה – צריך לעשות את מה שכתוב. ובסוף תמיד אפשר לערער. ברור שבמציאות זה לא באמת עובד ככה. איסוף דרישות זה תהליך מורכז והמשתמשים אף פעם לא יודעים בדיוק מה הם רוצים. ברוב המקרים אתן לא יודעות בדיוק מה צריך לעשות ולא כתוב בשום מקום איך צריכה להיקרא הפונקציה הזאת או המחלקה ההיא. צריך להגדיל ראש גם בקטע של עיצוב התוכנה ואיסוף הדרישות, וגם בביצוע עצמו – להתייעץ עם אחרים כשצריך, לא להסס לעשות שינויים, לקבל משום מאחרים וכו'. תלוי באיזו חברה אתם עובדים ומה המוצר שלכם אבל בימינו צריך לגדל עור של פיל ולהתמודד עם מה שקורה מסביב. מהניסיון שלי זה בעיקר קשור ללקוחות ולדרישות. לקוחות הם באמת אנשים איומים. הם ממציאים דרישות חדשות, שונות ומשונות בכל יום והרבה פעמים גם סותרים את עצמם על הדרך ומשנים את כל אופן פעולת המערכת. אנחנו צריכות לדעת להתמודד עם זה גם ברמה האישית וגם ברמה המקצועית. קרה לי מספר פעמים שעבדתי קשה על משהו שפשוט החליטו לבטל יום אחד. זה היה מאוד מעצבן אבל הדברים האלה קורים. ומבחינה מקצועית, וזה קצת מתקשר לארכיטקטורה של מערכות, אנחנו צריכות לנסות לתכנן את המערכת כך שיהיה יחסית נוח לעשות שינויים. לדוגמה אם חלק מהמערכת שלנו היא שמירת נתונים לקבצים אולי כדאי לקחת בחשבון שהפורמט עלול להשתנות ולתכנן מחלקה נפרדת שיש לה ממשק שמירה לקבצים והמימוש שלה יכול להשתנות בהתאם לצרכים. אבל אני זולגת פה לתחום הפיתוח שכבר דיברנו עליו ועכשיו אני רוצה להתמקד באספקטים אישיים. לימוד עצמי. נכון, גם בהייטק יש קורסים וכנסים והרבה פעמים אתן אולי קוראות על אנשים שמבלים בערב בבר אחרי איזה כנס ודנים בהרצאות מקצועיות שהיו בבוקר. אבל את עיקר הלימוד אתן צריכות לעשות לבד. זה אומר לקרוא באינטרנט, לקרוא ספרים, לראות הרצאות מוקלטות, לשאול שאלות בפורומים ולענות לשאלות, לחקור לבד, לכתוב קוד כדי להתנסות באיזו ספריה חדשה, להסתכל על קוד שמישהו אחר כתב ועוד ועוד. כמעט כל יום צריך ללמוד משהו חדש. זה יכול להיות משהו קטן, כמו איזה פיפס בטכנולוגיה שאת כבר מכירה וזה יכול להיות משהו חדש לגמרי. למשל, לפני שנה ומשהו הייתי צריכה ללמוד כמעט מאפס פיתוח ווב, כי היה צריך את זה בשביל פרוייקט בעבודה. אם לא לומדים את התהליך הזה של למידה עצמית והתפתחות מתמדת, אתן יכולות למצוא את עצמכן במצב של 20 פעמים שנת ניסיון אחת ולא 20 שנות ניסיון אמיתי. זה לא שבאוניברסיטה לא לומדים באופן עצמאי אבל הלימוד העצמי הזה הוא מאוד מובנה. לקורס יש רשימת ספרים או מאמרים, יש אתר אינטרנט ויש כל שבוע כמה שעות הרצאה ותרגול. יש סילבוס אפילו אם אין חומרים מוכנים לכל הפחות יש נושא שברור שאותו צריך ללמוד השבוע. הדבר האחרון שאני ירוצה להזכיר בעניין הכישורים האישיים הוא יכולת לנהל זמן ביעילות. נכון, יש מנהלים וראשי צוותים ומסמכי פרוייקט ולו"ז באאוטלוק. אבל הרבה מאוד מניהול הזמן צריך להיות שלכן. אתן צריכות לדעת לנהל את הזמן שלכן ברמה יומית, שבועית וחודשית ולשקף את זה להנהלה. אתם צריכות לדעת מתי יש לכן זמן לעזור למישהו אחר מהצוות ומתי אתן חייבות להתמקד במשימה דחופה. אתם צריכות לדעת איזה לק מהזמן להקדיש ללימוד ומחקר ואיזה חלק מהזמן לפיתוח ובדיקות. ניהול זמן נכון זה משהו שלומדים מניסיון. אני לא חושבת שאפשר ללמד את זה בקורב באוניברסיטה. ובגלל שרוב התרגילים ניתנים לתקופת שמן של שבוע או שבועיים גם לא לומדים כל כך את הכישור הזה על הדרך. אני חושבת שלהרבה מתחילים יש בעיה ביכולת לנהל זמן, או למעשה יותר ביכולת להבחין בין עיקר לתפל וכתוצאה מכך לא לנהל את הזמן נכון. למשל, בגלל חוסר ניסיון וביטחון אנחנו עלולות למצוא את עצמנו בלולאה אינסופית של תכנון ובלי לעשות בכלל שום דבר קונקרטי.
- כבר אמרתי קודם שבעבודה אנחנו פתאום מוצאות את עצמינו צריכות להתמודד עם הרבה סוגי אנשים שבאים מרקעים שונים ולכל אחד דרישות משלו. כישורי דיפלומטיה טובים יקלו עליכן מאוד את החיים. לגרום לכולם להיות מרוצים זה לא קל. אני עוד לא למדתי לעשות את זה. אם תצליחו, אשמח לשמוע איך ובהמשך ישיר לכך, חשוב להישאר פתוחים לרעיונות ולדעות של אחרים. למדנו באוניברסיטה ויש לנו תואר ואנחנו מרגישות חכמות ומוצלחות. אבל יש עוד אנשים מוצלחים. לפעמים אין להם תואר במחשבים אבל סתם יש להן הרבה ניסיון בשימוש במערכת, או שהם למדו במקום אחר ולמדו שיטות שונות לבצע משימות. למרות שהרבה פעמים יש לנו דעות חזקות משלנו וברור שאנחנו אוהבות לעשות דברים בדרך שלנו חשוב לשמור על פתיחות ולהיות מסוגלות להשתכנע לפעול אחרת. כמובן, זה לא צריך לבוא על חשבון דברים שנראים לכן עקרוניים. זה הכל עניין של משא ומתן – דיפלומטיה. לסיכום, חשוב גם לדעת מתי ואיך להגיד לא. כולנו רוצות לעזור – למשל, אם חבר לצוות מבקש עזרה או שואל שאלה או רק רוצה שנסתכל ביחד על איזו בעיה קשה, איך לא נעזור לו? כשראש הצוות רוצה שנוסיף עוד משהו קטן לתכנית העבודה, לא נסכים? וזה גם קצת מתחבר לניהול זמן. פשוט צריך לדעת להגיד לא, ולנהל את כמות המחויבויות שסביר שיהיו לנו. אף אחד לא רוצה לעבוד 14 שעות ביום ולוותר על החיים האישיים ועל השפיות. אף אחד לא רוצה להקריב את האיכות בפרוייקט על חשבון לעשות יותר פיצ'רים ולהוציא את הגרסה מהר יותר. גם מנהלים (בדרך כלל) לא רוצים את זה, אם מסבירים להם את כל ההשלכות בצורה משכנעת לכן חשוב לדעת להגיד לא גם למנהל שמבקש משהו בזמן או איכות לא סבירים, וגם לחברים לצוות שרוצים יזרה או זמן או כל דבר אחר שפשוט אי אפשר לתת באותו הרגע.