ทำไมการละเมิดไกด์สไตล์แพร่กระจายได้เร็ว\n\nการละเมิดไกด์สไตล์แทบจะไม่เกิดขึ้นเป็นความผิดพลาดครั้งใหญ่ครั้งเดียว แต่มันเริ่มจากการเลือกเล็ก ๆ ที่ดูว่า "พอใช้ได้" ใน pull request แล้วสะสมจนโค้ดเบสดูไม่สม่ำเสมอและยากต่อการอ่าน\n\nการเบี่ยงเบนสไตล์มักจะเป็นแบบนี้: ไฟล์หนึ่งใช้ ไฟล์ถัดมาระบุ และอีกไฟล์ใช้ ตัวจัดการหนึ่งคืนค่า อีกตัวโยนข้อผิดพลาด อีกตัวล็อกแล้วคืน การเปลี่ยนแต่ละครั้งเล็ก ๆ แต่รวมกันแล้วทำให้รูปแบบในรีโปไม่คาดเดาได้\n\nการทำงานอย่างรวดเร็วและหลายคนร่วมงานทำให้แย่ลง ผู้คนมักคัดลอกสิ่งที่เห็น โดยเฉพาะเมื่อมีความกดดันด้านเวลา ถ้าชิ้นโค้ดล่าสุดในรีโปใช้ทางลัด ทางลัดนั้นมักกลายเป็นต้นแบบสำหรับการเปลี่ยนแปลงต่อไป ภายในไม่กี่สัปดาห์ "สไตล์เริ่มต้น" อาจไม่ใช่ไกด์ที่เขียนไว้ แต่เป็นสิ่งที่เกิดขึ้นล่าสุด\n\nนั่นคือเหตุผลที่เป้าหมายควรเป็นการมีคอนเวนชันที่สม่ำเสมอ ไม่ใช่รสนิยมส่วนบุคคล คำถามไม่ใช่ "ฉันชอบชื่อนี้ไหม?" แต่เป็น "นี่ตรงตามกฎที่ตกลงกันไว้หรือไม่ เพื่อให้คนถัดไปทำตามได้โดยไม่ต้องคิดมาก"\n\nการจับการละเมิดตั้งแต่เนิ่น ๆ คือการหยุดรูปแบบไม่ดีไว้ก่อนที่จะกลายเป็นเชื้อคัดลอก ให้โฟกัสที่โค้ดใหม่และที่แก้ไข แก้จุดแรกที่มีความไม่สอดคล้องใหม่ และบล็อกการรวมโค้ดที่นำมาซึ่งการเบี่ยงเบนใหม่ เมื่อรายงานปัญหา ให้เพิ่มตัวอย่างสั้น ๆ ที่แนะนำเพื่อให้คนอื่นทำตามครั้งหน้าได้ง่าย\n\nตัวอย่างสมจริง: นักพัฒนาคนหนึ่งเพิ่ม endpoint ใหม่ของ API แล้วล็อก request body ตรง ๆ "แค่เพื่อดีบัก" ถ้าสิ่งนั้นเข้ามา endpoint ถัด ๆ ไปก็จะคัดลอก และในไม่ช้าข้อมูลที่ละเอียดอ่อนก็จะไปปรากฏในล็อก การจับมันใน PR แรกถูกและง่าย การแก้หลังจากมันแพร่กระจายแล้วทั้งเจ็บปวดและมีความเสี่ยง\n\n## เปลี่ยนไกด์สไตล์ให้เป็นกฎที่ชัดเจนและทดสอบได้\n\nไกด์สไตล์จะใช้ได้ในการรีวิวก็ต่อเมื่อมันอ่านเหมือนเช็คลิสต์ ไม่ใช่ชุดความชอบ ปรับแต่ละคำแนะนำให้เป็นกฎที่ตรวจสอบได้บน diff\n\nจัดระเบียบกฎเป็นสี่หมวดให้ชัดเจน: การตั้งชื่อ (naming), เลเยอร์ (layering), การจัดการข้อผิดพลาด (error handling), และการล็อก (logging) สำหรับแต่ละหมวด เขียนสองสิ่ง: สิ่งที่ต้องเป็นจริง และสิ่งที่ห้ามทำ\n\nกำหนดความเข้มของแต่ละกฎล่วงหน้า:\n\n- : หากไม่ผ่านจะบล็อกการเปลี่ยนแปลง\n- : ควรแก้ถ้าไม่มีเหตุผลชัดเจนที่จะไม่แก้\n- : ดีแต่ไม่บล็อก\n\nตั้งขอบเขตเพื่อให้การรีวิวไม่กลายเป็นการรีแฟกเตอร์ไม่รู้จบ กฎง่าย ๆ ที่ใช้ได้ดีคือ: "โค้ดใหม่และที่แก้ไขต้องสอดคล้อง; โค้ดเก่าที่ไม่ได้แตะไม่ต้องถูกเขียนใหม่ เว้นแต่จะขัดขวางการแก้" ถ้าต้องการทำความสะอาด ให้ตั้งเวลาเป็นงานแยก\n\nนอกจากนี้ให้กำหนดผลลัพธ์ที่ต้องการจากการรีวิวเพื่อให้ทำตามได้ง่าย: ผลผ่าน/ล้ม, รายการการละเมิดพร้อมไฟล์และบรรทัดอ้างอิง, การแก้แนะนำในรูปแบบแก้ไขที่เป็นรูปธรรม, และบันทึกความเสี่ยงสั้น ๆ เมื่อบางอย่างอาจก่อให้เกิดบั๊กหรือการรั่วไหล\n\nตัวอย่าง: ถ้า PR ล็อก token ผู้ใช้ดิบ การรีวิวควรล้มภายใต้ "logging: never log secrets" และแนะนำให้ล็อกเฉพาะ request ID แทน\n\n## โครงสร้างพรอมต์ที่บังคับใช้กฎมากกว่ารสนิยม\n\nพรอมต์ไกด์สไตล์มักล้มเหลวเมื่อมันฟังดูเป็นความชอบส่วนตัว พรอมต์รีวิวที่ดีต้องอ่านเหมือนสัญญา: ข้อห้ามที่ชัดเจน ข้อยกเว้นที่ตั้งชื่อชัด และผลลัพธ์ที่คาดเดาได้\n\nเริ่มด้วยสองบล็อกสั้น ๆ: สิ่งที่ต้องเป็นจริง และสิ่งที่สามารถยืดหยุ่นได้ จากนั้นเพิ่มกฎการตัดสิน: "ถ้าไม่ชัด ให้ระบุ Needs Clarification อย่าสันนิษฐาน"\n\nบังคับให้มีหลักฐาน เมื่อเครื่องมือตรวจพบการละเมิด ให้บังคับให้มันอ้างข้อความ identifier และตำแหน่งไฟล์เป๊ะ ๆ แทนคำบรรยายคลุมเครือ ข้อจำกัดเดียวนั้นช่วยลดการโต้ตอบซ้ำ ๆ ได้มาก\n\nเก็บขอบเขตให้แคบ: แสดงความคิดเห็นเฉพาะบรรทัดที่เปลี่ยนและเส้นทางโค้ดที่ได้รับผลกระทบโดยตรงเท่านั้น หากอนุญาตให้รีแฟกเตอร์ที่ไม่เกี่ยวข้อง การบังคับใช้สไตล์จะกลายเป็นการ "เขียนไฟล์ใหม่" และผู้คนจะหยุดเชื่อถือคำติชม\n\nนี่คือโครงสร้างที่ใช้ซ้ำได้:\n\n\n\nบังคับให้รายงานมีส่วนเดิมทุกครั้ง แม้บางส่วนจะขึ้นว่า "ไม่พบปัญหา": Naming, Layering, Error handling, Logging\n\nถ้ารายงานระบุว่า "service layer leaking DB details" มันต้องอ้างอิงบางอย่างเช่น และการเรียกที่ชี้ชัด (ตัวอย่าง ) เพื่อให้คุณแก้ปัญหาโดยไม่ต้องถกเถียงกันว่ามันหมายถึงอะไร\n\n## ขั้นตอนทีละขั้น: สร้างเวิร์กโฟลว์พรอมต์เช็กสไตล์\n\nไกด์สไตล์จะติดเมื่อกระบวนการทำซ้ำได้ เป้าหมายคือให้โมเดลเช็กกฎ ไม่ใช่โต้เถียงเรื่องรสนิยม และให้ทำในแบบเดียวกันทุกครั้ง\n\nใช้เวิร์กโฟลว์สองพาสเรียบง่าย:\n\n1) วางมาตรฐานของคุณเป็นรายการกฎแบบตัวเลขสั้น ๆ (10-25 บรรทัด) ให้แต่ละกฎตรวจสอบได้\n2) เพิ่มบริบทสำหรับการเปลี่ยนแปลง: diff, ไฟล์ที่แตะ และประโยคสั้น ๆ เกี่ยวกับเจตนา\n3) ขอรายงานการละเมิดก่อน ให้มีไฟล์และบรรทัด สาเหตุสั้น ๆ และหมายเลขกฎที่ตรงกัน\n4) เฉพาะหลังรายงานแล้ว ให้ขอแพตช์ที่เล็กที่สุดเพื่อให้เป็นไปตามกฎ\n5) รันพรอมต์เดิมอีกครั้งบนโค้ดที่อัปเดตเพื่อยืนยันว่าไม่มีเหลือ\n\nตัวอย่าง: PR เพิ่ม endpoint ใหม่ Pass 1 จะชี้ว่า handler พูดคุยกับ PostgreSQL โดยตรง (layering), ใช้การตั้งชื่อผสมใน struct ของ request (naming), และล็อกอีเมลเต็มรูปแบบ (logging). Pass 2 แก้ไขเล็กน้อย: ย้ายการเรียก DB ไปยัง service หรือ repository, เปลี่ยนชื่อ struct, และปกปิดอีเมลในล็อก โดยไม่เปลี่ยนอย่างอื่น\n\n## การตั้งชื่อ: พรอมต์ที่จับสิ่งเล็ก ๆ\n\nปัญหาการตั้งชื่อดูเหมือนเล็ก แต่สร้างต้นทุนจริง: คนอ่านความหมายผิด การค้นหาซับซ้อน และชื่อคล้ายกันจำนวนมากเพิ่มขึ้น\n\nระบุให้ชัดเจนกฎการตั้งชื่อที่รีวิวเวอร์ต้องบังคับใช้ทั่วทั้งการเปลี่ยน: ชื่อไฟล์, types ที่ export, ฟังก์ชัน, ตัวแปร, คอนสแตนต์, และเทสต์ ระบุชัดเรื่องการใช้เคส (camelCase, PascalCase, snake_case) และเลือกกฎคำย่อหนึ่งแบบ (เช่น vs ) แล้วบังคับใช้ทุกที่\n\nมาตรฐานคำศัพท์ร่วมกันก็สำคัญ: ประเภทข้อผิดพลาด, ฟิลด์ล็อก, และคีย์คอนฟิก ถ้าล็อกใช้ ไม่ควรยอม ในไฟล์หนึ่งและ ในอีกไฟล์\n\nคำสั่งสำหรับรีวิวที่ใช้งานได้จริง:\n\n\n\nขอรายงานสั้น ๆ: สามชื่ิอที่ทำให้สับสนที่สุด, รายชื่อ near-duplicates และตัวที่ควรเก็บไว้, รวมถึงชื่อฟิลด์ล็อก/คอนฟิก/ข้อผิดพลาดที่ไม่ตรงกับมาตรฐาน\n\n## กฎเลเยอร์: แยกความรับผิดชอบไม่ให้ปะปน\n\nกฎเลเยอร์ทำงานได้ดีที่สุดเมื่ออธิบายเป็นภาษาธรรมดา: handler ดูแล HTTP, service ถือ business rules, repository ติดต่อฐานข้อมูล\n\nล็อกทิศทางการพึ่งพา Handler สามารถเรียก service ได้ Service สามารถเรียก repository ได้ Repository ไม่ควรเรียก service หรือ handler Handler ไม่ควร import โค้ดฐานข้อมูล helpers SQL หรือโมเดล ORM ถ้าใช้แพ็กเกจร่วม (config, time, IDs) ให้แน่ใจว่าไม่มีโลจิกของแอปอยู่ในนั้น\n\nกำหนดที่อยู่ของงานข้ามเลเยอร์ การ validate มักอยู่ที่ boundary สำหรับรูปร่าง request และใน service สำหรับกฎธุรกิจ การอนุญาตมักเริ่มใน handler (identity, scopes) แต่ service ควรบังคับการตัดสินขั้นสุดท้าย การ mapping อยู่ที่ขอบของเลเยอร์: handler แปลง HTTP เป็น domain input, repository แปลง DB rows เป็น domain types\n\nใส่บล็อกนี้ในพรอมต์เพื่อให้รีวิวเป็นรูปธรรม:\n\n\n\nทำให้รายงานชัดเจน: ระบุไฟล์ เลเยอร์ที่ควรอยู่ การ import หรือการเรียกที่ละเมิดกฎ และการเปลี่ยนแปลงเล็กที่สุดที่ป้องกันไม่ให้รูปแบบนั้นแพร่กระจาย\n\n## ข้อตกลงการจัดการข้อผิดพลาด: สม่ำเสมอเมื่อเกิดความกดดัน\n\nการถกเถียงเรื่องสไตล์มักจะดังเมื่อบางอย่างล้มในโปรดักชัน นโยบายชัดเจนเรื่องการจัดการข้อผิดพลาดช่วยให้การแก้ปัญหาเป็นไปอย่างสงบเพราะทุกคนรู้ว่า "ดี" เป็นอย่างไร\n\nเขียนปรัชญาและบังคับใช้ ตัวอย่าง: "wrap errors เพื่อเพิ่มบริบท; สร้าง error ใหม่เมื่อเปลี่ยนความหมายหรือแปลเป็นข้อความผู้ใช้; คืน raw error เฉพาะที่ขอบระบบ" ประโยคเดียวจะป้องกันรูปแบบสุ่ม ๆ จากการแพร่\n\nแยกข้อความที่แสดงกับผู้ใช้จากรายละเอียดภายใน ข้อความผู้ใช้ควรกระชับและปลอดภัย ข้อผิดพลาดภายในอาจมีชื่อการดำเนินการและตัวระบุหลัก แต่ไม่ควรมีความลับ\n\nในการรีวิว ให้เช็กความล้มเหลวที่พบบ่อย: ข้อผิดพลาดถูกละเลย (ล็อกแต่ไม่คืนค่า), คืนค่ากำกวม (ค่ากลับเป็น nil พร้อม error เป็น nil หลังจากล้มเหลว), และข้อความผู้ใช้ที่รั่วข้อมูลเช่น stack trace, คำสั่ง query, token หรือ PII ถ้ารองรับการ retry หรือ timeout ให้บังคับให้ระบุไว้ชัดเจน\n\nตัวอย่าง: การเรียก checkout เวลา timeout ผู้ใช้เห็น "Payment service is taking too long." ภายในให้ wrap timeout และใส่ และ order ID เพื่อให้ค้นหาได้และแก้ไขได้\n\n## ข้อตกลงการล็อก: อ่านได้ ค้นหาได้ และปลอดภัย\n\nล็อกช่วยได้เมื่อทุกคนเขียนแบบเดียวกัน ถ้าผู้พัฒนาแต่ละคนเลือกคำพูด ระดับ และฟิลด์เอง การค้นหาจะกลายเป็นการคาดเดา\n\nทำให้ระดับล็อกเป็นสิ่งที่ไม่ต่อรองได้: debug สำหรับรายละเอียดการพัฒนา, info สำหรับเหตุการณ์ปกติ, warn สำหรับสถานการณ์ที่คาดไม่ถึงแต่จัดการได้, และ error เมื่อการกระทำต่อผู้ใช้ล้มเหลวหรือจำเป็นต้องให้ความสนใจ ระวังการใช้ fatal หรือ panic ให้ชัดเจนตามนโยบายการล่ม\n\nล็อกแบบมีโครงสร้างสำคัญกว่าประโยคที่สมบูรณ์แบบ กำหนดชื่อคีย์ที่คงที่เพื่อไม่ให้แดชบอร์ดและ alerts พัง เลือกชุดคีย์แกนเล็ก ๆ (เช่น event, component, action, status, duration_ms) และรักษาให้สม่ำเสมอ\n\nจัดการข้อมูลละเอียดอ่อนเป็นข้อห้ามชัดเจน ระบุชัดเจนสิ่งที่ห้ามล็อกเด็ดขาด: รหัสผ่าน, auth tokens, หมายเลขบัตรเครดิตเต็ม, ความลับ, และข้อมูลส่วนบุคคลดิบ เรียกสิ่งที่ดูไม่อันตรายแต่จริง ๆ แล้วอันตราย เช่น ลิงก์รีเซ็ตรหัสผ่าน, session IDs, และ request bodies เต็ม ๆ ว่าเป็นความเสี่ยง\n\nCorrelation IDs ทำให้การดีบักข้ามเลเยอร์เป็นไปได้ บังคับให้มี ในทุกบรรทัดล็อกที่อยู่ภายในการร้องขอ ถ้าล็อก ให้กำหนดว่าเมื่อใดอนุญาตและจะแสดงผู้ใช้ที่ไม่ได้ระบุอย่างไร\n\nบล็อกพรอมต์ที่ใช้ซ้ำได้:\n\n\n\nก่อนจะ merge ให้ทำ "safety pass" อย่างรวดเร็ว: ล็อกใหม่ที่ขาด สำหรับงานที่ผูกกับ request, คีย์ใหม่ที่เปลี่ยนชื่อเดิม ( vs ), error logs ที่ขาดข้อมูลว่าล้มที่ไหน (operation, resource, status), ล็อกความถี่สูงที่จะเกิดทุก request, และความเป็นไปได้ที่จะมีความลับหรือข้อมูลส่วนบุคคลปรากฏในฟิลด์หรือข้อความ\n\n## วิธีจับการละเมิดก่อนที่มันจะแพร่\n\nมองการเบี่ยงเบนสไตล์เหมือนการแตกของ build ไม่ใช่คำแนะนำ เพิ่มเกทที่เข้มงวดก่อน merge และให้ผลผ่านหรือไม่ผ่านชัดเจน หากกฎบังคับถูกละเมิด (การตั้งชื่อ, ขอบเขตเลเยอร์, ความปลอดภัยล็อก, การจัดการข้อผิดพลาด) ให้ล้มและชี้ไฟล์บรรทัดที่แน่นอน\n\nรักษาเกทให้สั้น เทคนิคปฏิบัติได้คือให้มีเช็คลิสต์ YES/NO ต่อตัว และปฏิเสธการอนุมัติถ้ารายการใดเป็น NO\n\nเช็คลิสต์ขนาด PR ที่จับปัญหาส่วนใหญ่:\n\n- Naming: ตรงตามรูปแบบที่อนุมัติสำหรับไฟล์ types และฟังก์ชัน\n- Layering: ไม่มีการเรียกข้ามเลเยอร์โดยตรง (เช่น handler เรียก DB)\n- Errors: คืนค่าอย่างสม่ำเสมอพร้อมบริบท ไม่มีการละเลยเงียบ ๆ\n- Logging: ฟิลด์สม่ำเสมอ ไม่มีความลับ และระดับตรงกับผลกระทบ\n- Tests/docs: อัปเดตเมื่อพฤติกรรมหรือ API สาธารณะเปลี่ยน\n\nเมื่อเครื่องมือเสนอการแก้ไข ให้บังคับให้มีสั้น ๆ ที่เป็นโค้ดที่ปฏิบัติตามสำหรับแต่ละกฎที่แตะ เพื่อป้องกันคำติชมคลุมเครือเช่น "เปลี่ยนชื่อเพื่อความชัดเจน"\n\n## กับดักทั่วไปเมื่อใช้พรอมต์ในการบังคับสไตล์\n\nวิธีที่เร็วที่สุดที่ไกด์สไตล์จะล้มคือการทิ้งช่องให้ตีความได้ ถ้าผู้ตรวจสองคนอ่านกฎเดียวกันแล้วได้ข้อสรุปต่างกัน เครื่องมือจะบังคับใช้รสนิยมไม่ใช่มาตรฐาน\n\nการตั้งชื่อเป็นตัวอย่างทั่วไป "ใช้ชื่อที่ชัดเจน" ตรวจสอบไม่ได้ ทำให้มันเข้มงวดเป็นสิ่งที่ตรวจสอบได้: "ฟังก์ชันเป็นกริยา (เช่น ), boolean เริ่มด้วย , types ที่ export เป็น "\n\nกับดักอีกอย่างคือขอทุกอย่างพร้อมกัน เมื่อพรอมต์พยายามครอบคลุม naming, layering, errors, logging, tests และ performance ในครั้งเดียว คำติชมจะตื้น แยกรีวิวเป็นพาสที่โฟกัสเมื่ออยากได้ความลึก หรือลดเกทให้เหลือกฎบังคับเท่านั้น\n\nปัญหาที่ทำให้การบังคับใช้แตกหักบ่อยที่สุด:\n\n- : แทนที่จะใช้คำว่า "สะอาด" และ "สม่ำเสมอ" ให้ใช้ภาษาที่วัดได้\n- : อย่าให้พรอมต์สไตล์เสนอสถาปัตยกรรมใหม่\n- : บังคับให้ทุกความคิดเห็นต้องอ้าง identifier หรือ snippet เป๊ะ ๆ\n- : ถ้าอนุญาตข้อยกเว้น ให้บันทึกสั้น ๆ ว่าทำไม และเมื่อไหร่ควรถอนออก\n\nถ้าปฏิบัติต่อพรอมต์เหมือนการทดสอบ คุณจะได้การบังคับใช้ที่คาดเดาได้ ถ้าปฏิบัติต่อมันเหมือนคำแนะนำ การละเมิดจะซ่อนตัวและทวีคูณ\n\n## เช็คลิสต์ด่วนที่คุณรันกับทุกการเปลี่ยนแปลง\n\nรันพาสด่วนบน diff (ไม่ใช่ทั้งรีโป) และยืนยัน:\n\n- ตัวระบุใหม่ตามแพทเทิร์นของคุณ (เคส, prefixes, suffixes) แนวคิดเดียวต้องมีชื่อเดียวข้ามไฟล์\n- การพึ่งพาไปในทิศทางที่อนุญาตเท่านั้น เลเยอร์ล่างไม่ import เลเยอร์บน\n- คืนค่าความล้มเหลวพร้อมบริบท ไม่มีการละเลยเงียบ\n- ระดับถูกต้อง ฟิลด์คงที่ และไม่มีความลับหรือข้อมูลส่วนบุคคล\n- ผู้ตรวจระบุชัด: “no mandatory violations found” หรือระบุการละเมิดที่ต้องแก้ก่อน merge\n\nเก็บพรอมต์เทมเพลตสั้น ๆ และวางมันกับแต่ละการเปลี่ยนแปลง:\n\n\n\nตัวอย่าง: ฟังก์ชันใหม่ ใน handler ที่เขียนไปยัง PostgreSQL โดยตรง ควรล้มทั้ง naming และ layering แม้ว่าฟีเจอร์จะทำงานได้ การจับมันตั้งแต่ตรงนี้จะป้องกันการคัดลอก-วางแพร่ปัญหา\n\n## ตัวอย่าง: รีวิวสมจริงที่แก้ปัญหาได้ตั้งแต่ต้น\n\nเพื่อนร่วมทีมเพิ่ม endpoint ใหม่: มันแตะ handler, service, และ storage\n\nในพาสแรก คุณต้องการรายงาน ไม่ใช่การเขียนใหม่:\n\n\n\nผลลัพธ์ทั่วไป: vs การตั้งชื่อไม่ตรงกัน, handler เรียก โดยตรง, คืนค่า raw โดยไม่มีบริบท, และล็อกที่ดังเกินไปเช่น ที่ dump วัตถุเต็ม\n\nพาสที่สองขอการแก้ไขที่เล็กและปลอดภัย:\n\n\n\nถ้าการละเมิดกฎได้รับอนุญาต ให้บอกตั้งแต่ต้น: "Exceptions are permitted only if you add a short comment explaining why, and you add a follow-up task to remove the exception."\n\nหลังการแก้ handler จะกลายเป็น adapter บาง ๆ, service ดูแล workflow, storage ดูแล query, ข้อผิดพลาดกลายเป็น และล็อกเป็นบรรทัดเดียวสะอาดพร้อมฟิลด์ที่ปลอดภัย (invoice ID ไม่ใช่ invoice ทั้งหมด)\n\n## ขั้นตอนถัดไป: ทำให้เป็นกิจวัตรโดยไม่ทำให้ช้าลง\n\nเลือกพรอมต์เดียวที่ทีมอนุมัติและปฏิบัติต่อมันเหมือนเครื่องมือร่วม เริ่มจากสิ่งที่ทำให้คุณเจ็บบ่อยที่สุดในการรีวิว (การเบี่ยงชื่อ, เลเยอร์รั่ว, ข้อผิดพลาดไม่สม่ำเสมอ, ล็อกไม่ปลอดภัย) อัปเดตพรอมต์เมื่อเห็นการละเมิดจริงในโค้ดจริงเท่านั้น\n\nเก็บบล็อกกฎขนาดเล็กไว้บนสุดของพรอมต์และวางมันในทุกรีวิวโดยไม่เปลี่ยน ถ้าทุกคนแก้กฎทุกครั้ง คุณจะไม่มีมาตรฐาน แต่อยู่ในเวทีถกเถียง\n\nจังหวะง่าย ๆ ช่วยได้: ให้คนหนึ่งเก็บรายการการละเมิดยอดนิยมของสัปดาห์ และเพิ่มเพียงหนึ่งกฎที่ชัดเจนขึ้นหรือหนึ่งตัวอย่างที่ดีกว่า\n\nถ้าคุณทำงานใน flow การสร้างด้วยแชทอย่าง Koder.ai (koder.ai) ควรรันการเช็กเกทเดียวกันระหว่างการเปลี่ยน ไม่ใช่แค่ตอนท้าย ฟีเจอร์อย่างการวางแผน snapshots และ rollback ช่วยให้การแก้สไตล์เล็ก ๆ และย้อนกลับได้ก่อนคุณส่งซอร์สโค้ดออกไป\n
