เปลี่ยน AI ให้เป็นผู้รีวิวที่เข้มงวดเรื่องความอ่านง่าย บั๊ก และความปลอดภัย และลับวิจารณญาณของคุณให้คมด้วยการปกป้องทางเลือกของตัวเองต่อคำวิจารณ์ของมัน
เปิดบทเรียนนี้ใน Kodokonการรีวิวโค้ดโดยเพื่อนร่วมงานเป็นหนึ่งในตัวเร่งการเติบโตในสายงานนี้ที่มีเอกสารรองรับมากที่สุด และเป็นหนึ่งในสิ่งที่เข้าถึงยากที่สุดเมื่อคุณทำงานคนเดียว AI มอบผู้รีวิวที่พร้อมตลอด 24 ชั่วโมง โดยมีเงื่อนไขเดียว: คุณต้องตั้งค่ามัน โดยปริยายแล้วโมเดลจะเอาใจ: มันชมความพยายามของคุณ ชี้เรื่องหยุมหยิมสองสามอย่าง แล้วสรุปว่า "โดยรวมแล้วงานนี้ดี" นั่นไม่ใช่การรีวิว แต่คือการตบไหล่ให้กำลังใจ ความผิดพลาดในทางกลับกันคือการขอ "เขียนโค้ดของฉันใหม่ให้สะอาด": คุณจะได้โค้ดที่ไม่เคยคิดตามด้วยเหตุผล และไม่ได้เรียนรู้อะไรเลย แนวทางที่ถูกต้อง: เรียกร้องคำวิจารณ์ที่มีโครงสร้าง ทั้งความอ่านง่าย บั๊ก และความปลอดภัย พร้อมระดับความรุนแรงที่ปรับเทียบมาดีและมีเหตุผลกำกับ
คุณคือผู้รีวิวระดับซีเนียร์ที่เข้มงวด เหมือนในการรีวิวโค้ดของทีม เป้าหมายของคุณคือทำให้ผมพัฒนาขึ้น ไม่ใช่ปล่อยผมไว้แบบผ่อนปรน
นี่คือโค้ดของผม ([ภาษา], บริบท: [มันใช้ทำอะไร, ข้อจำกัดของโปรเจกต์]):
[วางโค้ด]
วิเคราะห์มันตามสามแกน:
1. ความอ่านง่าย: การตั้งชื่อ, โครงสร้าง, ความซับซ้อนที่ไม่จำเป็น, เจตนาที่ไม่ชัดเจน
2. บั๊ก: กรณีขอบที่ไม่ได้จัดการ, ข้อผิดพลาดที่เงียบไป, สถานะที่ไม่สอดคล้อง, การทำงานพร้อมกัน
3. ความปลอดภัย: อินพุตที่ไม่ได้ตรวจสอบ, การฉีดคำสั่ง, ข้อมูลอ่อนไหวที่เปิดเผย, สิทธิ์การเข้าถึง
รูปแบบผลลัพธ์: สำหรับแต่ละข้อสังเกต ให้ระบุ บรรทัดหรือบล็อกที่เกี่ยวข้อง, แกน, ระดับความรุนแรง (ต้องแก้ก่อน / สำคัญ / เล็กน้อย) และเหตุผลว่าทำไมในหนึ่งหรือสองประโยค
ข้อจำกัด: อย่าเขียนโค้ดของผมใหม่ ให้ข้อสังเกตได้มากที่สุด 8 ข้อ เรียงร้ายแรงที่สุดขึ้นก่อน ถ้าทางเลือกที่ถกเถียงได้สามารถอธิบายได้ตามบริบท ให้บอกอย่างชัดเจนแทนที่จะนับมันเป็นข้อบกพร่องสังเกตเพดานที่ 8 ข้อสังเกตเรียงตามความรุนแรง: หากไม่มีมัน คุณจะได้เรื่องจับผิด 25 ข้อ ที่การขาดการตรวจสอบอินพุตมีน้ำหนักเท่ากับความชอบส่วนตัวเรื่องการตั้งชื่อ สังเกตข้อกำหนดเรื่องทางเลือกที่ปกป้องได้ด้วย: มันบังคับให้โมเดลแยกแยะข้อบกพร่องที่เป็นภววิสัยออกจากธรรมเนียมที่ถกเถียงได้ จากนั้นก็มาถึงส่วนที่สร้างพัฒนาการมากที่สุด ส่วนที่แทบทุกคนข้ามไป: การปกป้องทางเลือกของคุณ การรีวิวไม่ใช่คำตัดสินที่ต้องนำไปปฏิบัติ แต่คือบทสนทนา เมื่อข้อสังเกตดูไม่สมเหตุสมผล ให้โต้กลับ ไม่เหตุผลของคุณก็หนักแน่นและในที่สุดคุณก็ได้สะกดมันออกมา หรือมันก็พังทลายและคุณค้นพบว่า "ทางเลือก" นี้เป็นเพียงความเคยชิน
เรากลับมาที่ข้อสังเกตหมายเลข [X] ของคุณ: คุณเห็นว่า [ทวนข้อสังเกตนั้นอีกครั้ง].
ผมไม่เห็นด้วย และนี่คือเหตุผลของผม: [ข้อโต้แย้งของคุณ - ข้อจำกัดด้านประสิทธิภาพที่วัดผลมาแล้ว, ความสอดคล้องกับโค้ดส่วนที่เหลือ, ความเรียบง่ายที่ตั้งใจ, กำหนดส่งงาน...].
1. ประเมินข้อโต้แย้งแต่ละข้อของผมอย่างตรงไปตรงมา: ข้อไหนหนักแน่น ข้อไหนเป็นแค่การหาเหตุผลเข้าข้างตัวเอง?
2. ให้ข้อโต้แย้งฝ่ายตรงข้ามที่หนักแน่นที่สุดต่อจุดยืนของผม อย่างเพื่อนร่วมงานผู้ช่ำชองที่ไม่เห็นด้วยจะพูด
3. สรุป: ในบริบทเฉพาะของผม การเปลี่ยนแปลงนี้คุ้มค่ากับต้นทุนของมันไหม? ตอบใช่หรือไม่ แล้วให้เหตุผลไม่เกินสามประโยค
อย่าพยายามเข้าข้างผม: ถ้าข้อโต้แย้งของผมอ่อน ก็บอกมาตรง ๆกับดักคลาสสิกสองอย่างของการรีวิวด้วย AI กับดักแรก: สัญญาณเตือนลวงที่ส่งมาด้วยความมั่นใจ โมเดลชี้ race condition ที่เป็นไปไม่ได้ในสถาปัตยกรรมของคุณ หรือ "บั๊ก" ที่ไม่ใช่บั๊กในภาษาเวอร์ชันของคุณ จงปฏิบัติต่อทุกข้อสังเกตเสมือนมาจากเพื่อนร่วมงานที่ปราดเปรื่องแต่ไม่มีสิทธิ์เข้าถึงบริบททั้งหมด: น่าเชื่อถือ แต่ต้องพิสูจน์ กับดักที่สอง: ละครความปลอดภัย AI เก่งมากในการจับรูปแบบคลาสสิก (SQL injection, XSS, ความลับที่เก็บเป็นข้อความธรรมดา) แต่พลาดข้อบกพร่องเชิงตรรกะทางธุรกิจ เช่นการขาดการตรวจสอบสิทธิ์บนเส้นทางหนึ่ง หรือสถานะกลางคันที่ถูกโจมตีได้ การรีวิวด้วย AI เป็นส่วนเสริม มันไม่ได้แทนที่ทั้งการตรวจสอบและความรู้เชิงโดเมนของคุณ