בפוסט קצר, שיכול להיות שרשור בטוויטר, אני רוצה לחדד את ההבדל בין ״תכנות״ ל״הנדסת תוכנה״.
אין כמובן הגדרה פורמאלית, ואם תחפשו באינטרנט תמצאו שלל הגדרות והבחנות – בהם הרבה אתרי יח״צ / מכללות – לא גורמים שעוסקים בעולם התוכן הזה לעומקו.
בקרב אנשי תוכנה ותיקים, נראה שיש איזו הסכמה מקובלת של המושגים שעוזרת לעשות הבחנה בין שתי דיסציפלינות דומות, אך עדיין שונות. בפוסט זה, אני רוצה להעלות את הדברים על הכתב, בכדי לחדד אותם לאלו שאצלם ההבחנה עוד מעורפלת.
כמובן שזו הגדרה שלי, וגם בקרב אנשי תוכנה ותיקים – תוכלו למצוא וריאציות לפה ולשם.
נושא | תכנות (ברמה גבוהה) | הנדסת-תוכנה (ברמה גבוהה) | אף אחד מהם |
כתיבה שוטפת של קוד | כתיבת קוד מהירה – שמבצע את העבודה: תוך זמן קצר – הפיצ׳ר עובד. | כתיבת קוד סופר-ברור וקריא, שקל להיכנס אליו ולקרוא אותו. | כתיבת קוד סופר-מתוחכם המשתמש במגוון יכולות של שפת התכנות / ספריות. קוד שמעטים יכולים לכתוב – ומעטים יכולים להבין בקלות. |
מקרי קצה | חשיבה על מקרי-קצה שעלולים לצוץ וטיפול בהם. ההבנה אילו מקרים לא מספיק חשובים לצורך העיסקי וניתן להתעלם בהם (למשל: המשתמש לא יוכל לבצע את הפעולה = מגבלה מתוך החלטה) | מקרי הקצה מטופלים באופן שקל להבין אותם: מהו מקרה הקצה, ומהי ההתנהגות. ארגון הקוד של מקרי-הקצה הוא מבנה שמקל על תחזוקת המערכת לאורך זמן״הידע מוטמע בצורה מסודרת בתוך הקוד״ ולא ״ידע מפוזר באקראיות ברחבי הקוד״. | התעלמות ממקרי הקצה, או טיפול ב 100% מהם. שתי הנקודות הללו לא-מיטביות. |
שימוש בספריות צד שלישי | שימוש מושכל בספריות / שירותי צד-שלישי כאשר השימוש חוסך כמות משמעותית של פיתוח. | בחירת ספריות עם התאמה גבוהה לארכיטקטורת המערכת: מינימום חפיפה לקיים, מקסימום המשך של גישת המערכת לנושאים שונים (צורת תקשורת, שמירת נתונים, קונבנציות, אבטחה, וכו׳) | שימוש (לעתים מנומק) של ספריות צד-שלישי שלא בהכרח מקצרות בהרבה את זמן הפיתוח ולא בהכרח מתיישבות עם ארכיטקטורת המערכת. |
איתור תקלות | מומחה באיתור תקלות במערכת, יודע היכן לחפש, איך לחשוף ביעילות עוד מידע – ולפתור מהר את הבעיה. | מתכנן את המערכת כך שתקלות יקרו פחות, ואם הן קורות – יהיה קל לאתר אותן, ולא יזדקקו ליכולות מיוחדות של איתור תקלות. | ? |
כתיבת בדיוק | כתיבת בדיקה שבודקת ביעילות נקודה מסוימת ומוכיחה: עובד או לא עובד. | כתיבת בדיקה קלה לתחזוקה (למשל: מיעוט בתלויות, או ב mocks). כתיבת בדיקה ברורה דיה להיות סוג של תיעוד מה היכולות וההתנהגות הצפויה מהמערכת. | ? |
מטאפורה | בישול ארוחה טובה | הרצת מסעדה רווחית | בשלן חובב, שעסוק בעשיית רושם – אבל לא ממש מצטיין בלב המלאכה. |
תצורת עבודה אופטימלית | לבד. חברה קטנה שצריכה לזוז מהר. סט היכולות נדרש גם בחברה גדולה – אך הוא הופך למשני להנדסת תוכנה | ארגונים גדולים ובינוניים, הדורשים עבודה עמוקה-משותפת של גורמים רבים, ובמיוחד אם יש בהם מורכבות גדולה. היכן ששם המשחק הוא: ״לאפשר למערכת להמשיך ולנוע – בלי להיתקע״. | בעיקר ארגונים גדולים – שם חוסר-יעילות יכולה לפרוח. |
כמה נקודות:
- נוהגים לומר ש״הנדסת התוכנה מתחילה היכן שהתכנות נגמר״. לכאורה נשמע ש״הנדסת תוכנה״ היא הפרקטיקה ה״שווה״ / חשובה יותר. זה נכון, אבל חלקית: הנדסת תוכנה בלי יכולות תכנות טובות – לא שווה הרבה.
- זה לא שאדם מסוים הוא מפתח או מהנדס תוכנה. הם לא Mutually exclusive (בלעדיים). תיאור מדויק יותר הוא שכל איש-תוכנה הוא במידה מסוימת מתכנת, ובמידה מסוימת מהנדס תוכנה.
- משה אולי הוא 9/10 מתכנת, ו 3/10 מהנדס תוכנה.
- רינת היא אולי 6/10 מתכנתת, ו 8/10 מהנדסת תוכנה.
- כמובן שנרצה אנשים מעולים בשני התחומים – אבל זה לא תמיד מה שנקבל.
- הצורך בהבנה הזו היא כדי להעריך ולהכווין עובדים. למשל: אם מישהו הוא מתכנת מעולה (אבל מהנדס תוכנה חלש) – כנראה שלא יהיה נכון למנות אותו למוביל טכני או ארכיטקט. מנהלים לפעמים מתבלבלים, שאם אדם הוא מתכנת מצוין – זה לא מעיד על יכולות הנדסת התוכנה שלו.
- יתרה מכך, ״להטוטני קוד״ שמכירים את כל הטכנולוגיות החדשות, או כותבים קוד סופר-מתוחכם וחדשני, עשויים להיות במקביל לא מתכנתים טובים, ולא מהנדסים טובים. חשוב להבין את זה, ולהכווין אותם לערוץ פרודוקטיבי. לא להתרשם מהפונקציה המתוחכמת-גנרית-רקורסיבית-tailrec-פונקציונלית – שאף אחד לא מבין, וזה כנראה מצביע על זה שהיא פשוט לא טובה.
- כמובן שארגונים גְּדֵלִים צריכים להיזהר מריבוי מפתחים שהם לא מהנדסים טובים. אפשר להתקדם במהירות בהתחלה – ואז לחוות נפילה גדולה שבה המערכת כ״כ סבוכה / נכתבה אופורטוניסטית / קשה לתחזוקה – שהארגון פשוט ״תקוע״ וההתקדמות הופכת למאוד אטית וכואבת.
- בחוויה של סטארטאפ קטן, האלתור והשחרור המהיר של הפיצ׳ר – הוא הניצחון.
- הרבה מאוד ניצחונות תכנותיים – הופכים לניצחון פירוס הנדסי (״עוד ניצחון כזה, ואבדנו״) במיוחד אם הדומיין העסקי הוא מורכב.
- ההיפך הוא גם נכון: יש מהנדסי תוכנה שרק ירצו לעשות Refactoring ושיפורי תשתית ותחזוקה בלי סוף. אם לא תאזנו אותם – הם יכנסו ל Refactoring רקורסיבי בלי תנאי עצירה. (כלומר: אינסופי. שנה, שנתיים – והיד עוד נטויה).
לא תמיד קל להבחין מהי הדרך הטובה ביותר לעשות דברים.
יש לבחון כל הזמן את הדברים…
סיכום
אני מרגיש שאמרתי דיי את המובן מאליו, כך שאם הפוסט לא חידש לכם דבר – הכל בסדר.
אני משוכנע שיהיו גם לא מעט אנשים שההבחנה הזו תעשה להם סדר – והם יוכלו מעתה להיות רגישים יותר לשיח הכולל אמירות כגון ״זה תכנות טוב, אבל אין פה הנדסת תוכנה״.
שיהיה בהצלחה!
פסקת הסיכום ביטאה היטב את התחושה שלי, ממש הזדהיתי עם כל מילה.
הרגשתי שהבנתי עוד קודם את ההבדל אבל לא בצורה שאני מצליחה להסביר אותה למישהו אחר.
עכשיו זה באמת עשה לי יותר סדר ואני יכולה מעתה… (כמו שכתבת)
תודה רבה!
באמת עושה סדר בדברים. תודה רבה!
לא השארת לי ספק שאני הרבה יותר מהנדס תוכנה מאשר מתכנת!
אני חושב שיש נקודת אמצע בין שני הדברים שאתה אומר.. יש את “תכנות” כSKILL הנדרש גם למתכנת וגם למהנדס. לדברייך, זה סקיל נדרש לשניהם.. וברמה גבוהה יותר עבור המתכנת מאשר למהנדס. מה דעתך?
כמו כן,
כתבתי פרק בעניין שאני מוצא הבדל בין שני התחומים.. בדבר הזה שנקרא MODELING.
https://monksoldserver.com/2022/05/30/engineering-v-s-development-modeling-appendix/
יפה!!
לא אהבתי את המושגים פה, הם מאוד מבלבלים ולא הצלחתי להבין כלום.
אנלוגיה טובה זה כימיה והנדסה כימית, מה ההבדל ביניהם?
כימיה זה התאוריה, הנדסת כימיה זו פרקטיקה לאיך לבנות מערכות כימיות.
לדעת את ההיסטוריה של הענף ולהכיר בזה שהתוכנה נבנתה באקדמיה מענף המתמטיקה.
לכן ב”מדעי המחשב” לומדים הרבה מתמטיקה וב”הנדסת תוכנה” יש יותר חומרים הנדסיים להקמת מערכות.
זה הגיע מהאקדמיה קודם כל.
בתעשייה מחפשים בדרך כלל תפקיד מסוים אבל זה נטו הגדרת התפקיד, לעיתים אנשים לובשים כמה כובעים בתוך תפקיד אחד שאיננו מוגדר רק בתחום צר כמו “כתיבת קוד” אה אז אתה מתכנת.
טכנית “מתכנת” הוא אדם שמקודד, ז”א כותב קוד.
ומהנדס תוכנה הוא אדם שיודע להקים מערכות תוכנה כולל DEPLOYMENT, VERSION CONTROL וכדו’…
מקסים, עושה סדר בראש!
מה שאהבתי שזה לא “מי טוב יותר”
אלא – בחן את הצורך שלך בהתאם לפרויקט ולזמן