DRY เป็นศัตรูของการจัดการโครงการซอฟต์แวร์หรือไม่

หนึ่งในหลักการพื้นฐานและเป็นที่ยอมรับอย่างกว้างขวางที่สุดของการพัฒนาซอฟต์แวร์คือ DRY (อย่าทำซ้ำตัวเอง) เป็นที่ชัดเจนว่าโครงการซอฟต์แวร์ส่วนใหญ่ต้องการการจัดการบางอย่าง

ตอนนี้งานใดบ้างที่ง่ายต่อการจัดการ (ประมาณ, กำหนดเวลา, ควบคุม) งานที่ถูกต้องทำซ้ำงานที่ควรหลีกเลี่ยงตาม DRY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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

ภารกิจ: สร้างรายงานที่แตกต่างกัน 100 รายงานสำหรับแอปพลิเคชันแต่ละรายงานมีลักษณะคล้ายกันมากมีความต้องการที่แตกต่างกันระหว่างรายงานตรรกะที่แตกต่างกันบางส่วน แต่ทั้งหมดไม่แตกต่างกันมาก

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

ตอนนี้หลังจากรายงาน 100 ฉบับเป็น "พร้อม" โปรแกรมจะเข้าสู่การผลิตจริงและปัญหาบางอย่างเกิดขึ้นซึ่งถูกมองข้ามระหว่าง QA อาจมีปัญหาประสิทธิภาพการทำงานอาจรายงานผิดพลาดเป็นประจำหรืออาจมีสิ่งอื่นไม่ทำงานตามที่ตั้งใจ ตอนนี้เมื่อนำหลักการ DRY ไปใช้แล้ว 90% ของปัญหาเหล่านั้นสามารถแก้ไขได้ด้วยการเปลี่ยนรหัสฐานในที่เดียว แต่เนื่องจากวิธีการคัดลอกวางปัญหาต้องได้รับการแก้ไข 100 ครั้งแทนที่จะเป็นหนึ่งครั้ง และเนื่องจากการเปลี่ยนแปลงที่ใช้จากรายงานหนึ่งไปยังอีกรายงานหนึ่งแล้ว dev ไม่สามารถคัดลอกวางการแก้ไขสำหรับรายงานแรกไปยังรายงานอื่น ๆ 99 ได้อย่างรวดเร็วเขาต้องดูรายงาน 100 ฉบับทั้งหมดอ่านแปลแปลการเปลี่ยนแปลงเป็นแก้ไข รายงานทดสอบและอาจดีบั๊กแต่ละรายการแยกกัน สำหรับ PM สิ่งนี้เริ่มยากขึ้นจริงๆ - เขาสามารถใช้เวลาในการแก้ไขข้อผิดพลาด "ปกติ" (สมมติว่า 3 ชั่วโมง) และคูณด้วย 100 แต่จริงๆแล้วนี่อาจเป็นการประมาณที่ผิดการแก้ไขบางอย่างอาจเป็น ทำให้ง่ายกว่าคนอื่นคนอื่นอาจจะยากกว่า และแม้ว่าการประเมินนี้ถูกต้องการแก้ไขข้อบกพร่องจะมีค่าสูงถึง 100 เท่าตามที่พวกเขาต้องการจะทำให้ บริษัท ต้องเสียเงินเป็นจำนวนมาก

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

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

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

การยืนยันฐานของคุณไม่ถูกต้อง

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

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

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

องค์กรที่คิดว่าวิธีนี้กำลังถูกบดขยี้โดย บริษัท ที่มีเทคโนโลยีที่ดีกว่า

Maxim ลืมบ่อย ๆ ที่ใช้ที่นี่เป็นกฎของ 3 สถานะนี้ระบุว่าตกลงเพื่อคัดลอกรหัสหนึ่งครั้ง แต่นอกเหนือจากนั้นควรแทนที่ด้วยรหัสทั่วไป

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

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

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

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

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

การเขียนรหัสใหม่เป็นเพียงส่วนเล็ก ๆ ของงาน

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

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

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

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

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

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

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

ฉันคิดว่าคุณเข้าใจผิด DRY

ลองใช้ตัวอย่าง:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

เมื่อเทียบกับ

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

โดยการแทนที่คลาส B ด้วย C เราได้ปฏิบัติตามหลักการของ DRY และลดการทำซ้ำรหัส แต่เราไม่ได้เพิ่มความรู้หรือความเสี่ยงให้กับโครงการ (เว้นแต่คุณจะไม่เคยได้รับมรดกมาก่อน)

ฉันคิดว่าคุณหมายถึงอะไรเมื่อคุณพูดถึง DRY เป็นอะไรที่มากกว่างานออกแบบ เช่น:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! ความต้องการใหม่! ลูกค้าบางรายจำเป็นต้องเพิ่มทวีคูณเป็นสองเท่า !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

เมื่อเทียบกับ

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

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

ดังนั้นเราควรใช้ B หรือ A เวอร์ชัน 2 ในกรณีนี้หรือไม่?

• B จะเจาะจงมากขึ้นกับการเปลี่ยนแปลงที่ร้องขอจริงโดยมีผลข้างเคียงน้อยลงและคาดการณ์ได้ง่ายขึ้นและเร็วขึ้น

• รุ่น 2 จะส่งผลให้รหัสโดยรวมน้อยลงในอนาคตและจะเป็นทางออกที่ดีกว่า

ฉันจะบอกอีกครั้งว่าคุณภาพของสเปคและความต้องการลดลง

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

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

ย่อหน้าตามวรรค

หนึ่งในหลักการพื้นฐานและเป็นที่ยอมรับอย่างกว้างขวางที่สุดของการพัฒนาซอฟต์แวร์คือ DRY (อย่าทำซ้ำตัวเอง) เป็นที่ชัดเจนว่าโครงการซอฟต์แวร์ส่วนใหญ่ต้องการการจัดการบางอย่าง

แก้ไข.

ตอนนี้งานใดบ้างที่ง่ายต่อการจัดการ (ประมาณ, กำหนดเวลา, ควบคุม) งานที่ถูกต้องทำซ้ำงานที่ควรหลีกเลี่ยงตาม DRY

งานซ้ำควรจะอัตโนมัติบังคับ พวกเขาน่าเบื่อข้อผิดพลาดได้ง่ายเมื่อทำด้วยมือ

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

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

• ก่อนแก้ไขรหัสในแหล่งต้นฉบับ;
• แก้ไขรหัสในที่อื่น ๆ ทุกแห่ง
• ตรวจสอบให้แน่ใจว่าสถานที่เหล่านั้นทั้งหมด เมื่อคุณบอกว่าเรื่องนี้ต้องทำกับผู้จัดการเขาอาจจะเกลียดใครสักคนอย่างน้อย

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

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

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

ผู้คนจำนวนมากชี้ว่าที่นี่ไม่มีภาวะที่กลืนไม่เข้าคายไม่ออก ใช่และไม่.

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

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

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

มันเป็นเรื่องของการออกแบบ อาจไม่ได้ใช้ซ้ำแต่การออกแบบยังคงอยู่

อะไรคือเกณฑ์ในการตัดสินใจว่านักพัฒนาซอฟต์แวร์ทำงานหนักเกินไปหรือไม่

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

เราจะพบการประนีประนอมที่ดีได้อย่างไร?

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

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

ถ้อยคำส

... คำถามที่ถูกอ้างถึงและคำตอบนั้นไม่ครอบคลุมถึงด้านการจัดการโครงการ

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

หากคุณใช้หลักการ DRY แทนและลองค้นหาสิ่งที่เป็นนามธรรมซึ่งมากหรือน้อยจะกำจัดรหัสที่ซ้ำกันซึ่งต่างออกไป

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

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

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

ในกรณีหนึ่งเราติดกับปืนของเราเมื่อผู้บริหารบอกว่า "คุณใช้เวลาในการออกแบบมากเกินไปไปได้" และเพื่อนร่วมงานพูดว่า "มันมีชั้นเรียนมากเกินไป" โครงการย่อยที่ซับซ้อนน้อยกว่านี้น่าจะใช้เวลาประมาณ 1 เดือน (ฉันคิดว่ามันเป็นการคาดเดา ballpark OK) แต่ใช้เวลา 5 เดือน 3 เดือนของการทดสอบ / แก้ไขเพราะมันเป็น POS "แต่เราไม่มีเวลาออกแบบ!" พวกเขาพูดอย่างนั้นจริง ๆ

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

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