เราควรจะป้องกันได้อย่างไร

เราใช้งานPexมากับโค้ดบางตัวและมันก็แสดงให้เห็นถึงสิ่งที่ดี (สิ่งเลวร้าย แต่แสดงให้พวกเขาเห็นก่อนที่มันจะเริ่มผลิต!)

อย่างไรก็ตามหนึ่งในสิ่งที่ดีเกี่ยวกับ Pex คือมันไม่จำเป็นต้องหยุดพยายามค้นหาปัญหา

สิ่งหนึ่งที่เราพบคือเมื่อผ่านสตริงเราไม่ได้ตรวจสอบสตริงว่าง

ดังนั้นเราจึงเปลี่ยน:

if (inputString == null)

ถึง

if (string.IsNullOrEmpty(inputString)) // ***

ที่แก้ไขปัญหาเบื้องต้น แต่เมื่อเราวิ่ง Pex อีกครั้งก็ตัดสินใจว่า

inputString = "\0";

ก่อให้เกิดปัญหา และจากนั้น

inputString = "\u0001";

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

เพียงพอหรือไม่

คำถามสามข้อควรช่วยคุณพิจารณาว่าจะป้องกันอย่างไรในการเข้ารหัสของคุณ

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

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

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

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

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

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

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

ฉันจะป้องกันอย่างที่คุณต้องการ ค่อนข้างคลุมเครือฉันเดา แต่ฉันจะพยายามอธิบาย

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

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

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

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

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

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

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

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

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

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

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