วิธีการโน้มน้าวให้เพื่อนร่วมทีมใช้ TDD [ปิด]

ฉันเป็นคนเดียวในทีมที่ใช้ TDD ฉันจะทำให้พวกเขาใช้มันได้อย่างไร

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

การใช้ github, fork และ pull ร้องขอจะแก้ปัญหานี้หรือไม่เพื่อให้พวกเขาจำเป็นต้องผ่านการทดสอบก่อนที่จะยอมรับ pull หรือไม่

ฉันไม่ใช่ผู้จัดการโครงการและฉันไม่สามารถโน้มน้าวให้เธอใช้งานได้

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

วิธีที่คุณอธิบายปัญหาดูเหมือนว่านี่ไม่ใช่กรณีที่นี่ ดู...

... เมื่อฉันดึงรหัสของใครบางคนจะทำลายการทดสอบของฉันและฉันเป็นคนที่ต้องแก้ไข

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

นี่อาจฟังดูราวกับว่าตายแล้ว แต่มันก็ไม่จริง เป้าหมายสุดท้ายของคุณ (โน้มน้าวให้ TDD) ยังคงสมเหตุสมผลอยู่พอสมควรอย่าทิ้งไว้ เพียงแค่มุ่งความสนใจไปที่การขจัดอุปสรรคที่คุณค้นพบ

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

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

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

... จะเกิดอะไรขึ้นเมื่อมีการแนะนำให้รู้จักกับเพื่อนร่วมงานที่ไม่มีประสบการณ์ของคุณ

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

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

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

เราใช้เวลาบ่ายเป็นคู่ทำซ้ำกะตะเดียวกัน แต่ภายใต้เงื่อนไขที่แตกต่างกัน เราเริ่มต้นด้วยทุกกลุ่มที่ทำแบบฝึกหัดเดียวในเวลาเดียวกัน นี่เป็นพื้นฐาน

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

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

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

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

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

ไซเบอร์ - โดโจเขียนโดยJon Jagger ใช้งานได้ดีอย่างเหลือเชื่อสำหรับการออกกำลังกายประเภทนี้ มันเป็นสภาพแวดล้อมแบบบูรณาการบนเว็บสำหรับการปฏิบัติโดยเจตนาของTDDและเรียนรู้เกี่ยวกับการเปลี่ยนแปลงของทีม มันมีกะตะจำนวนมากที่ถูกเลือกมาโดยเฉพาะเพื่อช่วยให้ผู้คนมีสมาธิกับกระบวนการของ TDD ไม่ใช่ปัญหา นอกจากนี้ยังรองรับหลากหลายภาษาตั้งแต่ Python และ Ruby ถึง Java และ C ++

สิ่งที่ดีที่สุดคือหลังจากทำกะตะคุณสามารถย้อนกลับไปดูความก้าวหน้าสีแดง / เขียว (หรืออาจจะไม่ใช่ * 8 ') ของแต่ละกลุ่มที่เข้าร่วม มันเป็นสัญญาณไฟจราจรเป็นวิธีที่ยอดเยี่ยมในการมองเห็นว่ากระบวนการ TDD ทำงานอย่างไร

หากคุณต้องการเซิร์ฟเวอร์ CyberDojo ของคุณเองคุณสามารถหาโปรเจ็กต์ทั้งหมดได้ที่ github และยังมีเครื่องเสมือนอุปกรณ์Turnkey Linux ที่เชื่อมโยงจากที่นั่นซึ่งหมายความว่าสมมติว่าคุณมีเครื่องเล่น VMwareหรือVirtualBoxติดตั้งอยู่แล้ว ไม่กี่นาทีของการดาวน์โหลดอุปกรณ์!

หากพวกเขาต่อต้าน TDD มันก็โอเค หลายคน (รวมถึงตัวเอง) กำลังมีปัญหากับการเขียนแบบทดสอบหน่วยก่อน

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

ฉันคิดว่าสิ่งที่ดีที่สุดคือการหาวิดีโอที่อธิบายถึงข้อดีของการใช้ TDD และแสดงในการประชุม

ถ้าเธอไม่ยอมฟังคุณสามารถลองไปหาคนที่อยู่เหนือเธอ แต่นั่นอาจไม่ฉลาดถ้าเจ้านายของคุณดื้อรั้น

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

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

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

มี 2 ​​ปัญหาที่ต่างกันเล็กน้อยที่นี่: ทำให้ผู้คนทำ TDD และผู้คนที่ทำข้อสอบของคุณ

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

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

ดังที่กล่าวไว้ในหลาย ๆ วิธี "ฉันควรโน้มน้าวให้ X ใช้วิธี / เทคโนโลยี Y" ได้อย่างไรคำตอบของฉันก็เหมือนกันเสมอ: จากตัวอย่าง

ใช้มันและให้ผลลัพธ์ที่ดีขึ้น (mesurable) จากนั้นตรวจสอบให้แน่ใจว่าคนอื่นสังเกตเห็น

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

คำแนะนำที่ดีมากมาย และตอนนี้อีกเล็กน้อย ...

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

ความกระตือรือร้นและการยอมรับอย่างสม่ำเสมอและต่อเนื่องของคุณสำหรับ TDD นั้นสำคัญมากในแคมเปญ WHAM

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

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

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

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

คำเตือน: TDD ไม่ใช่วิธีรักษาและไม่สามารถเอาชนะการออกแบบและการเข้ารหัส OO ที่ไม่ดี (แต่มันสามารถเปิดเผยได้อย่างแน่นอน) อย่าปล่อยให้ Luddites กล่าวโทษความพยายามในการทดสอบรหัสสำหรับการขาดคุณสมบัติ

ฉันลองอีกครั้งเพื่อโน้มน้าวผู้จัดการ จากสิ่งที่คุณเขียนฉันไม่คิดว่าคุณจะโน้มน้าวให้เพื่อนร่วมทีมทำ TDD ด้านหลังเธอ

คุณต้องพูดภาษาของเธอ ผู้จัดการมักจะไม่ประทับใจกับเทคโนโลยี แต่พวกเขาเข้าใจภาษาธุรกิจ:

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

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

• และคุณจะทำอะไรกับเวลาพิเศษ สร้างสิ่งของ moar และทำให้เป็นเงิน moar :)

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

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

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

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