หลักการที่เป็นของแข็งเทียบกับ YAGNI

43

หลักการ SOLID กลายเป็น YAGNI เมื่อใด

ในฐานะโปรแกรมเมอร์เราทำการแลกเปลี่ยนตลอดเวลาระหว่างความซับซ้อนการบำรุงรักษาเวลาในการสร้างและอื่น ๆ ในบรรดาคนอื่น ๆ แนวทางที่ฉลาดที่สุดสองข้อในการเลือกอยู่ในใจของฉันคือหลักการของ SOLID และ YAGNI หากคุณไม่ต้องการมัน อย่าสร้างมันและรักษาความสะอาด

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

ตามที่ถามในความคิดเห็น:

design philosophy solid

— KeesDijk
แหล่งที่มา

ชื่อไม่ควรเป็นเช่นกันSOLID principle vs YAGNI?

— Wolf

2

@ หมาป่า: มันเป็นพหูพจน์ "SOLID (ความรับผิดชอบเดี่ยว, เปิด - ปิด, การทดแทน Liskov, การแยกส่วนต่อประสานและการพึ่งพาอาศัยกัน) เป็นคำย่อช่วยจำที่นำโดย Michael Feathers สำหรับ 'ห้าหลักการแรก' ที่ตั้งชื่อโดย Robert C. Martin ยุค 2000 ที่ย่อมาจากห้าหลักการพื้นฐานของการเขียนโปรแกรมและการออกแบบเชิงวัตถุ "

— logc

55

มันมักจะยากที่จะตัดสินวิธีการจาก screencast เนื่องจากปัญหาที่เลือกสำหรับการสาธิตมักจะมีขนาดเล็กมากที่การใช้หลักการอย่างเช่น SOLID อย่างรวดเร็วทำให้ดูเหมือนว่าโซลูชันนั้นถูก overengineered อย่างสมบูรณ์

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

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

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

— อดัมเลียร์
แหล่งที่มา

นี่คือสิ่งที่ฉันคิดด้วย เป็นคำพูดที่ฉันไม่ได้ตัดสินโดย screencast ฉันแค่คิดว่ามันเป็นตัวอย่างที่ดีของซอฟต์แวร์ที่สามารถเติบโตได้เมื่อใช้ SOLID

— KeesDijk

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

— Berin Loritsch

YAGNI and SOLID coexistข้อสรุปที่ดี แม้ว่ามันอาจจะเป็นจุดเริ่มต้นที่ดี

— Wolf

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

— johnny

19

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

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

YAGNI (คุณไม่ต้องการมัน [ตัวย่อที่แปลกตาของอเมริกา]) เกี่ยวข้องกับการประหยัดเวลาของนักพัฒนาเพิ่มฐานรากคอนกรีต inforced ใหม่ไปยังสะพานที่มีวัตถุประสงค์เพื่อขยายลำห้วยกว้าง 3 ฟุตเท่านั้นเมื่อสะพานไม้ที่เรียบง่ายจะทำเพียง ละเอียด. หากเราทอดข้ามแม่น้ำกว้างหนึ่งไมล์และต้องการสนับสนุนรถเทรลเลอร์รถแทรกเตอร์หลายคันแน่นอนว่าเราจะต้องมีงานฐานรากที่พิเศษ ในสาระสำคัญ YAGNI จะบอกให้คุณดูภาพที่ใหญ่ขึ้นและการออกแบบสำหรับความต้องการในปัจจุบัน มันคือการจัดการปัญหาในการทำสิ่งที่ซับซ้อนเกินไปเพราะเราคาดการณ์ความต้องการที่เป็นไปได้จำนวนมากที่ลูกค้ายังไม่ได้ระบุ

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

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

— Berin Loritsch
แหล่งที่มา

ใช่เห็นด้วย .. ไม่มีวิธีกระสุนเงินที่เหมาะกับทุกสถานการณ์

— EL Yusubov

ของคุณคือไกลโดยไม่เป็นที่เห็นได้ชัดว่าเป็นmake sure the pieces of the bridge fit together can be maintained over time

— Wolf

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

— ร่า

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

— Berin Loritsch

@BerinLoritsch ซึ่งเป็นเหตุผลที่ฉันยอมรับว่าถ้าคุณต้องการ 5 ฟุตคุณสร้าง 5 ฟุต แต่คุณไม่ต้องสร้าง 5 ฟุตโดยการวางท่อสองเท่า 2x4 วินาทีกับพื้น คุณทำสิ่งที่คุณต้องการและคุณทำได้ดี (ถึงแม้ว่าการเปรียบเทียบจะค่อนข้างแตกสลาย)

— sara

9

หลักการโซลิดนั้นไม่จำเป็นเมื่อมันใช้กับแอพพลิเคชั่น มิฉะนั้นพวกเขาก็มักจะต้องการ

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

เป็นความแตกต่างระหว่างคลาสรถยนต์ที่มีการกำหนดขอบเขตที่ดี (SOLID) และคลาสรถยนต์ที่มีความสามารถในการรักษาตัวเอง (YAGNI) ก่อนที่ลูกค้าจะขอ

— George Stocker
แหล่งที่มา

1

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

— Wolf

2

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

— sara

บ่อยครั้งที่แอปพลิเคชันแบบโยนทิ้งไม่ได้

— Tulains Córdova

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

— johnny

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

— icc97

4

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

เมื่อเร็ว ๆ นี้ฉันพยายามที่จะเข้าใจเมื่อฉันควรใช้หลักการความรับผิดชอบเดี่ยว ( นี่คือสิ่งที่ฉันเกิดขึ้น)

หวังว่านี่จะช่วยได้!

— แบรนดอน
แหล่งที่มา

2

มีการอ้างถึงไอน์สไตน์ (อาจเป็นรูปแบบของจริง ):

“ ทุกสิ่งควรทำอย่างง่ายที่สุดเท่าที่จะทำได้ แต่ไม่ง่ายกว่านี้”

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

— LogC
แหล่งที่มา

จุดดี: you never know if a program is 'throw-away' code- ดีฉันคิดว่าความคิดอีกทางเลือกไม่ดี

— Wolf

@ Wolf: ใช่ฉันกำลังขยายตามลำดับขั้นตอนที่ฉันคิดว่าดีที่สุด (สรุปใน 'ทำครั้งแรกให้เป็นไปได้แล้วทำให้มันสวยงามแล้วทำให้มันเร็ว' คำขวัญ) แต่จากนั้นฉันก็คิดว่า ... YAGNI :)

— logc

1

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

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

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

— Doval
แหล่งที่มา

0

ฉันคิดว่าคุณควรเริ่ม YAGNI และทุกครั้งที่มีความจำเป็น

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

คุณไม่ต้องเสียเวลาเพราะคุณจะต้องทำงานต่อไป (ตอนแรก) และทุกที่ที่คุณต้องการรหัสของคุณนั้นดีและเรียบร้อย

ฉันเดาว่าคุณสามารถเรียกมันว่าการประเมิน SOLID ที่ขี้เกียจ

— Binyamin
แหล่งที่มา

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

— Binyamin