เมื่อใดที่จะชอบวิธีการแก้ปัญหาทั่วไปมากกว่าการแก้ปัญหาเฉพาะกรณี

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

เห็นได้ชัดว่าการแก้ปัญหาในทันทีนั้นเร็วขึ้นอย่างไรก็ตามการสร้างโซลูชันทั่วไปจะช่วยประหยัดเวลาในอนาคต

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

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

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

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

ประสบการณ์.

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

แล้วถึงแม้คุณไม่ได้จริงๆรู้ ; คุณแค่คาดเดาได้ดีกว่า

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

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

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

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

ทำครั้งเดียวทำสองครั้งทำสามครั้งพูดคุย

หนึ่งสองหลาย!

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