การลบค่าตายตัวและการออกแบบการป้องกันเทียบกับ YAGNI

พื้นหลังเล็กน้อยก่อน ฉันกำลังค้นหารหัสจากอายุ -> อัตรา มีวงเล็บอายุ 7 รายการดังนั้นตารางการค้นหาคือ 3 คอลัมน์ (จาก | ถึง | อัตรา) ด้วย 7 แถว ค่าไม่ค่อยมีการเปลี่ยนแปลง - เป็นอัตราที่มีการออกกฎหมาย (คอลัมน์แรกและคอลัมน์ที่สาม) ที่มีค่าคงเดิมเป็นเวลา 3 ปี ฉันคิดว่าวิธีที่ง่ายที่สุดในการจัดเก็บตารางนี้โดยไม่ต้องเข้ารหัสยากอยู่ในฐานข้อมูลในตารางการกำหนดค่าส่วนกลางเป็นค่าข้อความเดียวที่มี CSV (ดังนั้น "65,69,0.05,70,74,0.06" เป็นวิธีการที่ 65-69 และ 70-74 ชั้นจะถูกเก็บไว้) ค่อนข้างง่ายต่อการแยกวิเคราะห์แล้วใช้

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

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

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

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

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

แก้ไขในขณะที่คำตอบทั้งหมดน่าสนใจมากเพราะฉันคิดว่านี่เป็นตัวเลือกการออกแบบของแต่ละคน แต่ฉันคิดว่าคำตอบที่ดีที่สุดคือ@ Corbin'sและ@EZ Hart'sเนื่องจากพวกเขานำสิ่งที่ฉันไม่ได้พิจารณามาพิจารณา:

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

ฉันกำลังทำเครื่องหมาย @ คำตอบของ Corbin ให้ถูกต้องเพราะมันเปลี่ยนสมมติฐานการพัฒนาต้นทุนและฉันอาจจะเพิ่มเครื่องมือสร้างรหัสบางอย่างลงในคลังแสงของฉันในอนาคตอันใกล้

คุณพบข้อบกพร่องในกระบวนการพัฒนาของคุณ เมื่อมันเจ็บปวดที่จะทำสิ่งที่ถูกต้อง (สร้างตาราง repo การทดสอบ repo การทดสอบแบบเรียบ ... ) นักพัฒนาจะค้นหาวิธีรอบ ๆ ซึ่งมักเกี่ยวข้องกับการทำสิ่งผิด ในกรณีนี้มันดึงดูดให้คุณปฏิบัติต่อข้อมูลแอปพลิเคชันเป็นตรรกะของแอปพลิเคชัน อย่าทำมัน ให้เพิ่มการทำงานอัตโนมัติที่มีประโยชน์ลงในกระบวนการพัฒนาของคุณแทน เราใช้CodeSmithเพื่อสร้างรหัสที่น่าเบื่อและไม่มีใครต้องการเขียน หลังจากที่เราสร้างตารางเราเรียกใช้ CodeSmith และมันจะสร้าง DAOs, DTOs และ stubs ออกการทดสอบหน่วยสำหรับแต่ละ

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

โอ้และไม่เก็บข้อมูลของคุณในรูปแบบที่ต้องการการประมวลผลเพิ่มเติม (CSV) นั่นเป็นเพียงการเพิ่มขั้นตอนพิเศษที่ต้องการความสนใจและการทดสอบของคุณ

หากต้องการปิดและขยายคำตอบของ @ Thorbjørn Ravn Andersen: การคำนวณ / ค้นหาในที่เดียวเป็นการเริ่มต้นที่ดี

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

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

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

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

โชคดี

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

ให้ฉันดูว่าฉันได้รับคำถามของคุณถูกต้องหรือไม่ คุณมี 2 ตัวเลือกในการปรับใช้คุณสมบัติ: ทั้งฮาร์ดโค้ดและคุณสมบัติของคุณนั้นใช้งานง่าย (btu คุณไม่ชอบส่วน hardcode) หรือคุณมีความพยายามอย่างมากในการ "ทำซ้ำ" สิ่งต่างๆ ดังนั้นคุณสามารถพัฒนาฟีเจอร์ของคุณได้อย่างสะอาดหมดจด ถูกต้องหรือไม่

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

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

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

นี่จะเป็นแนวทางของฉัน :)

นี่คือรายการที่ "จะไม่เปลี่ยนแปลง" จนกว่าจะมี มันหลีกเลี่ยงไม่ได้ที่มันจะเปลี่ยนแปลง แต่เวลานั้นอาจจะค่อนข้างไกล

การให้เหตุผลของคุณถูกต้อง ในเวลานี้ลูกค้าไม่ได้ขอความสามารถในการเปลี่ยนแปลงอัตราเหล่านั้นได้อย่างง่ายดาย เช่น YAGNI

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

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

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

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

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

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

ฉันคิดว่าวิธีที่ง่ายที่สุดในการจัดเก็บตารางนี้โดยไม่ต้องเข้ารหัสยากอยู่ในฐานข้อมูลในตารางการกำหนดค่าส่วนกลางเป็นค่าข้อความเดียวที่มี CSV (ดังนั้น "65,69,0.05,70,74,0.06" เป็นวิธีการที่ 65-69 และ 70-74 ชั้นจะถูกเก็บไว้

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

ตารางต้องการ 2 ฟิลด์ไม่ใช่ 3. อายุและอัตรา แถวถัดไปนี้มีค่าสูงสุด! คุณกำลังทำให้ปกติโดยที่ไม่รู้ตัว!

นี่คือ Sql เพื่อรับอัตราสำหรับคนที่อายุ 67 ปี

Select * from RateTable where Age in (Select max(age) from RateTable where age <=67) 

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

แก้ไข: ตามที่คนอื่นพูดว่ารักษารหัสได้รับอัตราการรวมศูนย์ในกรณีที่โครงสร้าง chages ทั้งอัตรา

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

ฉันมีความทรงจำที่ห่างไกลจากการอ่านคนที่มีความคล่องแคล่ว / OOP (เช่น Dave Thomas หรือ Kent Beck หรือบางคน) ที่บอกว่ากฎง่ายๆสำหรับการทำสำเนารหัสเป็นสองครั้งและสองครั้งเท่านั้น: อย่า refactor ในครั้งแรกที่คุณทำซ้ำตั้งแต่ คุณอาจเคยเขียนมันสองครั้งในชีวิตของคุณ แต่ครั้งที่สาม ...

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

รหัสยากในฟังก์ชั่น

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