การสร้างล้อใหม่ทั้งหมดนั้นเลวร้ายจริง ๆ ไหม?

ความรู้ทั่วไปในการเขียนโปรแกรมที่ reinventing ล้อไม่ดีหรือความชั่วร้าย

แต่ทำไมล่ะ

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

ที่ทำให้ฉันคำถามนี้:

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

ทำไมเขาถึงต้องใช้สิ่งก่อสร้างในตัวของตัวเอง?

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

ขึ้นอยู่ ..

เกี่ยวกับบริบท:

เป็นเรื่องที่ดีเมื่อ:

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

มันไม่ดีเมื่อ:

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

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

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

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

แค่ถามเขาว่าข้อบกพร่องคืออะไร

โดยทั่วไปแล้วฉันหลีกเลี่ยงการสร้างวงล้อใหม่หากฟังก์ชั่นที่ฉันต้องการหรือสิ่งที่ใกล้เคียงมีอยู่ในห้องสมุดมาตรฐานของภาษาที่ฉันใช้

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

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

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

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

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

หากผู้คนไม่ได้คิดค้นใหม่ล้อโลกจะเต็มไปด้วยสิ่งเหล่านี้ ..

นี่คือบทสนทนาจากที่ทำงานของฉัน:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

มีสองตัวเลือก: สร้างใหม่ล้อหรือใช้ Colorama นี่คือสิ่งที่แต่ละตัวเลือกจะได้รับ:

ใช้ Colorama

• อาจจะเร็วกว่านี้เล็กน้อยในการเริ่มทำงาน
• การเพิ่มการพึ่งพาบุคคลที่สามสำหรับสิ่งเล็กน้อย
• คุณยังคงโง่เหมือนก่อนใช้ Colorama

ประกอบล้อใหม่

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

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

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

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

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

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

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

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

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

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

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

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

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

นอกจากนี้การใช้ล้อที่มีอยู่มักเพิ่มข้อ จำกัด ให้กับโครงการของฉันที่ฉันไม่ต้องการ ตัวอย่างเช่น:

• ล้อที่มีอยู่ต้องใช้ภาษาและ / หรือรูปแบบการเขียนโปรแกรมที่แตกต่างจากที่ฉันต้องการใช้
• ล้อที่มีอยู่ใช้งานได้กับภาษาดั้งเดิมเท่านั้น (เช่น Python 2 แทนที่จะเป็น Python 3)
• ในกรณีที่มีการแลกเปลี่ยนระหว่างประสิทธิภาพความยืดหยุ่นและความเรียบง่ายล้อที่มีอยู่ทำให้ตัวเลือกที่ไม่ดีสำหรับกรณีการใช้งานของฉัน (เป็นที่รู้จักกันดีในเรื่องการสร้างใหม่แม้ฟังก์ชั่นจากห้องสมุดที่ฉันเขียนเองในกรณีเหล่านี้โดยปกติแล้วมันเป็นเพราะฉันเขียนรุ่นไลบรารี่ของฟังก์ชั่นทั่วไปและมีประสิทธิภาพพอสมควรเมื่อฉันต้องการบางสิ่งบางอย่างที่รวดเร็ว กรณี.)
• ล้อที่มีอยู่มี cruft ดั้งเดิมมากมายที่ไร้ประโยชน์โดยสิ้นเชิงในกรณีของรหัสใหม่ แต่ก็ทำให้ชีวิตยากลำบาก (เช่นไลบรารี Java ที่ฉันใช้ซึ่งบังคับให้ฉันใช้คลาสคอนเทนเนอร์เส็งเคร็งเพราะมันเขียนไว้ก่อนชื่อสามัญ) .
• วิธีที่ล้อรุ่นปัจจุบันมีปัญหานั้นแตกต่างจากกรณีที่ใช้งานได้สะดวก (ตัวอย่างเช่นบางทีมันอาจจะสะดวกสำหรับฉันที่จะมีกราฟกำกับที่แสดงโดยวัตถุโหนดและการอ้างอิง แต่วงล้อที่มีอยู่ใช้เมทริกซ์ adjacency หรือในทางกลับกันบางทีมันอาจจะสะดวกสำหรับฉันที่จะวางข้อมูลของฉันในลำดับหลักของคอลัมน์ ล้อที่มีอยู่ยืนยันในแถวหลักหรือในทางกลับกัน)
• ห้องสมุดเพิ่มการพึ่งพาที่เปราะบางเป็นจำนวนมากซึ่งเป็นปัญหาใหญ่ในการติดตั้งและใช้งานทุกที่ที่ฉันต้องการปรับใช้โค้ดของฉันเมื่อสิ่งที่ฉันต้องการก็คือฟีเจอร์ย่อย ๆ ในทางกลับกันในกรณีนี้บางครั้งฉันก็แยกคุณลักษณะที่ฉันต้องการลงในไลบรารีใหม่ที่มีขนาดเล็กลงหรือเพียงแค่คัดลอก / วางหากไลบรารีเป็นโอเพ่นซอร์สและโค้ดเบสทำให้ง่ายพอสมควร (ฉันทำสิ่งนี้ด้วยห้องสมุดขนาดใหญ่ที่ฉันเขียนเองไม่ใช่เฉพาะกับคนอื่น)
• ล้อที่มีอยู่พยายามที่จะปฏิบัติตามอวดรู้กับมาตรฐานบางอย่างที่ไม่สะดวกและไม่เกี่ยวข้องกับกรณีการใช้งานของฉัน

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

มีรหัสมากและฉันไม่ได้มีเวลามากที่จะกลับไปและรหัสใหม่บางสิ่งบางอย่างถ้ามันส่งผลกระทบต่อการผลิต

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

การสร้างวงล้อใหม่เป็นวิธีที่ดีในการเรียนรู้วิธีการทำงานของล้อ แต่มันไม่ใช่วิธีที่ดีในการสร้างรถ

ปัจจุบันฉันทำงานให้กับ cheapskates จำนวนมาก

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

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

นำเสนอเกี่ยวกับการสร้าง VS ซื้อ
บทความเกี่ยวกับการสร้าง VS ซื้อ

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

ทำไมเขาถึงต้องใช้สิ่งก่อสร้างในตัวของตัวเอง?

เวอร์ชันในตัวจะมีผู้คนจำนวนมากต่อสู้กับมัน - ดังนั้นการค้นหาและแก้ไขข้อผิดพลาดมากกว่ารหัส homebrew ของคุณสามารถมีได้

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

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

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

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

ไม่ว่าจะคิดค้นล้อใหม่หรือไม่ก็ตามจะเป็นเรื่องต้นทุน / ผลประโยชน์ ราคาค่อนข้างชัดเจน ...

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

สิ่งสุดท้ายคือสิ่งสำคัญ - มีการโพสต์บล็อกบางแห่งเตือนเกี่ยวกับแนวโน้มที่จะ "โยนรหัสเก่าออกไปและเริ่มต้นจากศูนย์" บนพื้นฐานที่ว่า cruft เก่าจำนวนมากที่คุณไม่เข้าใจนั้นเป็นสิ่งที่จำเป็นจริงๆ มีเรื่องเตือนเกี่ยวกับ Netscape, IIRC

ข้อดีสามารถ ...

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

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

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

Joel เขียนบทความเกี่ยวกับ Not-invented ที่นี่ซึ่งพูดถึงโวลุ่มเกี่ยวกับเมื่อการเขียนโค้ดและซอฟต์แวร์ใหม่ไม่ได้และไม่มีประโยชน์

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

ตัวอย่างเช่นฉันจะไม่เขียนโค้ด JavaScript ตั้งแต่ต้น ฉันจะเริ่มต้นด้วย jQuery และสร้างแอปพลิเคชันของฉันแทนเฟรมเวิร์กนั้น

กฎง่ายๆของฉัน:

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

การเป็น "เลว" หรือแม้แต่ "ชั่วร้าย" เป็นคำที่ค่อนข้างแข็งแกร่ง

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

สิ่งนี้ใช้ไม่ได้กับโปรแกรม Java เนื่องจาก JVM มีการกำหนดไว้อย่างเข้มงวด แต่อัลกอริทึมบางตัวยังคงยากที่จะทำให้ถูกต้อง ตัวอย่างเช่น Joshua Bloch อธิบายถึงวิธีการค้นหาไบนารีแบบง่าย ๆ แบบหลอกในไลบรารีรันไทม์ Java ที่มีข้อบกพร่องซึ่งใช้เวลาเก้าปีในการแสดง:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

พบแก้ไขและแจกจ่ายในการแจกจาวาในอนาคต

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

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

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

ฉันเพิ่งบล็อกความคิดของฉันในหัวข้อนี้ เพื่อสรุป:

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

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

3. ประโยชน์หลักอย่างหนึ่งของการสร้างกรอบงานของคุณคือคุณไม่ต้องรับผิดชอบข้อบกพร่องของคนอื่น (นี่คือปรัชญาของอเมซอน ) ลองคิดดูด้วยวิธีนี้: สิ่งใดบ้างที่จะบอกลูกค้าได้ดีกว่า -

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

   "เว็บไซต์ของเราพังและเราสามารถแก้ไขได้ทันที"

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

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

การประกอบล้อใหม่ไม่เลวมันเป็นคำแถลงของคนขี้เกียจที่จะหลีกเลี่ยงการทำงานหนัก แม้แต่ผู้เขียนเฟรมเวิร์กก็สามารถสร้างใหม่ได้ กรอบงาน. Net ทั้งหมดได้รับการคิดค้นใหม่เพื่อทำในสิ่งที่ COM เสนอให้

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

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

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

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

1. หากไม่จำเป็นจริงๆ
2. ถ้าเป็นคนอื่นทำมันเมื่อคุณสามารถมี

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

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

สมมติว่าฉันกำลังประเมินไลบรารี 'Forms-plus' ซึ่งเพิ่งได้รับความนิยมเมื่อเร็ว ๆ นี้และช่วยจัดการกับฟอร์ม มันมีหน้าที่เชื่อมโยงไปถึงที่ยอดเยี่ยมกราฟิกสุดเจ๋งที่ทันสมัยและ -cult- (อุ๊ปส์ฉันหมายถึงชุมชน) รอบตัวที่สาบานว่าจะทำให้รูปแบบยอดเยี่ยมอีกครั้งได้อย่างไร แต่ "forms-plus" เป็นนามธรรมที่ด้านบนของ "แบบฟอร์ม" "รูปแบบ" เป็นไปได้ แต่ยุ่งยากในการจัดการดังนั้นสิ่งที่ทำให้สิ่งที่ทำให้เป็นที่นิยมนั้นง่ายขึ้น

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

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

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

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

ฉันเขียนบทความเล็กน้อยเกี่ยวกับเรื่องนี้ - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

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