מעבר מדוט נט לC++ לינוקס וPYTHON

[dragon201]

מעבר מדוט נט לC++ לינוקס וPYTHON

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

איפה הקאצ'?

אני מתכנת C# דוט נט 7 שנים, עשיתי סרבר קליינט ווינדוס ורוב מה שיש להתנסות בו בתחום. מעולם לא הייתה לי השכלה במדמ"ח - כך שעשו לי טובה (ובפריפריה זה אישו) ששקלו את מועמדותי.
המשרה היא על מערכת בת 10 כתובה בc++ וPython על גבי לינוקס. והחברה שם עם כוונות טובות אבל אין להם מושג מה זה "קוד נקי" או AGILE.

האם לדעתכם C++ לינוקס וPYTHON זה לימוד ששווה לדעת בשביל מתכנת דוט נט. האם זו השלמת ידע ואוכל בעתיד לשלב וזה ימצב אותי יותר טוב בשוק?
או האם זה בזבוז זמן טוטלי ועדיף שאחכה למשרה בתחום שלי. בד"כ אומר שאצטרך להתפשר על תנאים או מרחק מהבית.

 

[vinney]

ללמוד C++ בחברה שלא יודעת מה זה "קוד נכון"

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

 

[ipv6]

צריך להבין מה זאת החברה

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

אחר שתכיר את הסינטקס של CPP, שווה לקרוא את סדרת הספרים effective c++. אלו באמת ספרים טובים שכתובים טוב ומתרכזים במה שחשוב.

 

[cppcpp]

עדיף את ה Effective Modern C++ לא? הוא מעודכן יותר...

 

[choo]

יש כמה נקודות שונות בשאלה שלך:

&nbsp
לגבי מעבר הסביבה הזה (בעיקר מחלונות ללינוקס, אבל גם החלפת השפה) - זה מעבר שצריך לעשות אותו ברצינות ובלב שלם, ולא בתור פשרה זמנית. לוקח מספר שנים להגיע לרמת מומחיות בסביבה החדשה, שדומה למה שהיה לך בסביבה הישנה ולחוש שוב כמו "דג במים" - ואם תעשה את זה בחצי לב, אתה עלול להיתקע במצב שבו אתה לא באמת לומד כמו שצריך את הסביבה החדשה, וזה יכול לפגוע בך מבחינה מקצועית (גם התרחקת ממה שאתה שולט בו, וגם לא יצרת מומחיות ראויה בסביבה החדשה).
&nbsp
שנית, התחושה שלי היא שבזמן שבאזור המרכז agile הוא הבון-טון, באזור הצפון (ופה אני מנחש שאתה מאזור הצפון - אנא תקן אותי אם אני טועה) זה לא ממש תפס (מסיבות שונות) - אבל בניגוד לך - אני רואה בזה סוג של יתרון (בכל זאת - אני מאזור הצפון ולא חסרון. בדיוק כמו שהמעבר משיטות פיתוח מסורתיות לשיטות פיחות אגיליות דורש mind switch - כך גם המעבר מהכיוון השני - הרבה יותר חשיבה ותיכנון קדימה, הרבה פחות דינמיות (=רעשים) במהלך העבודה.
&nbsp
לגבי "קוד נקי" - האם אתה מדבר על "לא מפתחים קדימה כל עוד יש באגים" - או שאתה מתכוון למובן הפשוט של המילה - שלא עושים code reviews, אין שום סטנדרט וכותבים קוד מאוד מלוכלך "העיקר שיעבוד?" אם זה המקרה השני - זה לא טוב, וייתכן שזה מקום שלא כדאי להתקרב אליו. לבחור מקום עבודה לפי "השם של החברה" זה לא רעיון מאוד מוצלח מבחינה מקצועית..

 

[ipv6]

אני מסכים איתך

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

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

[1] סטנדרטים וReview זה דברים לא אובסולטיים. יכולים להגיד לך "אצלנו יש תהליך Code Review מאד ארוך ומסודר" ואתה תגלה כשתגיע שהארוך מסודר שלהם זה פחות מqucik and dirty בסטנדרטים שלך.

 

[טרול המתכנן]

זה די מיידי להפריד מוץ מתבן

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

 

[dragon201]

אני עושה את זה בחצי לב - מטרתי לחזור לדוטנט בתוך החברה

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

חד וחלק אני עושה את זה בשביל החברה (השיפור בתנאים והערך המוסף לקו"ח) ולא בשביל התפקיד. בהזדמנות הראשונה כשיהיה לגיטימי אחפש להמשיך בתוך החברה במחלקה אחרת שיש בה דוטנט או לפחות ג'אווה או ווינדוס עם C++ ברמה גבוהה יותר.

קצת לחדד על המחלקה:
1. אין Agile זה understatement. הם טוענים שעובדים Agile כשבתכלס הספרינטים של 4+ שבועות, הצ'ק אינים ארוכים, איש הפרודקט היחיד הוא גם scrummaster ומפתח. אין QA (הלקוח מחזיר רג'קטים) כאילו מדובר במוסך ולא חברת הייטק.

2. קוד נקי הכוונה - קוד קריא, הקפדה על naming וdesign patterns. קבצים ומתודות קצרים שעושים דבר אחד ברור. נקודות extention והפשטות.

3. הבנתי שלא ממש כותבים C++ אלא framework שנקרא QT. זה טוב כי זה יותר דומה לVS ויש GC שמשחרר זיכרון. פחות טוב בנוגע לניסיון הנצבר אצלי.


לסיכום:

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

חסרונות:
- צריך לסחוב שנה וחצי שנתיים כשאני לא עושה משהו שאני טוב בו ומעניין אותי

 

[טרול המתכנן]

אין GC ב-QT. שלא תתאכזב

 

[choo]

נשמע שאסור לך לקחת את המשרה הזו אם אתה "חפץ חיים"

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

 

[ipv6]

גם לגוגל ומיקרוסופט

אין QA, לפחות בחלק מהפרויקטים\מחלקות.
בדיקות אוטומטיות יש.

 

[vinney]

אני מכיר מישהו שעובד בQA בגוגל...

מה שיש במייקרוסופט זה SET, שזה Software Enginner in Test, שזה בתורו שם מכובס ל"טסטר". הם אכן מסתמכים מאוד על אוטומציה, אבל זה לא נכון להגיד שאין להם QA.

 

[ipv6]

ואני מכיר כמה וכמה

פרויקים\מחלקות בגוגל שאין להם QA.
כנ"ל במיקרוסופט, בארץ.

 

[user32]

האמת שגם אני מכיר כמה

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

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

יש דברים מוזרים בעולם. ככה זה.

 

[ipv6]

אם מה שרשמתי

לא היה נכון, לא הייתי כותב את זה..

 

[טרול המתכנן]

למשל במחלקה המשפטית אין QA.

 

[choo]

הוא אמר "אין QA ואין בדיקות אוטומטיות"

&nbsp
הקוד כתוב בצורה לא נקיה וזה לא מעניין אף אחד, וככל הנראה גם אין code reviews. בעיני, ללכת לעבוד במקום כזה, כיום, זה כל כך שנות ה-90...

 

[ipv6]

צריך להבדיל בין מצב

שלא עושים בו בדיקות למצב שאין בו אנשי QA.
עבדתי במקום שהיו בו Unit Tests, בדיקות אינטגרציה (שבודקות אינטגרציה בין חלקים שונים) ובדיקות מערכת (שבודקות את כל המוצר) אבל לא היה אף אחד שהתפקיד שלו הוא "איש QA\בודק תוכנה".

וסדר של קוד, זה לא דבר אבסולוטי

 

[choo]

אכן, צריך להבדיל - והוא כבר הבדיל. למה ההתעקשות?

 

[user32]

מעבר למה שכתבו קודמיי

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

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