เป็นคนใจกว้างในสิ่งที่คุณยอมรับ ... หรือไม่?

[คำปฏิเสธ: คำถามนี้เป็นอัตนัย แต่ฉันต้องการคำตอบที่ได้รับการสนับสนุนจากข้อเท็จจริงและ / หรือการสะท้อนกลับ]

ฉันคิดว่าทุกคนรู้เกี่ยวกับหลักการความแข็งแกร่งซึ่งมักจะสรุปตามกฎหมายของ Postel:

ระมัดระวังในสิ่งที่คุณส่ง มีอิสระในสิ่งที่คุณยอมรับ

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

ฉันสังเกตเห็นว่ามี RFC ของโปรโตคอล TCP เห็นว่า "ยอมรับความล้มเหลว" เว้นแต่จะระบุไว้เป็นอย่างอื่น ... ซึ่งเป็นพฤติกรรมที่น่าสนใจที่จะพูดน้อย

มีตัวอย่างอื่น ๆ ของการประยุกต์ใช้หลักการนี้ตลอดการค้าซอฟต์แวร์ที่ปรากฏขึ้นอย่างสม่ำเสมอเพราะพวกเขามีผู้พัฒนาที่ถูกกัดตั้งแต่หัวจรดหัวของฉัน:

• การแทรกเซมิโคลอน Javascript
• การแปลง builtin C (เงียบ) (ซึ่งจะไม่เลวร้ายหากไม่ตัดทอน ... )

และมีเครื่องมือที่จะช่วยทำให้เกิดพฤติกรรม "ฉลาด":

• การจับคู่ชื่ออัลกอริทึมการออกเสียง ( Double Metaphone )
• ขั้นตอนวิธีระยะทางสตริง ( ระยะทาง Levenshtein )

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

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

และนี่คือสิ่งที่นำฉันไปสู่คำถามต่อไปนี้:

เมื่อออกแบบอินเทอร์เฟซ (ไลบรารีคลาสข้อความ) คุณพึ่งพาหลักการความทนทานหรือไม่?

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

ผมจะบอกว่าความทนทานเมื่อมันไม่แนะนำงงงวย

ตัวอย่างเช่น: เมื่อแยกวิเคราะห์รายการที่คั่นด้วยเครื่องหมายจุลภาคหรือไม่มีช่องว่างก่อน / หลังเครื่องหมายจุลภาคจะไม่เปลี่ยนความหมายของความหมาย

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

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

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

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

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

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

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

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

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

เบราว์เซอร์ควรแสดงข้อความแสดงข้อผิดพลาดแทนที่จะพยายามแก้ไขภายใต้ฝาครอบ นั่นจะทำให้ผู้บังคับบังโคลนทุกคนต้องแก้ไขระเบียบ

ฉันแบ่งอินเทอร์เฟซออกเป็นหลายกลุ่ม (เพิ่มมากขึ้นถ้าคุณชอบ):

1. ผู้ที่อยู่ภายใต้การควบคุมของคุณควรเข้มงวด (โดยทั่วไปคือคลาส)
2. API ไลบรารีที่ควรอยู่ด้านเข้มงวด แต่ควรตรวจสอบความถูกต้องเป็นพิเศษ
3. ส่วนต่อประสานสาธารณะที่ต้องจัดการกับการล่วงละเมิดทุกประเภทที่เข้ามา (โดยทั่วไปคือโปรโตคอลอินพุตของผู้ใช้ ฯลฯ ) ที่นี่มีความแข็งแกร่งในการป้อนข้อมูลจ่ายจริงคุณไม่สามารถคาดหวังว่าทุกคนจะแก้ไขสิ่งที่พวกเขา และจำไว้ว่าสำหรับผู้ใช้มันจะเป็นความผิดของคุณถ้าแอปพลิเคชันไม่ทำงานไม่ใช่บุคคลที่ส่งอึที่จัดรูปแบบไม่ดี

ผลลัพธ์จะต้องเข้มงวด

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

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

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

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

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

ไฟล์ศัพท์แสงยังมีเรื่องราวสยองขวัญที่ "คาดเดา" เจตนาของผู้ใช้

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

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

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

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

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

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

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

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

ความพยายามส่งมอบฟังก์ชันการทำงาน 2010 ในเบราว์เซอร์ปี 1999 เมื่อคุณสามารถส่งมอบหน้าเทคโนโลยี่ที่ต่ำกว่านั้นเป็นอีกตัวอย่างหนึ่งของการออกแบบที่ดูไร้สาระ โอกาสที่ถูกพัดและเงินที่ฉันเคยเห็นเสียไปกับเวลาของนักพัฒนาที่ใช้ในการแก้ปัญหาข้อผิดพลาดเพียงเพื่อให้ได้มุมที่โค้งมนในองค์ประกอบที่อยู่เหนือพื้นดิน! @ # $ พื้นหลังไล่ระดับสี และเพื่ออะไร เพื่อส่งมอบหน้าเทคโนโลยีที่สูงขึ้นซึ่งมีประสิทธิภาพต่ำต่อเทคโนโลยีที่ได้รับการพิสูจน์แล้วในขณะที่ จำกัด ตัวเลือกของคุณสำหรับเบราว์เซอร์ปลายทางที่สูงขึ้น

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

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

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

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

ไม่ว่าในกรณีใด ๆ ที่ไม่ชัดเจนและไม่แน่นอน 100% ว่าอินพุตหนึ่งรายการควรถูกแปลงเป็นอีกรายการหนึ่งคุณไม่ควรทำการแปลงด้วยเหตุผลหลายประการที่กล่าวถึงไปแล้ว

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

ฉันอยากจะแนะนำให้คุณอ่านคำถามของฉันในกรณีที่คล้ายกันนี้