antipattern ตรงข้ามกับชื่อของอะไรคือ [ปิด]


101

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

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

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

มีชื่อสามัญสำหรับ antipattern ประเภทนี้หรือไม่?

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

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


52
พึ่งพานรก นั่นคือสิ่งที่ฉันคิดได้
Machado

5
@Machado: ดีแม้ว่าฉันจะบอกว่าการพึ่งพานรกเป็นผลโดยตรงจากความอุดมสมบูรณ์ของรูปแบบการต่อต้านนี้ ในกรณีที่ระบบที่ซับซ้อนมากอาจเป็นผลมาจากความซับซ้อนที่ตรงไปตรงมา
เอสเอฟ

27
ฉันจะเรียกมันว่า"การพึ่งพาอาศัยกัน"แอนะล็อกกับFeature_creepหรือScope_creepซึ่งมีการเพิ่มฟีเจอร์ที่ไม่พึงประสงค์ในผลิตภัณฑ์มากขึ้นเรื่อย ๆ
k3b

21
ความล้มเหลวของ Tle left-padเป็นตัวอย่างชีวิตจริงของโรคนี้
เอสเอฟ

13
ฉันขอแนะนำให้เราเริ่มเรียกรวมกันว่านี่เป็น LeftPad
RubberDuck

คำตอบ:


9

ไม่ไม่มีชื่อรูปแบบการต่อต้านที่ใช้กันทั่วไปซึ่งครอบคลุมสิ่งที่คุณกำลังอธิบาย


4
มันจะปรากฏขึ้นพร้อมกับจำนวนความคิดข้อเสนอแนะและการอภิปรายที่เกิดขึ้นจริงถูกต้อง
เอสเอฟ

3
ฉันรู้สึกสกปรกที่ทำสิ่งนี้
เอสเอฟ

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

1
@AnoE "มีชื่อสามัญสำหรับ antipattern ประเภทนี้หรือไม่?" หลักฐานในการแสดงความคิดเห็นและคำตอบดังกล่าวแสดงให้เห็นอย่างมากว่าไม่มี จริงมันไม่ตอบชื่อ แต่มันตอบคำถามเอง
Kroltan

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

49

ค้อนทองคำ

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

แหล่งที่มา: xkcd 801

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


5
อัปโหลดแล้วและคุณยังสามารถหาได้จากวิกิพีเดีย: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument
Pierre.Sassoulas

3
ฉันจะลงคะแนนถ้าฉันมีตัวแทน มันไม่ได้ตอบคำถามโดยรวม แต่มีหนึ่งคำ (ถูกต้อง) ที่ตอบเพียงหนึ่งในสถานการณ์ที่แนะนำ
David

3
ตรงกันข้ามถูกถาม นี่เป็นเหมือนการยืนยันว่า "Becquerel" (การแผ่รังสีหน่วยเป็น s ^ -1) สามารถใช้กับเพลงแทน Hertz (hz, หน่วยเป็น s ^ -1) เพราะพวกเขาทั้งคู่หมายถึง "ต่อวินาที"
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersenฉันเคยได้ยินเพลงอันตรายบ้างในวันของฉัน

34

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


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

18

หน้าวิกิพีเดียใน " คิดค้นที่นี่ " อธิบายสถานการณ์ที่แตกต่างกันเล็กน้อย แต่มีผลลัพธ์ที่คล้ายคลึงกันมาก อธิบายความเกลียดชังของทีมที่มีต่อการสร้างรหัสของตัวเองเมื่อสามารถใช้ฟังก์ชันที่เทียบเท่าได้

ฉันจะยืนยันว่าชื่อนี้เป็นความเข้าใจผิดเล็กน้อย ให้ความรู้สึกเมื่อพูดถึงบริบทตรงข้ามกับNot Invented ที่นี่ซึ่ง IMHO เป็นคำพ้องความหมายสำหรับการสร้างวงล้อใหม่


13

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


9

อย่าใช้ปืนใหญ่เพื่อฆ่ายุง

ขงจื๊อ

AKA Overkill


5
วลีภาษาอังกฤษทั่วไป (สหราชอาณาจักร) คือ "การใช้ค้อนขนาดใหญ่เพื่อแคร็ก"
nigel222


ด้วย: "การล่ากวางด้วยรถถัง"
Jeutnarg

"การตบแมลงวันด้วยค้อน"

อย่าใช้ค้อนเพื่อฆ่าแมลงวัน
jeffmcneill

8

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

ถ้าเราหวังว่าเราจะได้ชี้แจงกับระยะเช่นการอ้างอิงป่อง


5

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

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

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


5

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

อย่างน้อยฉันก็ยืนยันว่านี่คือสิ่งที่เกิดขึ้นจริงๆ เมื่อฉันพบบางสิ่งที่คล้ายกับสิ่งที่คุณอธิบาย

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

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

ห้องสมุดที่ทำสิ่งที่ง่ายก็จะง่ายเช่นกัน มันไม่น่าเป็นไปได้ที่จะทำให้คุณปวดหัวที่คำถามของคุณมีความหมาย

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

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

ปัญหาที่เกิดขึ้นที่นี่ไม่ได้ล้มเหลวที่จะบูรณาการล้อจริงๆต่อ se


4

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

ถ้านี่เป็นรูปแบบการต่อต้านมันมักจะเรียกว่าล็อคผู้ขาย


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

@Ben - ตกลงฉันชอบ Framework ผูกติดกับผู้ขายล็อคดีกว่า คำถามนี้เป็นประเภทของความคิดเห็นตามและนี่คือสิ่งแรกที่โผล่เข้ามาในหัวของฉัน
Jon Raynor

0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.