ค่าเริ่มต้น - พวกเขาดีหรือไม่ดี?

คำถามเกี่ยวกับค่าเริ่มต้นโดยทั่วไป - ค่าฟังก์ชันส่งคืนค่าเริ่มต้น, ค่าพารามิเตอร์เริ่มต้น, ตรรกะเริ่มต้นสำหรับสิ่งที่หายไป, ตรรกะเริ่มต้นสำหรับการจัดการข้อยกเว้น, ตรรกะเริ่มต้นสำหรับการจัดการเงื่อนไขขอบ ฯลฯ

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

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

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

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

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

จะขอบคุณการป้อนข้อมูลใด ๆ

ไชโย

แก้ไข:

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

แนวคิดของการประชุมผ่านการตั้งค่าคอนฟิกเป็นไปไม่ได้โดยไม่มีค่าเริ่มต้นที่สมเหตุสมผล คำสำคัญที่นี่คือ "เหมาะสม" ค่าเริ่มต้นจะต้องสมเหตุสมผลอย่างน้อย 80% (หากไม่มาก) ของการใช้งานทั้งหมดของไลบรารี / บริการ / กรอบงาน

กฎทั่วไปของหัวแม่มือ:

• หากค่าเหมาะสมสำหรับการใช้ 80% หรือมากกว่านั้นจะต้องเป็นค่าเริ่มต้น
• หากไม่มีค่าที่ใช้สำหรับกรณีส่วนใหญ่อย่าใช้ค่าเริ่มต้น
• ค่าเริ่มต้นป้องกันข้อผิดพลาดที่โง่จากรหัสการตั้งค่า หากค่าเริ่มต้นเหมาะสมสำหรับกรณีส่วนใหญ่ลดจำนวนคนที่ยุ่งกับการกำหนดค่าการทำงาน
• การกำหนดค่าที่ไม่ได้มาตรฐานจะปรากฏให้เห็นมากขึ้นเมื่อคุณใช้ค่าเริ่มต้น
• Badค่าเริ่มต้นที่เลวร้ายยิ่งกว่าไม่มีค่าเริ่มต้น

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

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

ค่าเริ่มต้นนั้นใช้ได้อย่างสมบูรณ์แบบเมื่อพวกเขาเป็นค่าเริ่มต้นที่มีสติ

คุณอาจใช้รูปแบบแป้นพิมพ์เริ่มต้นพร้อมการแมปปุ่มเริ่มต้นการแมปปุ่มเมาส์เริ่มต้นเบราว์เซอร์เริ่มต้นการพิมพ์ในภาษาเริ่มต้นของระบบการบูตจากระบบปฏิบัติการเริ่มต้นในตัวโหลดการบูตเมนูตำแหน่งเริ่มต้นชุดรูปแบบสีเริ่มต้น ความกว้าง / ความสูง / ใบหน้า / สไตล์ชุดอักขระเริ่มต้นความละเอียดจอภาพเริ่มต้นเริ่มต้น ... คุณจะได้รับแนวคิด

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

นอกจากนี้การจัดการข้อยกเว้น "catch-all" นั้นเป็นข้อบกพร่องในการออกแบบมากกว่าที่คุณจะเรียกว่า "default"

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

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

จัดการกับสาเหตุที่แท้จริงไม่ใช่อาการ

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

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

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