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