วิธีการส่งเสริมการใช้ซ้ำรหัสและเอกสารประกอบ? [ปิด]

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

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

อย่างไรก็ตามมีการเตือนผู้พัฒนาให้นำส่วนประกอบมาใช้ใหม่ / ปรับปรุงเอกสารประกอบ / สนับสนุนส่วนประกอบพื้นฐานแทนการทำซ้ำรหัสที่มีอยู่และปรับแต่งมันหรือเขียนเอง?

วิธีทำให้ส่วนประกอบค้นพบได้ง่ายและใช้งานได้ง่ายเพื่อให้ทุกคนใช้งานได้?

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

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

ฉันเห็นด้วยกับความคิดเห็นของ Euphoric ต่อคำถาม บ่อยครั้งที่เป็นไปไม่ได้ที่จะนำสิ่งต่าง ๆ มาใช้ระหว่างโครงการต่าง ๆ (โดยทั่วไปการดำเนินการ CRUD ทั้งหมดจะเหมือนกัน

นอกจาก "เอกสารประกอบ" ที่กล่าวถึงแล้ว "ง่ายต่อการค้นหาและนำทาง", "วินัย" และ "codereview"

รหัสที่ใช้ซ้ำได้จะต้องเป็น

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

หากไม่มีสองรายการสุดท้ายจะเป็นการง่ายกว่ามากในการใช้ "การคัดลอกและการรับมรดกในอดีต" ที่เราไม่ต้องการ

ฉันคิดว่าวิธีที่ดีที่สุดที่จะทำให้พวกเขาใช้รหัสซ้ำคือแรงจูงใจ หากคุณใส่ส่วนประกอบที่นำกลับมาใช้ใหม่ในโครงการพิเศษเช่นแนะนำ Euphoric ให้ใช้ความพยายามมากในนั้น ที่ที่ฉันทำงานเราทำโครงการที่รันชุดอินเตอร์เฟสที่กำหนดไว้ล่วงหน้าในแผนการดำเนินการที่กำหนดค่าได้และให้บริการบางอย่าง (เช่นคลาสที่แตกต่างกันสำหรับ DB_interaction, FTP-Service, ... ) โครงการนี้ประสบความสำเร็จอย่างยิ่งใหญ่เนื่องจากนักพัฒนาของเราต้องการใช้งานไมโครเฟรมเพราะมันช่วยประหยัดเวลาได้มากสำหรับการเขียนโค้ดสำเร็จรูปสำหรับโครงการที่คล้ายกัน สิ่งเดียวกันคือสำหรับยูทิลิตี้ไลบรารีสำหรับรายการสตริง ฯลฯ แต่ในกรณีนี้คุณต้องการใช้งานอยู่ครั้งเดียว (ทำไมต้องบูรณาการกับตัวอักษรใหม่)

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

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

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

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

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

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

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

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

การเจรจาทั่วทั้ง บริษัท นั้นมาก่อน เราเพิ่งใช้วิธีนี้สำหรับการแบ่งปันความรู้เฉพาะโครงการและฉันคิดว่ามันใช้งานได้ดี

การเขียนโปรแกรมคู่ยังทำให้การหมุนเวียนความรู้เร็วขึ้นมาก

ฉันคิดว่านี่เป็นคำถามสองข้อในหนึ่งเดียว - ฉันจะลองตอบทั้งคู่

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

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

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

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

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

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

IMMO กุญแจไม่ใช่เอกสารหรือเครื่องมือที่สำคัญคือการสื่อสาร นักพัฒนา 10+ คนไม่ใช่คนจำนวนมากบางสิ่งที่ปรับปรุงการสื่อสารนี้:

• การเขียนโปรแกรมคู่: กับคนสองคนมีการเปลี่ยนแปลงมากกว่าที่หนึ่งในสองคนรู้ว่าปัญหาได้รับการแก้ไขแล้วในส่วนอื่นของโครงการและนำมาใช้ใหม่

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

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

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

เอกสารอาจเป็นสิ่งจำเป็น แต่เป็นเพียงส่วนเล็ก ๆ ของสิ่งที่คุณต้องการ: ปรับปรุงการสื่อสารภายในทีมของคุณ

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

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

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

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

มีเครื่องมือต่างๆสำหรับการจัดการข้อมูลโค้ดที่มีผมขอแนะนำให้คนนี้: http://www.snip2code.com

(ข้อจำกัดความรับผิดชอบ: ฉันเป็นหนึ่งในผู้ก่อตั้ง Snip2Code และฉัน - ร่วมกับผู้ร่วมก่อตั้งของฉัน - ในความคิดเดียวกันของคุณเมื่อไม่นานมานี้: นี่คือสาเหตุที่เราตัดสินใจเริ่มโครงการนี้ซึ่งรวบรวมคุณสมบัติทั้งหมดที่ฉัน ข้างต้นคือการแชร์ตัวอย่างระหว่างทีมการรวมเข้ากับ IDE เช่น Visual Studio, Eclipse, IntelliJ, Notepad ++ เป็นต้น)