בתשובה להאייל האלמוני, 03/11/10 14:50
 |
|
 |
||
|
||||
 |
האמנם תחומי התמחות הם קשים יותר ללמידה? אתה יכול לתת דוגמה או שתיים? אני מניח שנשארים בתוך התחום הכללי של תוכנה, ולא קופצים לפיזיקה או תכנון מעבדים; משהו שמקביל לקורס באקדמיה ולא לתואר. עיבוד מקבילי הוא אולי דוגמה, אבל זה בגלל שלא מדובר רק בתחום ידע אלא בצורת חשיבה שונה. אם אני חושב על פרוטוקולי תקשורת, או אפליקציות אינטרנט, או GUI - אז נדמה לי שמהנדס טוב יכול ללמוד אותם בערך באותה קלות או קושי של לימוד שפה חדשה. אגב, בשני הראשונים נגעתי רק לרגעים קצרים ומרחוק, בשלישי יותר אבל רק בזווית צרה. |
 |
 |
 |
|
|
|
||
|
||||
|
אני לא יודע אם "תחומי התמחות הם קשים יותר ללמידה". אני יודע שיש מהנדסים שמתאימים יותר לצורת חשיבה הנחוצה בתחום מסוים. >>> עיבוד מקבילי הוא אולי דוגמה, אבל זה בגלל שלא מדובר רק בתחום ידע אלא בצורת חשיבה שונה. גם "עיבוד אותות" זו צורת חשיבה שונה, ו־device drivers זו צורת חשיבה שונה, ו־embedded systems זה משהו אחר לגמרי. הכרתי מהנדסים שידעו לבנות gui באופן שעורר את קנאתי - יותר יפה ובעיקר יותר פונקציונלי ממה שיכולתי לחלום, וברבע הזמן שהיה לוקח לי. לעומת זאת עם הקוד שהם כתבו בלב המערכת לא היה מה לעשות חוץ מאשר לעטוף בשטר של עשר לירות ולזרוק למקום בו השמש לעולם לא זורחת. אולי אפשר להשוות זאת להבדל בין מהנדס בניין ומעצב פנים, רק שבענף שלנו קוראים לשניהם "מהנדס תכנה" ובמקרים רבים הם משתמשים באותה שפת תכנות. לעומת זאת אין שום קשר בין זה ובין שפה. מעולם לא ראיתי מישהו שעשה עבודה טובה בשפה אחת וגרועה באחרת. מי שהתוצרת שלו גרמה לי סחרחורת ובחילה, זה עבד בשלוש שפות באותה מידה; ומי שהרשים אותי בבהירות, פשטות ואלגנטיות של התוצרת זה נשאר משפת אסמבלי דרך ג'אווה ועד פייתון. |
|
|
|
|
|
|
||
|
||||
|
הגיוני. | |
|
|
|
|
|
||
|
||||
|
בעניין "מעולם לא ראיתי מישהו שעשה עבודה טובה בשפה אחת וגרועה באחרת" - זה נכון בד"כ, אבל הנה דוגמא הפוכה: גייסתי פעם עובד ששלט היטב בפייתון והיה מהיר כברק בשפה זו. הוא גם פתר בע"פ חידות מתמטיות/אלגוריתמיות מהר יותר מכל מרואיין שהיה לי. מסיבות אלו ואחרות גייסתי אותו כאיש אלגוריתמים למימוש אזורי קוד תובעניים (מבחינת ביצועים) בשפת ++C. לאחר חודשיים של עבודה הסתכמו הישגיו בקרוב לאפס. לבקשתי מן הממונה עליו לרדת לפשר העניין, התברר שהבחור סובל מהפרעת קשב. הוא הסביר שיש לו משהו כמו עשר דקות (לפעמים קצת יותר) בהן הוא חד ומהיר, מה שמספיק למשימות קטנות ואפילו ביינוניות בפייתון, כמו גם לפתרון חידות אלגוריתמיות מן הסוג שנתתי לו. לאחר מכן, הוא זקוק ללפחות שעה של "התרעננות". מאחר וב++C המשימות הן בד"כ חלק מפרוייקט גדול, די בניסיון להכנס למשימה, תוך בהבנת מקומה הנכון בפרוייקט והבנה/היזכרות באופן בו צריך לבצעה, כדי לעבור את זמן הקשב שלו. "מדוע אין הוא לוקח ריטלין" שאלתי את המנהל? התשובה שבאה הוא שהבחור בדק באינטרנט וחושש שהריטלין מרעיל אותו אז הוא מנסה בלעדיו. "תגיד לו שהניסיון נכשל והטענות נגד הריטלין הן אמונות טפלות שמופצות ע"י כת של עובדי אלילים, ואם הוא רוצה להמשיך לעבוד כאן כדאי לו שיחזור לקחת" (או מה שסביר יותר - גירסה עדינה של זה). ואכן כעבור כמה זמן היה שיפור מסויים (אם כי לא מספיק). |
|
|
|
|
|
|
||
|
||||
|
הו הא. שעה התרעננות אחרי עשר דקות עבודה? זה לא מתכנת פייתון. זה עובד הסתדרות! דוגמה יפה, אבל אתה רק מחזק את טענותיו של הוגג. הרי מה הקשר בין פייתון לבין הקשיים של המתכנת הנ"ל? הנ"ל יהיה מפתח גרוע גם במימוש פרויקטים מסוימים בשפה זו. במקום העבודה הקודם שלי, בו הרוב המוחלט של המערכות נכתב בפייתון, המתכנת הנ"ל לא היה מוצא לא את ידיו ולא את רגליו. פייתון היא שפה של ממש ולא סתם שפה לכתיבת סקריפטים קצרים או משהו שרק ניתן להדגים איתו שעשועים ופתרון חידות אלגוריתמיות קצרות. ניתן לממש בה אפליקציות שלמות, תשתיות ו/או פרוייקטים מאוד מורכבים. |
|
|
|
|
|
|
||
|
||||
|
אני מניח שאתה צודק. להלן המשך אותו המקרה: לאחר שהחלטתי לפטרו, עיכב הבוס שלי את מימוש ההחלטה, לפחות עד שנמצא מישהו במקומו. בינתיים העברתי את הבחור למחלקת המחקר שקירטעה מאז המתכנת היחיד בה (אני) קודם. הרעיונות שהבחור הגה שם והמימושים להם הקפיצו אותה שנות אור קדימה1. אנקדוטה הקשורה בבחור: לאחר שלב הראיונות, כשהתקשרתי לממליצים, טען אחד מהם שהנזקים שהבחור עשה אצלם נוראים עד כדי כך שהוא אפילו לא יכול לספר לי. 1 פיסיקה הוא לא ידע (: |
|
|
|
|
|
|
||
|
||||
|
סיפור מעניין ומאלף. שאלה מעניינת (כלומר מעניינת אותי) היא האם לדעתך ההבדל בין הביצועים המרשימים של מהנדס זה במשימה אחת מול ביצועים עלובים במשימה אחרת קשורים יותר לשפה\סביבה, או לטיב המשימות עצמן? גם אני הזכרתי מהנדסים (למשל החתום מעלה) עלובים ב-gui וטובים בדברים אחרים וההפך - אבל במקרה זה מעבר שפה לא שינה לא את הטוב ולא את הרע. |
|
|
|
|
|
|
||
|
||||
|
אני חושב שהצלחתו של הנ"ל בפייתון נבעה מכך שבשפה זו ישנו יחס גבוה מאוד של תפוקה ביחס להשקעה, גם בזמני עבודה קצרים, המתאימים לאורך הקשב שלו. משום כך לדעתי הוא גם התמחה בשפה זו, ולא למשל בג'אווה או ++C בהן הדבר בד"כ אינו ניתן, אך הן כן טובות יותר לפרוייקטים גדולים (מסויימים) וכמובן, מבחינת ביצועים (מהירות, צריכת זיכרון). התשובה משום כך היא שהסיבה הראשונית היא כאן טיב המשימות, ולא השפה. | |
|
|
|
|
|
||
|
||||
|
אני מכיר כמה פרויקטים (ואפילו מוצלחים) בפייתון, אולי לא "גדולים" אבל משהו כמו 50KLOC (שכנראה שקול לפחות ל 150KLOC, ויש אומרים 300, בג'אווה). מאד יתכן שאותו מהנדס היה נכשל גם שם. מצד שני יש סוג משימות מהאופי של "פגע וברח" גם בפרויקטים גדולים וסבוכים ב ++C ("תמצא איפה הבעיה ותגרום לנביילה הזו לרוץ פי שלוש יותר מהר") - שבהחלט יכולות להתאים למהנדסים מסוימים שלא מסוגלים לתכנן ולהריץ פרויקט שלם, אפילו קטן. |
|
|
|
|
|
|
||
|
||||
|
אלו בדיוק הבעיות המצומצמות אותן הוא קיבל. אבל כאן נכנס גורם נוסף, לדעתי הספקולטיבית מאוד: אצל חלק מבעלי בעיות הריכוז הן מחמירות באופן קיצוני כאשר הם עוסקים בדבר (שפה במקרה זה) שאינו מלהיב אותם, גם אם הם מאוד היו רוצים לסיים את המשימה. | |
|
|
|
|
|
||
|
||||
|
ג'אווה? מילא מהירות, אבל טובה בצריכת זיכרון!? | |
|
|
|
|
|
||
|
||||
|
מה שהיה לי בראש כשכתבתי זאת היא השפה בה אני עובד בשבועיים האחרונים (VBA) ופייתון. לא בדקתי אז אני חוזר בי מן הטענה שבג'אווה ניצול הזיכרון טוב יותר מאצלן. | |
|
|
|
|
|
||
|
||||
|
ג'אווה אכן טובה בצריכת זיכרון. לא סתם טובה, ג'אווה מתמכה בצריכת זיכרון! צריכת (עוד ועוד) זיכרון זה אחד מהפיצ'רים המרכזיים ביותר של השפה. | |
|
|
|
|
|
||
|
||||
|
תסריט בו העובד הזה היה מגיע אל מעסיק שלא היה מצליח להבין מהן נקודות החוזק והחולשה שלו הוא תסריט סביר. היו מתאכזבים ממנו שוב ושוב ומפטרים אותו. בקלות היו יכולים לקטלגו כמהנדס תוכנה כושל שאת התוצרת שלו אפשר רק לעטוף בעשר לירות ולזרוק לפח. מזל שהוא הגיע אליך. בין השאר, הסיפור הזה מלמד אותנו את החשיבות והמרכזיות שיש להחלטות ההנהלה בהצלחתו או כשלונו של העובד (ושל פרוייקטי תוכנה באופן כללי). אם היה לי שקל על כל פעם שראיתי קוד גרוע שנכתב בגלל מנהלים גרועים ע''י מהנדסים מוכשרים (שמוצאים את עצמם כותבים ובוכים) הייתי יכול לעשות אקזיט. |
|
|
|
|
|
|
||
|
||||
|
איך מסתדרים עם הפרעות קשב וריכוז במקום העבודה? | |
|
|
|
|
|
||
|
||||
|
באופן מוזר יצא לי לראות כמה פעמים קוד של מהנדסים (ולפעמים גם צוותים שלמים) שעברו משפה "נמוכה" לשפה "גבוהה" (ז"א מ-c ל-c++ ומ-C++ לג'אווה - הכרתי גם צוות שעבר כולו מדלפי לג'ווה אבל בגלל שאני לא מכיר דלפי אז אני לא יכול לדעת אם זאת הסיבה שהקוד שלהם היה כל כך מוזר), ובהחלט אפשר להבחין בזה. יש דברים שמהנדס ששולט בשפה מסויימת לא יעשה (לא שהם בהכרח לא נכונים או לא עובדים, נגיד להגדיר את כל המשתנים בתחילת הפונקציה ולא בסקופ שלה, אבל הקוד שנוצר הוא פחות קל לתחזוקה) ויש דברים שמי שלא מכיר את השפה מספיק טוב יפחד לעשות (למשל exception בג'אווה, וכמובן שאפשר לעקוף את זה על ידי החזרת ערך, אבל...) בלי צידוק מספק. שינוי ההרגלים הזה לוקח זמן, ועולה כסף, וכשמדובר על צוות שלם אז הרבה פעמים ההרגלים האלה גם לא משתנים (זה גם תלוי באופי של הצוות) אחרי שנים. | |
|
|
|
|
|
||
|
||||
|
מהניסיון האישי שלי ובהכללה גסה: אנשים עם ניסיון המתרכז בשפות "גבוהות" או אפילו חסרי ניסיון לחלוטין, מסתגלים מהר יותר לכתוב קוד נכון יותר ב - python מאשר מפתחים עם ניסיון מסוים או רב שנים ב - ++C. לא פשוט לדרוש ממפתחים שרגילים לכתוב בצורה מסוימת לכתוב כמו כל שאר החבר'ה על פי המלצות PEP 8. היה אפילו אחד שהתעקש, כמו פרד, להוסיף נקודה פסיק בסופי שורות פקודה, כאילו הסימן הזה מחובר אצלו במקלדת למקש ה - enter. |
|
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |