שְׁאֵלָה:
כיצד לנווט בעבודה עם תהליך פיתוח שאינו תומך בקוד נקי?
user1261710
2018-07-05 12:40:36 UTC
view on stackexchange narkive permalink

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

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

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

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

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

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

הקולגה הרגשי הוא זה שכתב את הקוד כזוטר?
לא.הזוטר שכתב את זה נעלם.לא בטוח אם הוא פוטר או עזב אבל הקולגה הרגשי מדי עובד כאן על פרויקט אחר.
אתה מבין מדוע הקולגה הזה נהיה אמוציונלי אז?
לא, אני לא.אני לא מבין מדוע אמירת קוד שמישהו אחר כתב אינו פועל לפי שיטות עבודה טובות יגרום לרגשות האלה.
כותרת השאלה כאן לא ממש עוקבת אחר השאלה בפועל.זה לא רק מפתח אחד, אלא צוות שלם, כל התהליך והניהול.אני מציע לשנות * "מפתח שהוא" * ל * "תהליך פיתוח שהוא" *.ניתן לעבוד עם מפתח יחיד, תהליך שלם הוא עניין אחר.
כן, אני נסער.אני יודע שאני מנסה לעשות את הדבר הנכון ולשפר את הדברים והאדם הזה מת נגדי משום מה.הקוד היה / הוא בלגן מוחלט.לא בטוח למה מישהו שלא כתב את זה יתעצבן גם אם אני רק אשאל מי כתב את זה.
ברור ש- @user1261710 למרות שהאדם לא כתב את הקוד המקורי, הם השקיעו זמן בתחזוקה וכנראה בתיקון באגים וכו '. אם אתה מציע שיש הרבה דברים לשיפור ובסיס הקוד הוא בלגן בלתי קריא, אתה רומז שלךעמית לעבודה הנוכחי לא עשה את עבודתו.
אתה מניח שהקוד המקורי לא ניתן לתחזוקה לא בהכרח מתקיים.
חָמֵשׁ תשובות:
user44108
2018-07-05 12:49:42 UTC
view on stackexchange narkive permalink

זו התשובה שלך ממש כאן.

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

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

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

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

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

FunnyJava
2018-07-05 13:31:05 UTC
view on stackexchange narkive permalink

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

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

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

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

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

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

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

בהצלחה!

Simon B
2018-07-06 01:41:11 UTC
view on stackexchange narkive permalink

כשמסתכלים מנקודת המבט של הניהול, קוד ענק מחדש של

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

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

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

Abigail
2018-07-06 22:23:30 UTC
view on stackexchange narkive permalink

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

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

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

Dang Nguyen
2018-07-05 13:13:49 UTC
view on stackexchange narkive permalink

פשוט המשך הלאה, אתה לא עץ!

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

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


שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 4.0 עליו הוא מופץ.
Loading...