ในตอนท้ายของเชือกของฉัน [ปิด]


17

ฉันเป็นผู้รับเหมาของ บริษัท ใหญ่ ปัจจุบันมีผู้พัฒนาสามรายในโครงการ

ปัญหาคือนักพัฒนาอีก 2 คนไม่เข้าใจ โดย "it" ฉันหมายถึงสิ่งต่อไปนี้:

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

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

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

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

มีวิธีที่ละเอียดอ่อน / ไม่ลึกซึ้งในการทำให้ชัดเจนว่ามีหลายสิ่งที่ฉันแก้ไขหรือไม่


1
ฉันเปิดคำถามเพื่อตอบคำถามนี้ซึ่งฉันคิดว่าปัญหาที่แท้จริงของทีมของคุณคือ: programmers.stackexchange.com/questions/127117/ …. เท่าที่แนะนำการทดสอบอัตโนมัติฉันเห็นด้วยอย่างยิ่งกับโพสต์ของ Martin Blore: martinblore.wordpress.com/2010/06/02/… - หากไม่มีหลักการและรากฐานที่ดีความพยายามของ TDD จะสูญเปล่าไปมาก ฉันพยายามเป็นศูนย์บนรากฐานนั้นในโพสต์ของฉันเพราะฉันก็อยากรู้อยากเห็น
DXM

ปัญหาที่ฉันมีคือการทดสอบการตรวจสอบการทำงานเท่านั้นที่ทำงาน พวกเขาไม่ได้พูดถึงอีก 7 รายการที่ฉันระบุไว้
hvgotcodes

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

คำตอบ:


7

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

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

ด้วยกฎนี้ในสถานที่ที่ผมใช้เป็นประจำเครื่องมือคุ้มครองรหัส (ในกรณีนี้jacocoของเราSBTสร้าง) เพื่อให้แน่ใจว่าชิ้นได้รับความคุ้มครองอย่างถูกต้องและฉันยังทำ refactorings และตรวจสอบรหัสอย่างต่อเนื่องในการผลักดันให้รหัสใด ๆ จากพวกเขา เนื่องจากเป็นโครงการJavaและScalaฉันมีเครื่องมือมากมายที่จะช่วยให้ฉันตรวจจับสิ่งที่ไม่ควรอยู่ที่นั่นหรือไม่ทำงานอย่างที่เราคิดว่าควรทำไม่แน่ใจว่าคุณสามารถทำเช่นเดียวกันกับJavaScriptแต่อาจมี ทางออก

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

จะมีสักครู่ที่พวกเขาจะยอมแพ้และทำสิ่งที่ถูกต้องหรือฝ่ายบริหารได้รับข้อความและลบพวกเขาออกจากโครงการ


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

dxm ใช่นี่เป็นปัญหา ประเด็นคำถามของฉันคือวิธีนำปัญหานี้ไปสู่การจัดการแม้ว่าฉันยอมรับว่าอาจไม่ชัดเจน
hvgotcodes

2
ฉันคิดว่าตัวเลือกที่ดีที่สุดในการจัดการสิ่งนี้คือการแสดงให้เห็นว่าต้องมีการทำซ้ำโค้ดของพวกเขามากแค่ไหน
Maurício Linhares

7

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

ก่อนอื่นฉันอยากจะบอกว่าเมื่อครู่ก่อนฉันเจอบล็อกซึ่งเป็นหนึ่งในสมาชิกโปรแกรมเมอร์ของเรา SE, Martin Bloreและ IMO หนึ่งโพสต์เฉพาะเกี่ยวกับการสร้างตัวเองของ TDDนั้นแม่นยำมาก TDD เป็นระดับสุดท้ายที่สูงที่สุดที่เชื่อมโยงทุกอย่างเข้าด้วยกัน แต่ไม่มีระดับก่อนหน้าโดยเฉพาะอย่างยิ่งหลักการและวิธีปฏิบัติที่ใหญ่ที่สุดในการสร้างรหัสที่ชัดเจนและอ่านได้มันจะยากมากหากไม่สามารถทำงาน TDD ได้

ใน บริษัท ของฉันทั้งผู้บริหารและเปรียว TDD ถูกกำหนดให้กับเราโดยผู้บริหารและในตอนแรกเราก็ทำได้เพราะเราได้รับการบอกกล่าว (ซึ่งตรงกันข้ามกับความคล่องตัว) เราได้ลอง TDD สองครั้งและในขณะที่ฉันเป็นผู้สนับสนุนอย่างมากในการใช้การทดสอบอัตโนมัติฉันได้โยนทุกอย่างที่ทีมตบไปด้วยกันในการเปิดตัวครั้งสุดท้าย พวกเขาบอบบาง, มโหฬาร, คัดลอก / วาง wazoo และเต็มไปด้วยคำสั่งการนอนหลับที่ทำให้พวกเขาทำงานได้ช้าจริงๆและคาดเดาไม่ได้ คำแนะนำของฉันสำหรับทีมของคุณ: อย่าทำ TDD ... ยัง

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

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

ดังนั้นสมมติว่าคุณมีความเคารพและความสนใจของทีม ตอนนี้คืออะไร

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

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

  1. เมื่อคุณได้รับการสนับสนุนจากฝ่ายบริหาร คุณสามารถเริ่มต้นการแนะนำมากของการปฏิบัติที่ส่วนกลางกำหนด A / กระบวนการที่MainMaข้อเสนอแนะในการตอบสนองต่อคำถามของฉัน เราได้ทำสิ่งเหล่านี้มากมาย (ยกเว้นการเขียนโปรแกรมจับคู่) และคุณจะเห็นประโยชน์อย่างแน่นอน การตรวจสอบรหัสช่วยให้มาตรฐานในการออกแบบเอกสารและช่วยให้เราสามารถแบ่งปันความรู้ / เทคนิคระหว่างทีม แม้ว่าการตรวจสอบโค้ดจะถูกกำหนด แต่ทีมชอบพวกเขาจริงและเราตรวจสอบทุกฟังก์ชันการทำงานที่ได้รับการตรวจสอบอย่างไรก็ตาม ...
  2. คุณสังเกตเห็นว่ารหัสที่เขียนโดยทั่วไปยังคงเป็นคู่เกินไปการออกแบบไม่ดีหรือขาดหายไปอย่างสมบูรณ์ ความคิดเห็นเกี่ยวกับโค้ดมีอยู่บ้าง แต่มีเพียงคุณเท่านั้นที่สามารถเขียนซ้ำได้ ทำไมการออกแบบไม่ดีตั้งแต่แรก - นักพัฒนาจำนวนมากไม่เคยรู้จักวิธีปฏิบัติที่ดีมาก่อนและไม่เคยสอน OOD อย่างเป็นทางการตั้งแต่แรก ผู้คนจำนวนมาก "เพียงแค่เขียนรหัส" ไม่ว่าจะได้งานอะไรก็ตาม
  3. ด้วยการสนับสนุนของฝ่ายจัดการคุณสามารถแนะนำกระบวนการเพิ่มเติมเช่นการอภิปรายการออกแบบก่อนการเข้ารหัสใด ๆ จะเกิดขึ้น แต่คุณเป็นเพียงคนเดียวและดูเหมือนว่าทันทีที่คุณไม่ใส่ใจทีมจะย้อนกลับไปสู่สิ่งที่พวกเขาทำมาตลอด ทำไม?
  4. สามารถแนะนำและสอนการปฏิบัติหรือนิสัยที่ดีขึ้นเพื่อที่คุณจะได้ไม่ต้องคอยเฝ้าดูอยู่ตลอดเวลา? - ปรากฎว่าส่วนนี้ไม่ใช่เรื่องง่าย
  5. ทำไมสมาชิกในทีมคนอื่น ๆ จึงลังเลที่จะเรียนรู้และเลือกปฏิบัติใหม่และทำไมพวกเขาถึงต้านทานต่อ SOLID หรือ DRY เมื่อมันถูกเขียนเกี่ยวกับวรรณคดีระเบียบวิธีซอฟแวร์สมัยใหม่? กับการเปลี่ยนแปลงในเชิงบวกทั้งหมดที่เราเคยมีในทีมงานของฉัน, 2 สัปดาห์ที่ผ่านมาผมมีข้อโต้แย้งเป็นฉัน refactored 2 ฟังก์ชั่นที่มีเหมือนกัน 15 บรรทัดของรหัสและวิจารณ์เรียกมันว่ากล้าหาญและความพยายามที่ไม่จำเป็นเพราะไม่มีอะไรผิดปกติกับการคัดลอก / วางของเท่านั้น 15 บรรทัด ฉันไม่เห็นด้วยอย่างยิ่งกับความคิดเห็นดังกล่าว แต่ตอนนี้เราได้ตกลงยอมรับที่จะไม่เห็นด้วย - แล้วอะไรล่ะ ตอนนี้เรามาถึงหัวข้อโพสต์อื่นของฉันแล้ว
  6. ในฐานะที่เป็นmaple_shaftและnikieชี้ให้เห็นในคำตอบของพวกเขา (ขอโทษMainMaคุณได้รับการโหวตมากที่สุด แต่คุณเป็น 5 ขั้นตอนหลัง :)) คุณมาถึงขั้นตอนที่ "กระบวนการ" ไม่สามารถช่วยคุณและไม่มีใครในฟอรัมนี้ สามารถบอกคุณได้ว่า "แก้ไข" คืออะไร ขั้นตอนต่อไปคือเข้าหาแต่ละคนอาจเป็นแบบตัวต่อตัวหรืออาจเป็นทีมอาจเป็นทั้งครั้งเดียวหรืออีกครั้งและพูดคุยกับพวกเขา ถามพวกเขาว่าอะไรทำงานได้ดีและอะไรที่ไม่ดี วิธีเดียวที่จะระบุสาเหตุที่แท้จริงของสิ่งที่ผลักดันพวกเขาตอนนี้คือการพูดคุยกับพวกเขาทีละคนและค้นหาสิ่งนั้น เป็นส่วนหนึ่งของขั้นตอนนี้ฉันเพิ่งเจอปัญหาทีมที่แตกต่างอย่างสิ้นเชิง แต่ฉันคิดว่าคำตอบของโจเอลที่นี่ซึ่งมีรายละเอียดและลึกซึ้งมากจะนำไปใช้กับกรณีนี้เช่นกัน โดยสรุปในขณะที่ใช้การจัดการในฐานะ "short leash" เป็นวิธีการที่เป็นไปได้สำหรับทุกสิ่งเราจำเป็นต้องจำไว้ว่าเรากำลังติดต่อกับมนุษย์เพื่อที่จะเข้าใจแรงจูงใจอย่างแท้จริงที่เราต้องข้ามไปสู่จิตวิเคราะห์มากกว่าการจัดการที่บริสุทธิ์
  7. ดังนั้นตอนนี้คุณกำลังพูดคุยกับเพื่อนร่วมทีมของคุณ? คุณถามอะไร ฉันไม่แน่ใจเกี่ยวกับส่วนต่อไปนี้เพราะฉันไม่เคยมาที่นี่ นี่เป็นสถานการณ์ที่เป็นไปได้: Q: ทำไมไม่มี SOLID? ตอบ: ฉันไม่ต้องการมัน ถาม: อาจช่วยได้ A: ฉันไม่เป็นไรเหมือนเดิม - อย่างใดคุณต้องสร้างชุดของเสียงที่จะออกจากปากของคุณและทำให้ผู้ฟังรับรู้ว่าสิ่งต่าง ๆ อาจจะดีกว่าถ้าพวกเขาให้สิ่งที่คุณกำลังเร่ขายโอกาส หากคุณล้มเหลวที่นี่พวกเขาจะไม่ถูกโน้มน้าวใจเลยว่าสิ่งใดก็ตามที่ "กระบวนการ" ทำให้พวกเขามีคุณค่า ในทางตรงกันข้ามหากคุณผ่านจุดนี้ไปได้คุณอาจพบว่าคุณไม่จำเป็นต้องมี "กระบวนการ" อีกต่อไป
  8. IMO ที่รากเพื่อนร่วมทีมของคุณจะไม่เรียนรู้ว่าพวกเขาไม่เห็นอะไรผิดปกติกับพฤติกรรม / การปฏิบัติในปัจจุบันของพวกเขา ดังนั้นขั้นตอนต่อไปในทั้งหมดนี้คือการหาวิธีที่จะแสดงให้เห็นถึงการเน้นปัญหาและทำให้พวกเขาชัดเจน ท้ายที่สุดเราไม่ได้เขียนโค้ดที่อ่านได้โดยใช้หลักการ SOLID / DRY หรือการบำรุงรักษาเอกสารเพียงเพราะมันให้ความรู้สึกอบอุ่นและคลุมเครือ เราทำเพราะจะสร้างรหัสคุณภาพที่ดีขึ้นและทำให้เรารหัสได้เร็วขึ้น สามารถวัดได้ไหม บางทีนี่อาจเป็นที่มาของการวัดซอฟต์แวร์
  9. นี่เป็นความคิดที่บ้าและฉันก็ไม่รู้ว่ามันจะใช้งานได้จริงหรือเปล่า (มันอาจจะเป็นมาตรฐานอุตสาหกรรมหรือมันอาจจะไม่ถูกต้องอย่างสมบูรณ์ฉันเพิ่งสร้างมันขึ้นมาใน 24 ชั่วโมงที่ผ่านมา) แต่ฉันอยากจะเอามันมา เข้าสู่ตารางทันทีที่เริ่มปีหน้า:
    • กับความคิดเห็นของคนอื่น ๆแนะนำแนวคิดของผู้แต่ง / เจ้าของสำหรับไฟล์ต้นฉบับทั้งหมด เนื่องจากPragmatic Programmerแนะนำว่าสิ่งนี้จะให้ความรู้สึกถึงความเป็นเจ้าของและความรับผิดชอบต่อบุคคลคนเดียวซึ่งจะต้องรับผิดชอบซอร์สโค้ดชิ้นหนึ่ง ไม่ได้หมายความว่าคนอื่นไม่สามารถแก้ไขรหัสได้เราทุกคนทำงานเป็นทีม แต่ในตอนท้ายของวันผู้ที่เป็นเจ้าของรหัสจะรับผิดชอบในการตรวจสอบการเปลี่ยนแปลง
    • สร้างทริกเกอร์ที่เก็บข้อมูลต้นทางที่ตรวจสอบการเช็คอินทั้งหมดและมองหาผู้ที่แก้ไขข้อผิดพลาดโดยเฉพาะ ทำให้เป็นกระบวนการเพื่อให้ทุกการแก้ไขข้อบกพร่องมีตัวระบุการอ้างอิงอยู่ตรงหน้าในคำอธิบายการเช็คอิน ตอนนี้เขียนสคริปต์ที่จะแยกรายการของไฟล์ที่มีการเปลี่ยนแปลงและตัดออก "ผู้เขียน" จากบล็อกความคิดเห็นส่วนหัวของไฟล์ สร้างฐานข้อมูล SQL ที่จะติดตาม # ข้อบกพร่องที่ตรวจสอบในแต่ละไฟล์ / ต่อโครงการ / ต่อผู้เขียน
    • เมื่อคุณมีสถิติเพียงพอแล้วหวังว่าคุณจะสังเกตเห็นว่าโค้ดของคุณมีข้อบกพร่อง / การเปลี่ยนแปลงน้อยกว่าโค้ดอื่น ๆ นี่เป็นข้อมูลที่คุณสามารถใช้งานได้ยาก หากโครงการใดโครงการหนึ่งมีอัตราสูงกว่าข้อบกพร่องเฉลี่ยอย่างมีนัยสำคัญให้นำโครงการขึ้นมาเป็นผู้สมัครสำหรับความพยายามในการทำความสะอาด / การปรับโครงสร้างครั้งต่อไปเพื่อชำระหนี้ทางเทคนิคบางส่วน
    • หากโครงการหรือไฟล์มีอัตราข้อบกพร่องสูงกว่าค่าเฉลี่ยอย่างมีนัยสำคัญและมีเจ้าของรายหนึ่งให้พูดคุยแบบตัวต่อตัวกับบุคคลนั้น ถามพวกเขาด้วยความสุภาพอย่างสุภาพและไม่คาดคั้นถึงสิ่งที่พวกเขาสามารถทำได้เพื่อแก้ไขปัญหานี้ เนื่องจากพวกเขาเป็นเจ้าของพวกเขาควรผลักดันการเปลี่ยนแปลง แต่ให้ความช่วยเหลือใด ๆ และทั้งหมดจากด้านข้างของคุณ หวังว่าเจ้าของจะติดตามหลายสาเหตุของรหัสสปาเก็ตตี้ของพวกเขาเองและทันทีที่พวกเขาขอความช่วยเหลือนั่นคือเมื่อคุณเริ่มดำเนินการและวางโซลิดบางส่วน

1
นี่มันยอดเยี่ยมมากขอบคุณ ฉันได้ลองก่อนเทคนิคเหล่านี้ (Jen * ทำไมคุณไม่เปลี่ยนฟอร์แมตโค้ดของคุณเป็น x, y, z ใช้เวลา 2 นาที) มาก่อนและฉันมักจะได้รับบริการริมฝีปากและไม่มีอะไรเกิดขึ้น นอกจากนี้เพื่อนร่วมงานคนหนึ่งของฉันก็แข็งแกร่งกว่าอีกคนหนึ่งอย่างชัดเจน ในบรรทัดที่เธออาจจะดีมาก แต่ล้มเหลวในการดำเนินการ ฉันได้ยินเธอพูดถึงคุณภาพของรหัสตลอดเวลา แต่ก็เปลี่ยนกลับไปเป็นเชลล์เมื่อถึงเวลาที่ต้องลงมือ: "เรามีเวลาแค่ 5 สัปดาห์เท่านั้นที่จะปล่อยฉันไม่ต้องการทำสิ่งใดในตอนนี้" และฉันใบหน้า * เปลี่ยนชื่อ
hvgotcodes

จะทำอย่างไรถ้าคุณไม่ได้มุ่งเน้นที่การจัดรูปแบบโค้ด (หรือสิ่งอื่นใดที่เฉพาะเจาะจง) เพียงแค่คุยกับ Jen และนำปัญหาบางอย่างมาเป็นปัญหาของทีม (เช่น "ฉันสังเกตว่าบางรหัสของเราไม่สามารถอ่านได้มากฉันคิดว่ามันทำให้เราทำผิดพลาดที่สามารถหลีกเลี่ยงได้") อย่าแนะนำอะไรเลย แต่ให้ Jen แค่คิดหาวิธีแก้ปัญหาที่เป็นไปได้ นอกจากนี้ฉันพบว่ามันช่วยเมื่อคุณสำรองข้อมูลคำแนะนำของคุณกับแหล่งที่มา แทนที่จะพูดว่า "ฉันคิดว่าเราต้องทำงานกับการตั้งชื่อตัวแปรที่ดีกว่า" ถ้าคุณพูดว่า "ฉันอ่าน Clean Code และฉันคิดว่าผู้เขียนมีจุดดีมากลองทำ ... " เถียง ...
DXM

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

2

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

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

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


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

2
@hvgotcodes: ฉันไม่เห็นสาเหตุที่ทำให้คุณไม่สามารถสร้างการทดสอบหน่วยเพื่อให้ทำงานในการเช็คอินแต่ละครั้ง
Marcin
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.