ฉันจะบอกผู้จัดการโครงการของฉันหรือนักพัฒนาชั้นนำได้อย่างไรว่า codebase ของโครงการนั้นต้องการการทำงานที่จริงจัง

ฉันเพิ่งเข้าร่วมทีมพัฒนาขนาดเล็กที่ค่อนข้างได้ทำงานในโครงการเป็นเวลาหลายเดือนถ้าไม่ใช่ปี เช่นเดียวกับนักพัฒนาส่วนใหญ่ที่เข้าร่วมโครงการฉันใช้เวลาสองสามวันแรกในการตรวจสอบ codebase ของโครงการ

โครงการ (บรรทัดภายในของโปรแกรมประยุกต์ทางธุรกิจ ASP.NET WebForms ขนาดกลางถึงขนาดใหญ่) คือการขาดคำที่มีความหมายมากขึ้นหายนะ มีสามปัญหาที่เห็นได้ชัดเจนทันทีกับมาตรฐานการเข้ารหัส:

1. มาตรฐานหลวมมาก มันอธิบายเพิ่มเติมเกี่ยวกับสิ่งที่ไม่ควรทำ (อย่าใช้สัญกรณ์ฮังการี ฯลฯ ) มากกว่าสิ่งที่ต้องทำ
2. มาตรฐานไม่ได้ปฏิบัติตามเสมอไป มีความไม่สอดคล้องกันด้วยรหัสการจัดรูปแบบที่มีทุกที่
3. มาตรฐานไม่เป็นไปตามหลักเกณฑ์ลักษณะของ Microsoft ในความคิดของฉันไม่มีค่าเบี่ยงเบนจากแนวทางที่กำหนดโดยนักพัฒนาของกรอบงานและผู้มีส่วนร่วมที่ใหญ่ที่สุดในการกำหนดภาษา

สำหรับจุดที่ 3 บางทีมันทำให้ฉันกังวลมากขึ้นเพราะฉันใช้เวลาในการรับMCPDของฉันโดยให้ความสำคัญกับเว็บแอปพลิเคชัน (โดยเฉพาะ ASP.NET) ฉันยังเป็น Microsoft Certified Professional คนเดียวในทีม เนื่องจากสิ่งที่ฉันได้เรียนรู้ในการเรียนการสอนด้วยตนเองและการเรียนรู้นอกสถานที่ทั้งหมด (รวมถึงการเตรียมการสำหรับการสอบเพื่อรับใบรับรอง) ฉันยังเห็นหลาย ๆ ครั้งในรหัสของโครงการซึ่งสิ่งต่าง ๆ ไม่ได้ทำใน วิธีที่ดีที่สุด.

ฉันอยู่ในทีมนี้มาหนึ่งสัปดาห์แล้ว แต่ฉันเห็นปัญหามากมายเกี่ยวกับ codebase ของพวกเขาที่ฉันคิดว่าฉันจะใช้เวลาต่อสู้กับสิ่งที่เขียนไปแล้วเพื่อทำสิ่งต่าง ๆ ใน "ทางของพวกเขา" มากกว่าที่ฉันจะเป็น ทำงานในโครงการที่ยกตัวอย่างเช่นปฏิบัติตามมาตรฐานการเข้ารหัสที่ยอมรับกันอย่างแพร่หลายรูปแบบสถาปัตยกรรมและแนวปฏิบัติที่ดีที่สุด สิ่งนี้นำมาสู่คำถามของฉัน:

ฉันควร (และถ้าเป็นเช่นนั้นฉันจะ) เสนอให้ผู้จัดการโครงการและทีมของฉันเป็นผู้นำได้หรือไม่ว่าโครงการต้องได้รับการปรับปรุงใหม่อย่างมาก

ฉันไม่ต้องการที่จะเดินเข้าไปในสำนักงานของพวกเขาโบกมือรับรอง MCTS และ MCPD ของฉันไปรอบ ๆ โดยบอกว่า codebase ของโครงการของพวกเขาไร้สาระ แต่ฉันก็ไม่ต้องการที่จะอยู่เงียบ ๆ และต้องเขียนโค้ด kludge บนรหัส kludgey ของพวกเขาเพราะฉันต้องการเขียนซอฟต์แวร์ที่มีคุณภาพและฉันต้องการให้ผลิตภัณฑ์สุดท้ายมีความเสถียรและบำรุงรักษาได้ง่าย

คุณสามารถใช้เวลาในการพิจารณาคดีของคุณ หรือคุณสามารถใช้เวลาทำความสะอาดเมื่อคุณไปด้วย

เลือกหลักการรูปแบบและวิธีปฏิบัติในการพัฒนาซอฟต์แวร์ที่สะอาดและคล่องตัว Agileและนำสิ่งที่คุณเรียนรู้ไปใช้ในระบบ ในที่สุดผู้คนจะสังเกตเห็น (ดีขึ้นหรือแย่ลง)

แก้ไข และตรวจสอบการทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม

จากสิ่งที่คุณอธิบายดูเหมือนว่าปัญหาส่วนใหญ่เกี่ยวกับการไม่ปฏิบัติตามมาตรฐานการเข้ารหัสและปัญหาการตั้งชื่อ นั่นคือไม่เกิดภัยพิบัติโดยไกล สำหรับการเปรียบเทียบนี่เป็นหายนะสำหรับจริง

บางทีคุณอาจเคยชินและต้องการมาตรฐานที่สูงใช่ไหม ในกรณีนั้นการเบี่ยงเบนจากความสมบูรณ์อาจถือได้ว่าเป็นความล้มเหลว นั่นคือกับดักที่ง่ายต่อการตกลงเมื่อความต้องการของคุณสูง แต่เป็นสิ่งสำคัญที่จะต้องเก็บมุมมองเกี่ยวกับสิ่งต่าง ๆ

ฉันขอแนะนำให้คุณพูดคุยเกี่ยวกับสิ่งนี้เป็นการปรับปรุงและช่วยให้ทีมปรับปรุงแนวทางของพวกเขาและโค้ชพวกเขาให้เริ่มใช้มันจริง ฉันชอบที่จะใช้คำจำกัดความของเสร็จเป็นเกณฑ์มาตรฐานที่มีคุณภาพและการสร้างหนึ่งเป็นทีมที่ยอดเยี่ยมสะเดาะเคราะห์ด้วยตัวเอง แต่ฉันไม่คิดว่าคุณควรทำมากกว่านี้อย่างน้อยก็ไม่ควรเป็นสมาชิกทีมคนใหม่

แน่นอนว่าอย่าไปโบกมือให้กับ MCSD ผู้คนจะหัวเราะเยาะคุณอย่างตรงไปตรงมา MS certs นั้นเหมาะสำหรับคนที่ชื่นชอบ แต่พวกเขาก็ไม่ได้เป็นมืออาชีพเลย!

เข้าร่วมทีมใหม่อย่างค่อยเป็นค่อยไปมองหาโอกาสในการแนะนำการเปลี่ยนแปลงเมื่อคุณไป

รอจนกว่าคุณจะได้รับการวางที่ดินก่อนที่จะหลุดรหัสทีม

คุณอาจพิจารณาว่าปัญหาคือคุณ ไม่มีสามสิ่งที่คุณกล่าวถึงมีค่าของการทำงานซ้ำทั้งหมดของแอปพลิเคชัน พวกเขาเป็นเพียงรายละเอียด nitpicky

จำไว้ว่าเป้าหมายของแอพพลิเคชั่นนั้นไม่ได้มีรหัสที่สวยงามมันเป็นการแก้ปัญหาทางธุรกิจ แน่นอนว่ามันเป็นเรื่องดีที่มีรหัสที่สอดคล้องและเป็นไปตามมาตรฐานที่ดี แต่การขาดรหัสดังกล่าวนั้นไม่มีเหตุผลที่จะทิ้งรหัสฐานทั้งหมด เพียงเพราะเครื่องยนต์มันไม่ได้หมายความว่าจะต้องสร้างใหม่

ดูทุกคนเกลียดโค้ดเบสทุกอันที่พวกเขาไม่ได้เขียน ในความเป็นจริงถ้าคุณรอสามปีและดูรหัสของคุณเองคุณก็จะเกลียดมันเช่นกันและคิดว่ามันต้องเขียนใหม่ทั้งหมด ความจริงก็คือมันไม่ได้ หากคุณไม่สามารถทำกรณีที่ใช้เวลาหลายเดือนในการสร้างโค้ดที่ทำให้คุณพึงพอใจแทนที่จะสร้างคุณสมบัติเพื่อเพิ่มมูลค่าทางธุรกิจคุณอาจเห่าต้นไม้ผิดไป

ไม่มีอะไรบอกว่าคุณต้องเขียนโค้ด kludgy เพียงเพราะอาจมีบางอย่างใน codebase และไม่มีสิ่งใดที่บอกว่ารหัส IS kludgy เพียงเพราะมันไม่ได้เป็นไปตามสไตล์สัตว์เลี้ยงของคุณ เพียงแค่ปรับโครงสร้างตามที่คุณทำตามส่วนต่างๆที่คุณทำงานและเขียนโค้ดที่ดีเมื่อคุณทำงานกับสิ่งใหม่ ๆ

สิ่งเหล่านี้ก็โอเคที่จะต้องกังวล แต่ถ้าคุณยังใหม่กับทีมงานยังไม่เขย่าเรือจนกว่าคุณจะสร้างความน่าเชื่อถือกับพวกเขา

ดูเหมือนว่าคุณได้เลือกสิ่งเล็ก ๆ น้อย ๆ สามอย่างที่ทำให้หงุดหงิด มีสิ่งอื่น ๆ ที่ฉันต้องกังวลเพิ่มเติมเกี่ยวกับ:

• รหัสมีเอกสารครบถ้วนหรือไม่
• รหัสเป็นไปตามข้อกำหนด / เอกสารการออกแบบหรือไม่?
• รหัสทำงานหรือไม่
• มันง่ายที่จะเข้าใจว่ารหัสทำอะไร?
• คุณกำลังพิจารณาที่จะส่งโค้ดขนาดใหญ่นี้ไปยัง TheDailyWTF หรือไม่?

คุณอยู่ที่นั่นมาหนึ่งสัปดาห์แล้วเหรอ? ฉันไม่แน่ใจว่าคุณรู้เพียงพอที่จะทำข้อเสนอใด ๆ กับผู้จัดการโครงการ แม้ว่าคุณจะมีข้อสงสัยว่ารหัสและการปฏิบัติของทีมนี้ "ไม่ดี" วิธีที่ดีที่สุดในการมีอิทธิพลต่อสิ่งเหล่านี้เมื่อเวลาผ่านไปก็คือค่อยๆได้รับความไว้วางใจและความเคารพจากพวกเขา การเข้าสู่โครงการและหลังจากหนึ่งสัปดาห์บอกกับทีมว่ารหัสของพวกเขาจำเป็นต้องเขียนใหม่ไม่ใช่วิธีที่ดีในการรับความไว้วางใจและความเคารพ

ในช่วงสองสามเดือนแรกของคุณให้เน้นที่การเป็นตัวอย่างที่ดีขึ้นและถามคำถามว่าทำไมพวกเขาถึงทำสิ่งต่าง ๆ ด้วยวิธีบางอย่าง ระมัดระวังเกี่ยวกับน้ำเสียงของคุณเมื่อคุณถามคำถามเหล่านี้ ถ้าคุณเจอในฐานะคนใหม่ "รู้ - มัน - ทั้งหมด" ไม่มีใครจะฟังความคิดเห็นของคุณในภายหลังเมื่อคุณอยู่ในตำแหน่งที่มีอิทธิพลต่อวิธีการทำสิ่งต่าง ๆ

เมื่อเวลาผ่านไปหากรหัสของคุณเป็น "ดีกว่า" นักพัฒนาซอฟต์แวร์รายอื่นจะเห็นว่า พวกเขาจะเริ่มเข้ามาหาคุณเพื่อเป็นแหล่งช่วยแก้ไขปัญหาของพวกเขาจากนั้นขอคำแนะนำจากคุณเกี่ยวกับวิธีที่พวกเขาควรทำสิ่งต่าง ๆ ณ จุดนี้คุณจะอยู่ในตำแหน่งที่ยอดเยี่ยมที่จะบอกทีม (และการจัดการ) ความคิดเห็นของคุณเกี่ยวกับมาตรฐานการเข้ารหัสและสิ่งที่คล้ายกัน กระบวนการนี้ใช้เวลานานเท่าใดจะแตกต่างกันไปตามองค์กร มันอาจเป็นเพียงไม่กี่สัปดาห์ในสภาพแวดล้อมที่ปรับตัวได้มากหรือเดือนถึงปีในวัฒนธรรมที่อดทนมากขึ้น สร้างอิทธิพลของคุณทีละคน

คุณจะไม่เข้าสู่งานใหม่ที่คุณจะคิดว่าฐานรหัสนั้นสมบูรณ์แบบและทุกอย่างได้ทำไปอย่างถูกต้อง เรียนรู้ที่จะยอมรับสิ่งนี้ สิ่งที่คุณสามารถทำได้ด้วยรหัสดั้งเดิมคือ refactor และเลื่อนไปข้างหน้าทีละนิด บางสิ่งที่คุณไม่ต้องการ refactor จนกว่าคุณจะมีความเข้าใจมากขึ้นว่าทำไมพวกเขาทำในสิ่งที่พวกเขาทำ นอกจากนี้ยังไม่มีใครในธุรกิจที่จะจ่ายเงินให้คุณเพื่อแก้ไขรหัสการทำงานดังนั้นคุณจะต้องทำเรื่องธุรกิจเพราะเหตุใดจึงต้องทำงานก่อนที่จะก้าวขึ้นและใช้เวลา คุณดีกว่าที่จะรอรหัส refactor เมื่อมีการเปลี่ยนแปลงที่คุณต้องทำต่อไป คุณอาจไม่ได้เลือกวิธีที่พวกเขาทำในบางสิ่ง แต่ถ้ามันใช้งานได้โปรดใช้ความระมัดระวังในการเปลี่ยนและแนะนำข้อบกพร่องใหม่ โดยเฉพาะอย่างยิ่งเมื่อคุณไม่ได้ถูกขอให้เปลี่ยน

หลังจากหนึ่งสัปดาห์คุณไม่มีความน่าเชื่อถือที่จะให้คำแนะนำที่สำคัญเกี่ยวกับวิธีที่พวกเขาทำธุรกิจ หากคุณนำเรื่องขึ้นตอนนี้ผู้คนจะหัวเราะเยาะคุณและจะไม่พาคุณไปอย่างจริงจัง พิสูจน์ตัวเองด้วยรหัสที่ดีก่อนจากนั้นผู้คนจะมีแนวโน้มที่จะรับฟังมากขึ้น

และไม่มีใครสนใจว่าคุณเป็นผู้เชี่ยวชาญที่ผ่านการรับรองจาก Microsoft ทุกคนที่มีประสบการณ์มากมายได้เห็นโปรแกรมเมอร์ที่ไม่ดีหลายคนที่ได้รับการรับรองว่าเป็นคนดี ฉันไม่ได้บอกว่ามันทำให้คุณดูไม่ดีที่จะได้รับการรับรองฉันกำลังบอกว่าเราไม่ได้ให้ความสำคัญกับพวกเขามากนักเพราะเราไม่ได้เห็นว่าพวกเขามีประสิทธิภาพแค่ไหนแสดงให้เราเห็นว่าเป็นโปรแกรมเมอร์ที่ดี

ฉันอาจลงไปตามถนนของการพยายามหาวิธีนำเสนอข้อเสนอด้วยความตั้งใจที่คุณอาจท้ายไม่สามารถพิสูจน์ตำแหน่งของคุณได้อย่างเพียงพอ คำถามสองสามข้อที่ต้องไตร่ตรองในการสร้างข้อเสนอนั้น:

• มูลค่าทางธุรกิจจะได้รับมากเพียงใดโดยการเปลี่ยนแปลงประเภทที่คุณอธิบายไว้ที่นี่
• คุณได้พิจารณาตัวเลือกต่าง ๆ เช่นการเขียนแอปพลิเคชันใหม่อีกครั้งตั้งแต่เริ่มต้นการแก้ไขโค้ดที่มีอยู่เพื่อทำให้ได้ถึงกลิ่นหรือเพียงแค่ทำการเปลี่ยนแปลงเล็กน้อยเมื่อเวลาผ่านไป
• คุณรู้หรือไม่ว่ามีฟีเจอร์และบั๊กที่ต้องการในขณะนี้ที่จะป้องกันไม่ให้คุณทำการเปลี่ยนแปลงที่คุณต้องการ?

ในขณะที่ฉันสามารถชื่นชมที่ต้องการแก้ไขฐานรหัสที่ไม่ดี แต่ต้องมีการชั่งน้ำหนักเพื่อให้เหมาะสมจากมุมมองทางธุรกิจที่จะทำ

ขณะนี้คุณไม่ได้อยู่ในตำแหน่งที่จะป้องกันรหัสที่ไม่ดีดังนั้นคุณจะต้องหาวิธีที่จะเก็บรหัสไว้

ผู้นำของ PM และทีมจะต้องใส่ใจว่ามันไม่ได้ผล ข้อกังวลต่อไปของพวกเขาคือเมื่อพวกเขาขอให้คุณทำการเปลี่ยนแปลงและสงสัยว่าทำไมเรื่อง 'ง่าย' ใช้เวลานาน นั่นคือสิ่งที่คุณจะเข้ามา

เริ่มทันทีด้วยปัญหาความสอดคล้อง ไม่ว่าวิธีมาตรฐานที่เป็นไปได้ในปัจจุบันคืออะไรพยายามที่จะระบุและดูว่าคุณไม่สามารถบังคับใช้ได้ หากคุณเริ่มต้นด้วยวิธีการที่ไม่มีใครคุ้นเคยคุณจะได้รับแรงผลักดันมากมาย

สมาชิกในทีมคนอื่น ๆ อาจต้องการได้รับการรับรองและคุณจะเป็นทรัพยากรที่ยอดเยี่ยม หวังว่าอย่างน้อยพวกเขาจะต้องการปรับปรุงและมองหาคุณเพื่อแสดงให้พวกเขาเห็นวิธี

การบ่นเกี่ยวกับสัญลักษณ์ของฮังการีจะทำให้คุณไม่มีความเห็นอกเห็นใจและอาจเป็นหนึ่งในการต่อสู้ครั้งสุดท้ายในรายการลำดับความสำคัญ

ฉันยอมรับว่าคุณจะต้องระมัดระวังเกี่ยวกับเรื่องนี้ คุณต้องสร้างชื่อเสียงภายในทีมก่อนที่คุณจะสามารถวิจารณ์และเสนอการเปลี่ยนแปลงที่ลึกซึ้งในรหัสหรือกระบวนการ ฉันจะจดบันทึกเกี่ยวกับสิ่งที่ฉันค้นพบ & ข้อเสนอแนะในขณะนั้นและใช้โอกาสในการทำความคุ้นเคยกับสมาชิกในทีมและผู้บริหารเข้าสู่การสนทนาฟรี แต่ไม่ปฏิเสธถ้าการพูดหันไปสู่ปัญหาคุณภาพการเขียนคำถาม ฯลฯ บางครั้ง บางคำถามของฉันเองลงในสระ (แต่ในรูปแบบทั่วไปไม่ได้ชี้ไปที่ปัญหาที่เป็นรูปธรรมใด ๆ ที่ฉันได้เห็นใน codebase นี้) วิธีนี้ฉันจะได้รับรู้ความคิดเห็นของสมาชิกในทีมและค้นหาพันธมิตรที่มีศักยภาพ

ในกรณีที่ดีที่สุดคุณอาจพบว่าส่วนสำคัญของทีม (และ / หรือการจัดการ) เห็นปัญหาเช่นเดียวกับคุณเพียงแค่ไม่มีความคิดริเริ่มที่จะทำอะไรเกี่ยวกับพวกเขาหรือไม่มีทรัพยากรที่ได้รับจากฝ่ายบริหาร คุณมีส่วนร่วมมากขึ้นในการโน้มน้าวใจฝ่ายบริหารหากจำเป็น

ตามที่ @ ไมค์แนะนำไว้การทำความสะอาดด้วยตัวคุณเองนั้นเป็นสิ่งที่จำเป็น แต่ก็ต้องอดทนกับมัน หากคุณเริ่มเร็วเกินไปคุณอาจทำให้สมาชิกทีมคนอื่น ๆ ที่อาจใช้มันเป็นการวิจารณ์ส่วนตัว ผู้จัดการของคุณอาจต้องใช้การทำความสะอาด / การสร้างรหัสใหม่อีกครั้งซึ่งอาจเป็นสัญญาณบ่งชี้ว่าคุณไม่ได้มุ่งเน้นที่งานจริงมากพอ ดังนั้นคุณควรได้รับมอบอำนาจให้ refactor ก่อนที่จะเริ่มดำเนินการในระดับที่รุนแรงมากขึ้น การเปลี่ยนแปลงในท้องถิ่นขนาดเล็กอาจตกลง

นอกจากนี้ในการโน้มน้าวผู้บริหารคุณต้องมีเหตุผลทางธุรกิจ การจัดการแทบจะไม่ย้ายโดยคำอธิบายของวิธีการเข้ารหัสที่ไม่สอดคล้องกัน คุณต้องแสดงให้พวกเขาเห็นว่าการเปลี่ยนแปลงที่เสนอมานั้นมีประโยชน์ต่อ บริษัท อย่างไรบรรทัดล่างคือเงินสด หากคุณสามารถรวบรวมการคำนวณที่ดูน่าเชื่อถือเกี่ยวกับค่าใช้จ่ายเทียบกับผลประโยชน์ระยะยาวของการเปลี่ยนแปลงที่เสนอต่างๆและแสดงให้เห็นว่ายอดคงเหลือโดยรวมนั้นชัดเจนในด้านบวกคุณได้ปรับปรุงโอกาสของคุณอย่างเห็นได้ชัด

ทำด้วยตัวคุณเอง. ถ้าคุณมีค่ารูปแบบการเข้ารหัสบางแล้วการทำงานในรหัสที่ละเมิดในรูปแบบการเข้ารหัส ชำระเงินชิ้นส่วนของรหัสที่กระทำผิดจากการควบคุมแหล่งที่มาจัดรูปแบบรหัสใหม่ตามข้อกำหนดของ whitespaces ของสไตล์ (ตัวอย่าง) และส่งรหัสที่ได้รับการอัปเดตพร้อมกับข้อความ

หลังจากผ่านไปหนึ่งสัปดาห์สิ่งที่แย่ที่สุดที่คุณสามารถทำได้คือไปที่การจัดการโดยตรงกับสิ่งนี้ ในทุกโอกาสพวกเขาใช้เวลาส่วนใหญ่ในรหัสและมีความภาคภูมิใจในระดับหนึ่ง คุณอาจจะหลุดพ้นจากความรุนแรง "รู้ทุกอย่าง"

สิ่งที่ฉันจะทำถ้าฉันเป็นคุณคือการปรับปรุงตามที่คุณไป เมื่อคุณคุ้นเคยกับมันมากขึ้นและเมื่อคุณทำงานกับมันมากขึ้นคุณจะมีโอกาสปรับปรุงมัน เมื่อถึงจุดนั้นฉันจะเริ่มแสดงให้เห็นถึงประโยชน์ของสิ่งที่คุณทำกับเพื่อนร่วมงานคนอื่น ๆ หลังจากนั้นเมื่อการประชุมออกแบบขึ้นมาสำหรับโมดูลใหม่นำเสนอข้อโต้แย้งสำหรับสิ่งที่คุณเห็นว่าเป็นวิธีที่ดีที่สุด

และตามจริงแล้วมาตรฐานก็มีอยู่ด้วยเหตุผล แต่ถ้ามันใช้ได้ผลและทำงานได้ดีซึ่งมีค่ามากกว่า 100 เท่าในหนังสือของฉัน (โดยเฉพาะหลังจากผ่านไปหนึ่งสัปดาห์) ฉันจะกังวลมากขึ้นถ้าคุณเปิดรหัสและเห็นข้อผิดพลาดเชิงตรรกะมากมายหรืออะไรทำนองนั้น

อย่าไปที่การจัดการโดยตรงกับ 'ปัญหา' นี้

อันดับแรกพูดคุยกับเพื่อนร่วมงานของคุณและค้นหาว่าทำไมพวกเขาถึงเป็นอย่างนั้น จากนั้นคุณสามารถทำการประเมินที่ดีขึ้นว่ามีปัญหาหรือไม่ คุณอาจประหลาดใจกับสิ่งที่เรียนรู้ นอกจากนี้คุณยังอาจหาพันธมิตรที่ต้องการทำความสะอาด

หากคุณไม่มีความคิดใด ๆ ว่าคุณไปถึงที่ที่คุณอยู่ในสถานที่แรกมันทำให้ยากที่จะออกไป

คำแนะนำที่ดีมากมายอยู่ที่นี่แล้วและฉันเป็นคนที่ไม่เขียนความเห็นของคุณจนกว่าคุณจะได้พิสูจน์ตัวเองเป็นคนแรกแล้ว สิ่งที่ฉันจะเพิ่มคือพูดคุยกับเพื่อนร่วมทีมของคุณเป็นอย่างดีก่อนที่จะแยกแยะพวกเขาโดยไปที่ผู้จัดการโครงการหรือหัวหน้าทีมก่อน และแสดงให้พวกเขาเห็นอย่างชัดเจนว่าคุณควรจริงจัง

ฟังดูเกินไปว่ามันเป็นปัญหาของโวหารที่คุณมีกับรหัส การยึดรหัสของคนอื่นและถือจมูกของคุณในขณะที่คุ้นเคยกับวิธีที่พวกเขาเขียนมันเป็นเพียงส่วนหนึ่งของงานแม้ว่ามันจะเป็นเรื่องเล็กน้อยเช่นเดียวกับที่พวกเขาจัดรูปแบบ การมอบ 'ทารก' ของคุณให้กับคนอื่นเพื่อให้พวกเขารำพึงด้วยมือที่สกปรกของพวกเขายิ่งเลวร้ายลง ...

หากท้ายที่สุดแล้ว - และปัญหานั้นมีประโยชน์มากกว่าเพียงแค่โวหาร - หากคุณกำลังจะเป็นหัวหน้าทีม / น. จะเป็นการดีที่สุดที่จะเลือกความต้องการการทำงานซ้ำในแง่ที่ว่าจะประหยัดเงินและความพยายามในอนาคต โครงการพัฒนา การปรับโครงสร้างเก่าที่ดี