תובנות על עצמי בעת בניית פרוייקט גמר

[imnotthatcreative]

שלום,

רציתי להתייעץ איתכם בבקשה.

אני נמצא בשלב פרוייקט הגמר שלי(מדמ"ח).

הפרוייקט בתחום הפיתוח מונחה עצמים- מתמקד בהנדסת תוכנה- Design patterns וכו'.

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

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

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

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

שורה תחתונה- אני פחות נהנה ממבנה הקוד, או הפרוייקט, אלא ממה שהקוד עצמו עושה.

האם התובנות האלה יכולות לשמש אותי בשביל לבחור תת-תחום בפיתוח?

או שאולי- בחרתי בתחום לא נכון?

אשמח לתובנות,
תודה.

 

[קלייטון.ש]

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

 

[חזי2003]

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

לגבי מחשבה על שינויים עתידיים, גם פה, דרך האמצע שנראית לי מוצלחת היא לעקוב אחרי ה-best practices המקובלים בתחום (למשל, בשאלות איך לעצב API, וכדומה), אבל אם מגזימים בזה, זה בדיוק המקום שכדאי להכיר את העיקרון ש-XP מלמדת אותנו: YAGNI.

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

 

[choo]

+1 לגבי מה שכתב חזי, עם תוספת:

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

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

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

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