โค้ดการจัดการแนวโน้มเป้าหมายควรได้รับการจัดการโดยผู้จัดการการพัฒนาอย่างไร

ก่อนอื่นให้ฉันเหรียญคำ:

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

การปฏิบัตินี้มีแนวโน้มที่จะมีข้อดีข้อเสียที่ฉันระบุ:

• Pro : คุณภาพของรหัส / ความสามารถในการอ่าน / ความสอดคล้องมักจะถูกรักษาไว้
• Pro : ข้อผิดพลาดบางอย่างได้รับการแก้ไขเนื่องจากนักพัฒนารายอื่นไม่คุ้นเคยกับรหัสดั้งเดิม
• คอนดิชั่น : มักจะเป็นการเสียเวลาของผู้พัฒนาเป้าหมาย
• คอนดิชั่น : บางครั้งแนะนำบั๊กที่ทำให้นักพัฒนาโกรธซึ่งคิดว่าพวกเขาเขียนโค้ดปราศจากข้อบกพร่องในวันก่อนหน้า
• คอนดิชั่นเนอร์ : นักพัฒนารายอื่นได้รับความเดือดร้อนจาก nitpicking มากเกินไปและเริ่มที่จะไม่ชอบการมีส่วนร่วมในรหัสของเป้าหมายที่อ่อนโยน

ข้อจำกัดความรับผิดชอบ: เพื่อความเป็นธรรมฉันไม่ได้เป็นผู้จัดการการพัฒนาจริง ๆ แล้วฉันเป็นผู้พัฒนาที่กำลังทำ "กำลังพุ่งเป้า"

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

ดังนั้นถ้าคุณเป็นผู้จัดการคุณจะแก้ไขปัญหานี้อย่างไร

UPDATE: ฉันไม่ได้ตั้งใจจะให้เป็นภาษาท้องถิ่น แต่บางคนถามดังนั้นบางทีพื้นหลังบางอย่างจะสว่างขึ้น ฉันได้รับมอบหมายโครงการยักษ์ใหญ่ (200K LoC) เมื่อสามปีที่แล้วและเมื่อไม่นานมานี้ (1 ปีก่อน) ได้มีการเพิ่มผู้พัฒนาเพิ่มเติมลงในโครงการซึ่งบางส่วนไม่คุ้นเคยกับสถาปัตยกรรม โดยทั่วไปฉันต้องตอบเพื่อความมั่นคงโดยรวมของผลิตภัณฑ์และฉันรู้สึกกังวลเป็นพิเศษเมื่อมีการเปลี่ยนแปลงเกิดขึ้นอย่างน่าประหลาดใจต่อส่วนสถาปัตยกรรมหลักของรหัสฐาน นิสัยนี้เกิดขึ้นเพราะในตอนแรกฉันมองโลกในแง่ดีเกี่ยวกับการมีส่วนร่วมของนักพัฒนาคนอื่น แต่พวกเขาทำผิดพลาดมากเกินไปจนทำให้เกิดปัญหาร้ายแรงที่จะไม่ถูกค้นพบจนกระทั่งอีกหลายสัปดาห์ต่อมา บ่อยครั้งสิ่งเหล่านี้ "

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

การพูดอย่างตรงไปตรงมา IMHO นี่เป็นความคิดที่แย่มาก

ฉันคาดหวังกำลังใจให้ลงไปในรางถ้ามันยังไม่ได้

เพื่อความเป็นธรรมกับคุณคุณรับทราบสิ่งนี้

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

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

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

ถ้าฉันเป็นผู้จัดการเพื่อแก้ไขปัญหานี้:

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

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

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

juju ไม่ดี

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

งานการล้างข้อมูลควรดำเนินการหลังจากทีมงานตรวจสอบโค้ดอย่างเป็นทางการเท่านั้นและโดยนักพัฒนาซอฟต์แวร์ที่ได้รับมอบหมายงานเหล่านั้นเท่านั้น

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