ฉันได้รับบทบาทเพื่อปรับปรุงการพัฒนาใน บริษัท ของเรา สิ่งแรกที่ฉันต้องการเริ่มต้นคือการตรวจสอบโค้ดเนื่องจากไม่เคยทำที่นี่มาก่อน

บริษัท ของเรามีโปรแกรมเมอร์ 3 คน ฉันเป็นโปรแกรมเมอร์เว็บภาษาที่ฉันรู้จักส่วนใหญ่เป็น PHP, ActionScript และ JavaScript นักพัฒนาอีก 2 คนเขียนแอปพลิเคชันภายในใน VB.net

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

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

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

นี่อาจเป็นจริง แต่ไม่รู้ภาษาฉันไม่แน่ใจว่าจะยืนยันหรือปฏิเสธข้อเรียกร้องเหล่านี้ได้อย่างไร

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

ความคิดที่มาหาฉันก็คือพวกเขาทั้งสองมีความสนใจใน C # และอื่น ๆ ฉันมันเกี่ยวข้องกับพวกเขาเพราะ. net และเมื่อเทียบกับฉันเพราะมันคล้ายกับภาษาที่ฉันรู้ แต่มันเป็นเรื่องใหม่สำหรับเราทุกคน ฉันคิดเกี่ยวกับประโยชน์ของพวกเราทุกคนที่ทำงานร่วมกันในโครงการสัตว์เลี้ยง C # .net และทบทวนโค้ดของกันและกัน

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

คุณอยากแนะนำอะไรให้ฉันทำในสถานการณ์นี้

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

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

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

เพื่อนเคยอธิบายสิ่งนี้ว่า "ทฤษฎีภารโรง": โดยการอธิบายรายละเอียดกับใครบางคนแม้กระทั่งภารโรงโปรแกรมเมอร์จะเปิดเผยจุดอ่อนใด ๆ ในรหัสของเขา / เธอซึ่งแน่นอนว่าเป้าหมายสูงสุดของการทบทวน กระบวนการ. แม้ว่าจะต้องมีการอธิบายรหัสอย่างละเอียดและเปิดเผย (ความเห็นจะไม่ทำงานเมื่อนักพัฒนามีการป้องกัน)

รุ่นสั้น ๆ

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

รุ่นที่ยาวขึ้น

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

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

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

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

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

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

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

นำการพัฒนาใหม่ไปใช้ภาษาที่ไม่มีใครเข้าใจ (C #) จะต้องใช้เวลานานในการชำระโดยเฉพาะอย่างยิ่งถ้าคุณทุกคนนำนิสัยที่ไม่ดีของพวกเขามาด้วย

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

คุณสามารถพิสูจน์อ่าน 'สิ่งที่คุณไม่ทราบจริงๆ แต่คุณไม่สามารถเพียงพอตรวจสอบมัน ฉันมีความสามารถสูงใน C รู้ C ++ ค่อนข้างดี แต่ฉันจะไม่ฝันที่จะทบทวนบางสิ่งใน C #

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

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

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

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

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

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

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

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

ข่าวดีคือเมื่อคุณทำสิ่งนี้แล้วสิ่งที่คุณได้เรียนรู้บางอย่างจะยังคงมีประโยชน์เมื่อคุณไปยัง C #

ความคิดที่คุณควรเก็บไว้ตลอดเวลาเมื่อทำการตรวจสอบโดยเพื่อนคือ:

"ฉันเป็นคนต่อไปเพื่อรักษารหัสนี้!"

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

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

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

สิ่งที่คุณสามารถเลือก / กำหนดแนวทางการเข้ารหัสและตรวจสอบรหัสกับแนวทางเหล่านี้ เมื่อบางสิ่งไม่สอดคล้องกับหลักเกณฑ์คุณสามารถขอคำอธิบายจากนักพัฒนาซอฟต์แวร์ได้

ฉันจะเริ่มต้นด้วยการเลือกแนวทางที่มีอยู่ (ฉันไม่รู้มาตรฐานการเข้ารหัสของ VB.net แต่ google ให้ฉัน:

• แนวทางการเข้ารหัส VB. Net
• Submain
• ทั้งหมดในหนึ่งรหัสกรอบ

ใช้stylecop เช่นเครื่องมือสำหรับ VB. net

วิเคราะห์แหล่งที่มาด้วยNDepend (มีกฎเกณฑ์เกี่ยวกับความซับซ้อนของวงจร, ความยาว, ความลึก ฯลฯ )

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

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

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

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

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

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

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

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

สมมติว่าคุณไม่ทราบว่าฟังก์ชั่นอินพุต () ใน Python 2 ประเมินค่าอินพุตจริงก่อนที่จะส่งคืนเพื่อให้ง่ายต่อการแยกวิเคราะห์ชนิดอินพุตที่ไม่ใช่สตริง จากนั้นโค้ดจะมีความเสี่ยงที่จะ Arbitrary Code Execution ทำให้ผู้ใช้สามารถป้อนสิ่งที่ต้องการ__import__('os').execl('/bin/sh', '/bin/sh')บนระบบ Linux เพื่อเปลี่ยนกระบวนการ Python ให้เป็นเชลล์ raw_input () ควรถูกใช้แทนเพื่อรับข้อมูลอินพุตที่ไม่ได้ประมวลผล

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