מיהו מהנדס תוכנה? הנדסת תוכנה לעומת תכנות "סתם".

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

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

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

חשיבה הנדסית - חיפוש פתרונות יישומיים

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

• אילו בעיות עלי לפתור?
• מה עוד אתה יכול לעשות מלבד כתיבת קוד כדי לפתור אותם?
• מה אני יכול לעשות כדי להקל על המשימות האלה עם האפליקציה?

איכות התוכנית ואיכות הקוד

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

סביבות ובדיקות

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

עלות ויעילות

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

התמקד בחוויית משתמש

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

• בעת עיצוב טפסי הזנת נתונים כגון דואר אלקטרוני, תוכנית טובה צריכה להתעלם מהמקרה של כתובת הדואר האלקטרוני. זה לא אמור לזרוק שגיאה אם ​​מקש CAPSLOCK נלחץ מכיוון שכתובת האימייל היא ייחודית באותיות קטנות. אם התוכנית מקבלת כתובת דוא"ל חדשה כקלט, בדוק אותה בשלב מוקדם בתהליך הקלט כדי להתריע בפני המשתמש שהוא משתמש בפורמט כתובת שגוי. פתרון זה כולל גם בדיקות ברורות כמו הסימן "@" החסר, וגם בדיקות לא ברורות כל כך, כגון בדיקת סדר שגוי של תווים כמו "gmail.ocm"

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

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




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

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

אמינות, ביטחון ובטיחות

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

כלים נדרשים

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

האבולוציה של הנדסת תוכנה

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