บทนำ: โค้ดไม่ได้สนใจความรู้สึกของคุณ
สิ่งหนึ่งที่เกี่ยวกับโมเดลภาษาขนาดใหญ่และโค้ดคือ: พวกมันมีความมั่นใจอย่างน่าทึ่งและไม่สนใจว่าโปรแกรมของคุณจะคอมไพล์หรือไม่ ยินดีที่จะเขียนสคริปต์ ที่แก้ปัญหาของคุณ พร้อมกับอีกสองปัญหาที่มันสร้างขึ้นมาเองเพื่อความสนุก เคล็ดลับ—เคล็ดลับเดียวที่สำคัญ—คือการเรียนรู้วิธีการ เพื่อสร้างโค้ดที่ถูกต้องในลักษณะที่ไม่เปิดโอกาสให้ความรู้สึกเข้ามาเกี่ยวข้อง และให้ความสำคัญกับความจริงมากที่สุด คุณไม่ต้องการข้อความที่ฟังดูเหมือนโค้ด คุณต้องการโค้ดที่ทำงานได้เหมือนโค้ด มันมีความแตกต่างกัน
ผู้คนปฏิบัติต่อการ เหมือนมนต์ขลัง—พูดคำที่ถูกต้อง แล้วจะได้แอปที่สมบูรณ์แบบ นั่นคือความคิดแบบบูชาเครื่องบิน โค้ดคือสัญญา หากคุณต้องการความถูกต้องจาก คุณต้องเขียนสัญญา "สร้างเว็บแอป" ไม่ใช่สัญญา "สร้าง ใน ที่รับ ตรวจสอบ ด้วย และส่งคืน เมื่อเกิดข้อผิดพลาดของ ด้วยรูปแบบ ที่เฉพาะเจาะจง" คือสัญญา นั่นคือวิธีการ เพื่อสร้างโค้ดที่ถูกต้อง: คุณกำหนดสัญญาให้ชัดเจน
สิ่งนี้คืออะไร (และไม่ใช่)
- นี่คือคู่มือวิธีการเพื่อให้ได้โค้ดที่น่าเชื่อถือและทดสอบได้จาก
- นี่ไม่ใช่คำเทศนาเกี่ยวกับ " เข้ามาแทนที่นักพัฒนา" เครื่องมือไม่ได้เข้ามาแทนที่การคิด
- มุ่งเน้นไปที่ ที่ใช้งานได้จริง โครงสร้าง และ : ส่วนที่น่าเบื่อที่ทำให้เวทมนตร์เกิดขึ้น
หากคุณต้องการโค้ดที่ทำงานได้ คุณต้องให้คำจำกัดความที่ใช้ได้จริงของคำว่า "ทำงานได้" แก่ หากคุณต้องการการสร้างโค้ดที่ถูกต้อง คุณต้องกำหนดความถูกต้องในรูปแบบที่เรียบง่ายและทดสอบได้ นั่นคือทั้งหมดของเกม
กำหนดความถูกต้องเหมือนทนายความ ไม่ใช่นักกวี
โค้ดที่ "ถูกต้อง" ไม่ใช่โค้ดที่ "ดูน่าเชื่อถือ" ความถูกต้องคือ:
- ความถูกต้องทางวากยสัมพันธ์: สามารถคอมไพล์หรือรันภายใต้ตัวแปรภาษาได้
- ความเที่ยงตรงเชิงความหมาย: ทำในสิ่งที่ข้อกำหนดระบุ
- พฤติกรรมที่แน่นอน: อินพุตเดียวกัน เอาต์พุตเดียวกัน ภายในขอบเขตข้อผิดพลาดที่กำหนด
- ความถูกต้องของเวอร์ชัน: ใช้ เวอร์ชัน และคุณสมบัติภาษาที่ถูกต้อง
จะให้สิ่งที่คุณขอ หากคุณขอ "ฟังก์ชันที่เรียงลำดับรายการ" คุณมักจะได้ฟังก์ชันดังกล่าว หากคุณขอ "การเรียงลำดับแบบคงที่ในตำแหน่งโดยใช้ความหมาย ที่มีพื้นที่พิเศษ " นั่นคือสัญญาที่แตกต่างกัน "วิธีการ เพื่อสร้างโค้ดที่ถูกต้อง" เริ่มต้นด้วยการเขียนสัญญาเหล่านั้นลงใน
ที่ได้รับการอัปเกรด
แย่: "เขียน สำหรับงาน"
ดีกว่า: "เขียน ที่มีเส้นทาง ที่ตรวจสอบฟิลด์ {title: string, dueDate: ISO 8601} และตอบกลับ 201 พร้อมกับอ็อบเจ็กต์ที่สร้างขึ้น หรือ 400 พร้อมรายละเอียดข้อผิดพลาด"
ถูกต้อง: "สร้างเซิร์ฟเวอร์ ที่มี เพียงตัวเดียว ข้อกำหนด: 1) ตรวจสอบ ด้วย ; 2) ฟิลด์: (สตริงที่ไม่ว่างเปล่า สูงสุด 140), วันที่ในอนาคต); 3) เมื่อสำเร็จ: 201 พร้อม {id: ULID, title, dueDate}; 4) เมื่อไม่ถูกต้อง: 400 พร้อม {error: 'VALIDATION', details: array}; 5) ไม่มีฐานข้อมูล; ในหน่วยความจำ; 6) รวมไฟล์ทดสอบ ที่ครอบคลุมกรณีที่ถูกต้อง ไม่ถูกต้อง (ชื่อเรื่องว่างเปล่า วันที่ผ่านมา); 7) จัดเตรียมสคริปต์ สำหรับการทดสอบและการพัฒนา; 8) ใช้ ; 9) อย่าใส่คำอธิบายที่ไม่จำเป็น"
สังเกตรูปร่าง: เวอร์ชันภาษา ไลบรารี ข้อจำกัด เอาต์พุต ข้อผิดพลาด การทดสอบ และแม้แต่โครงสร้างแพ็กเกจ คุณได้ขจัดความคลุมเครือออกไปแล้ว งานของ คือการเติมโค้ด ไม่ใช่ข้อกำหนด
รูปแบบ : แล้วจึง
หากคุณต้องการการสร้างโค้ดที่ถูกต้องจาก คุณต้องให้ทางวิ่งแก่โค้ด:
- การวางกรอบระบบ (สายจูงสั้น)
- คุณ: "คุณกำลังเขียน คุณภาพระดับโปรดักชันสำหรับ แสดงเฉพาะบล็อกโค้ดที่มีชื่อไฟล์เท่านั้น"
- เหตุผล: คุณควบคุมน้ำเสียงและรูปแบบเอาต์พุต อย่าปล่อยให้เป็นเรื่องบังเอิญ
- รวมเวอร์ชันภาษา ตัวเลือกแพ็กเกจ ความหมายของข้อผิดพลาด รูปแบบ ข้อจำกัดด้านประสิทธิภาพ และข้อจำกัดด้านความปลอดภัย
- บอกให้ เขียน ก่อน การทดสอบกำหนด "ถูกต้อง" ได้ดีกว่าคำคุณศัพท์ หากบรรทัดของโค้ดไม่ได้ใช้ในการทดสอบ แสดงว่าเป็นเพียงการประดับ
- หลังจากทดสอบเท่านั้น ใช่ นี่คือ โดยพื้นฐาน แต่มีหุ่นยนต์ที่ไม่เคยเบื่อที่จะเขียน
- หากการทดสอบล้มเหลวหรือการนำเข้าไม่ตรงกัน ให้อัปเดตเฉพาะส่วนที่ล้มเหลวเท่านั้น อย่าเขียนโครงการทั้งหมดใหม่
ทำงานได้ดีเมื่อมีบริบทและขอบเขต ให้ขอบเขตแก่โค้ด
การตรึงเวอร์ชันไม่ใช่ทางเลือก
ข้อมูลการฝึกอบรมของ เต็มไปด้วยเอกสารเก่าและใหม่ นั่นเป็นวิธีสุภาพในการพูดว่ามันเห็นคำแนะนำที่ขัดแย้งกันมากมาย "ใช้ " เป็นเรื่องคลุมเครือ "ใช้ กับ " คือทิศทาง อย่าเชื่อถือค่าเริ่มต้น:
- ภาษา: ตรึงไปที่ —สิ่งที่คุณรันจริง
- เฟรมเวิร์ก: ระบุเวอร์ชันหลักที่แน่นอนและแฟล็กการเปลี่ยนแปลงที่ทำให้เกิดการหยุดชะงัก
- : ตรึงเวอร์ชัน; เทียบกับ มีความสำคัญ
- : ระบุกฎเพื่อหลีกเลี่ยงการเขียนใหม่แบบ "สไตล์ปิงปอง"
หากคุณไม่ตรึง คุณจะได้รับเพลงฮิตที่ยิ่งใหญ่ที่สุดจากบล็อกโพสต์ห้าปี การสร้างโค้ดที่ถูกต้องแพ้ความรู้สึกถึงอดีต
อย่าขอโครงสร้าง "โปรไฟล์ผู้ใช้" กำหนด ใน และกำหนดให้มีการตรวจสอบ:
จากนั้นให้ บังคับใช้ ที่ขอบเขต—อินพุต การเขียนฐานข้อมูล และคิวข้อความ ขอ และรหัสข้อผิดพลาดที่ชัดเจน ความถูกต้องชอบ ความคลุมเครือไม่ชอบ
ทำให้สังเกตได้ หรืออย่าแกล้งทำเป็นว่ามันเป็นจริง
บอกให้ เพิ่มการบันทึก เมตริก และการติดตามในที่ที่คุณต้องการ—และให้เก็บไว้ในที่ที่คุณไม่ต้องการ ที่ดีประกอบด้วย:
- นโยบายการบันทึก: ระดับ การแก้ไข โครงสร้าง (บันทึก โปรด)
- เมตริก: เวลาต่อคำขอ จำนวนข้อผิดพลาด
- สถานะ: ที่พิสูจน์ว่าการอ้างอิงขึ้น
จะเพิ่มสิ่งที่คุณขอ หากคุณไม่ขอ คุณจะได้รับคำสั่งพิมพ์—ถ้าคุณโชคดี
วิธีที่ดีในการ เพื่อสร้างโค้ดที่ถูกต้องคือการทำให้การทดสอบเป็นแหล่งที่มาของความจริง ตัวอย่าง:
"เขียนการทดสอบ สำหรับฟังก์ชัน ที่:
- ทำให้ส่วน และ เป็นตัวพิมพ์เล็ก;
- ลบจุดในส่วน เฉพาะสำหรับ ;
- ปฏิเสธอินพุตที่ไม่มี @ ตัวเดียวหรือมีช่องว่าง;
- รักษายูนิโค้ดโดเมน ไว้ตามเดิม ครอบคลุมกรณีขอบ หลังจากเขียนการทดสอบแล้ว ให้ใช้ฟังก์ชันเพื่อให้ผ่าน
มักจะเขียนโค้ดได้ดีขึ้นเมื่อถูกบังคับให้ทำการทดสอบที่คุณอธิบายไว้ หากไม่เป็นเช่นนั้น คุณจะมีความล้มเหลวที่เป็นรูปธรรม ไม่ใช่ข้อโต้แย้งด้านความรู้สึก
ไม่มีภาพหลอนโดยการก่อสร้าง
คุณไม่สามารถกำจัดภาพหลอนได้ แต่คุณสามารถล้อมพวกมันไว้ได้:
- ขอการอ้างอิงหรือ แหล่งที่มาเฉพาะเมื่อมีแหล่งที่มา สำหรับวิธีการ ให้ขอลิงก์เอกสารและกำหนดให้โค้ดตรงกับเอกสารเหล่านั้น
- สำหรับ ส่วนตัว ให้วางข้อกำหนดไว้ใน อย่าคาดหวังว่า จะรู้จัก ภายในของคุณ
- สำหรับไลบรารีที่มี ที่สับสน ให้ใส่ ตัวอย่างจากเอกสารทางการและบอกให้ ปฏิบัติตาม
โค้ดที่ถูกต้องส่วนใหญ่เป็นการอ้างอิงที่ถูกต้อง ให้ อ้างอิง
คู่มือสไตล์: สิ่งที่เซ็กซี่น้อยที่สุด มีประโยชน์มากที่สุด
เขียนโค้ดในสไตล์ใดก็ตามที่อนุมานได้ นั่นคือสูตรสำหรับการเปลี่ยนแปลง วางคู่มือสไตล์ของคุณ ระบุ:
- การจัดรูปแบบ ( ค่าเริ่มต้น)
- รูปแบบการจัดการข้อผิดพลาด
นอกจากนี้ ให้ขอความคิดเห็นเชิงเหตุผลสั้นๆ สำหรับตัวเลือกที่ไม่ชัดเจน อนาคตคุณจะขอบคุณ และ ปัจจุบันจะสร้าง "แก้ไข" น้อยลง
อีกวิธีหนึ่งในการคิดเกี่ยวกับวิธีการ เพื่อสร้างโค้ดที่ถูกต้อง: ใช้คำพูดของคุณกับ ไม่ใช่เอาต์พุต คุณต้องการ:
- คำบรรยายที่ไม่จำเป็นน้อยที่สุดในเอาต์พุต
บอกให้โค้ดระงับคำอธิบายและแสดงเฉพาะบล็อกโค้ดที่มีชื่อไฟล์และ สั้นๆ หากคุณต้องการความคิดเห็น ให้ขอในการรันแยกต่างหาก การสอดแทรกข้อความและโค้ดคือวิธีที่ข้อบกพร่องแอบเข้ามาสวมแว่นกันลมและหมวกทรงสูง
การปรับแต่ง: วงจรที่รัดกุมที่ใช้งานได้จริง
เส้นทางที่เร็วที่สุดไปยังโค้ดที่เชื่อถือได้ไม่ใช่ "ทำให้ถูกต้องตั้งแต่ครั้งแรก" แต่เป็นวงจรแก้ไขสั้นๆ:
- เรียกใช้ในเครื่อง วางเอาต์พุตการทดสอบที่ไม่สำเร็จและข้อผิดพลาดของ กลับเข้าไปใน ตามตัวอักษร
- สั่ง: "แก้ไขเฉพาะบรรทัดที่จำเป็นขั้นต่ำเท่านั้น อย่าเปลี่ยนลายเซ็นฟังก์ชันเว้นแต่จำเป็นโดยการทดสอบที่ไม่สำเร็จ"
เก่งในการใช้ เมื่อคุณบอกว่าอะไรเสียอย่างชัดเจน อย่าถอดความบันทึกความล้มเหลว วางมัน บันทึกคือความจริง
ความปลอดภัยคือคุณสมบัติ ไม่ใช่คำลงท้าย
เนื่องจากโมเดลได้รับการฝึกฝนเกี่ยวกับโค้ดสาธารณะ (ดี ไม่ดี และสาปแช่ง) คุณจึงต้องการทำให้ความปลอดภัยเป็นข้อกำหนดชั้นหนึ่ง:
- ไม่อนุญาตอย่างชัดเจน และ ที่พิมพ์เป็นสตริง
- กำหนดให้มี ที่เป็น การป้องกัน และการจำกัดอัตรา
- ขอการตรึงการอ้างอิงบวกไฟล์ล็อก
- กำหนดให้มีการจัดการสำหรับความลับผ่านตัวแปรสภาพแวดล้อมหรือตัวจัดการความลับ
ที่ปลอดภัยโดยค่าเริ่มต้นให้โค้ดที่ปลอดภัยกว่า "เราจะ ในภายหลัง" สร้างพาดหัวข่าว
ประสิทธิภาพ: บอกว่า "เร็ว" หมายถึงอะไร
"ทำให้เร็ว" แปลว่า "ทำอะไรก็ได้" แทนที่จะระบุเมตริก:
- เป้าหมาย สำหรับในหน่วยความจำ สำหรับ
- ความซับซ้อนของเวลา (ต้องเป็น ไม่ใช่
จะเลือกอัลกอริทึมให้เหมาะกับงบประมาณที่คุณตั้งไว้ ให้งบประมาณแก่โค้ด
เอกสาร: เพียงพอที่จะสอนคนแปลกหน้า
ขอให้ สร้าง ที่ประกอบด้วย:
- คำแนะนำในการตั้งค่าพร้อมเวอร์ชันที่แน่นอน
- ข้อจำกัดและข้อแลกเปลี่ยนที่ทราบ
"โค้ดที่ถูกต้อง" รวมถึงเอกสารที่ถูกต้อง พวกเขาเป็นส่วนหนึ่งของการส่งมอบ
เทมเพลต:
ระบบ: คุณเป็นวิศวกร ที่พิถีพิถัน แสดงเฉพาะบล็อกโค้ดที่มีชื่อไฟล์
ผู้ใช้:
- คำขอ: {amount: Decimal as string, from: 'USD'|'EUR', to: same}
- ตรวจสอบด้วย ส่งคืนรูปร่าง 422 เมื่อเกิดข้อผิดพลาดของ
- ใช้ฟังก์ชันบริสุทธิ์ ที่มีอัตราคงที่ {USD:1, EUR:1.1}
- ส่งคืน {amount: string, currency: string} พร้อม 200
- รวมการทดสอบ ที่ครอบคลุมกรณีที่ถูกต้อง ไม่ถูกต้อง (ทศนิยมไม่ถูกต้อง รหัสที่ไม่รู้จัก) และขอบ (0)
- ให้ ที่มีการตรึงการอ้างอิง; รวมการกำหนดค่า และ
- ไม่มีการโทรเครือข่าย ไม่มีคำอธิบาย
เทมเพลต:
ระบบ: คุณกำลังเขียน แสดงเฉพาะบล็อกโค้ดที่มีชื่อไฟล์
ผู้ใช้:
- สร้าง ชื่อ ที่อ่าน และพิมพ์ ที่ปลอดภัยสำหรับ
- กฎ: ตัวพิมพ์เล็ก, เท่านั้น, ตัวคั่นยัติภังค์, ยุบช่องว่าง, ลบเครื่องหมายวรรคตอน
- ให้ และ พร้อมการทดสอบตาราง
- รวม ที่มีการทดสอบและสร้างเป้าหมาย
เทมเพลต:
ระบบ: คุณเป็นวิศวกร ที่ใช้งานได้จริงโดยกำหนดเป้าหมาย
ผู้ใช้:
- : value: string, onChange(value): void, delay=300
- ใช้ ; ไม่มี ของบุคคลที่สาม
- รวมการทดสอบ พร้อมตัวจับเวลาปลอม
เทมเพลตเหล่านี้แสดงให้เห็นถึงวิธีการ เพื่อสร้างโค้ดที่ถูกต้องโดยการตรึงเวอร์ชัน การกำหนดพฤติกรรม และการกำหนดให้มีการทดสอบ
ปฏิเสธที่จะฉลาด: เมื่อใดควรพูดว่า "อย่าเพิ่มประสิทธิภาพ"
หากคุณไม่ต้องการการเพิ่มประสิทธิภาพขนาดเล็กก่อนเวลาอันควร (และคุณไม่ต้องการ) ให้พูดว่า:
- "ให้ความสำคัญกับความสามารถในการอ่านมากกว่าความฉลาด; ไม่มีการบิดบิตเว้นแต่การทดสอบจะกำหนด"
- "ไม่มีการเรียกซ้ำหาก ชัดเจนกว่า"
- "ไม่มี ; ชัดเจน > โดยนัย"
ชอบสร้างความประทับใจ อย่าปล่อยให้โค้ดทำเช่นนั้น ทำให้ผ่านการทดสอบและอ่านง่าย นั่นก็น่าประทับใจพอแล้ว
Sider.AI ในเวิร์กโฟลว์ ที่ซึ่งช่วยได้จริง ฉันเคยเห็นผู้คนสลับ ในแท็บแชทแบบสุ่มราวกับว่าเป็นพิธีกรรมในการเพิ่มประสิทธิภาพ ใช้พื้นที่ทำงานที่เข้าใจบริบทของโค้ด Sider.AI ตัวอย่างเช่น สร้างขึ้นโดยเน้นที่การเก็บข้อกำหนด โค้ด และบันทึกการทดสอบของคุณไว้ในมุมมอง ดังนั้นวงจร "วางข้อผิดพลาด แก้ไขบรรทัด" จึงรัดกุมจริง ไม่ใช่เวทมนตร์ เป็นโครงสร้างพื้นฐานที่น่าเบื่อที่ป้องกันไม่ให้คุณหลงประเด็น หากเครื่องมือของคุณเก็บสัญญา การทดสอบ และโค้ดไว้ในการสนทนาเดียวกัน—โดยไม่รบกวนคุณด้วย —ให้ใช้ Sider ทำเช่นนั้น วิธีแก้ไขข้อบกพร่องด้วย ในฐานะเพื่อนร่วมทีม ไม่ใช่นักทำนาย
- วางเอาต์พุตการทดสอบที่ไม่สำเร็จตามที่เป็น อย่าสรุป
- ขอ : "ตอบกลับด้วย เทียบกับไฟล์ เท่านั้น"
- สำหรับข้อบกพร่องรันไทม์ ให้เพิ่ม ที่สร้างซ้ำได้ที่เล็กที่สุดและขอคำอธิบายพร้อม
- สำหรับข้อผิดพลาดของไลบรารี ให้วางข้อความที่ตัดตอนมาจากเอกสารที่คุณคิดว่าใช้ได้และถามว่า: "นี่คือ ที่ถูกต้องสำหรับเวอร์ชัน หรือไม่ หากไม่ถูกต้อง ให้อัปเดตโค้ดและอ้างอิงข้อความที่ตัดตอนมาที่ถูกต้อง"
เป้าหมายคือทำให้ โต้แย้งด้วยหลักฐาน คุณนำหลักฐานมา
ขบวนพาเหรดหลุมพราง (และวิธีหลบหลีก)
- กับดัก "ล่าสุด": อย่าพูดว่า "ใช้ล่าสุด" พูดว่า "ใช้เวอร์ชัน " และยึดมั่นในเวอร์ชันนั้น
- ไฟล์ทดสอบว่างเปล่า: หากคุณไม่ต้องการการทดสอบ คุณจะไม่ได้รับการทดสอบ
- ความเข้าใจผิดแบบ : วางแผนการปรับแต่งสั้นๆ สองหรือสามครั้ง เร็วกว่า ที่พองโตครั้งเดียว
- นโยบายข้อผิดพลาดที่ไม่ชัดเจน: กำหนดรหัสสถานะและ "ส่งคืนข้อผิดพลาด" ไม่มีความหมาย
- การอ้างอิงที่ไม่เป็นเจ้าของ: หากโค้ดอาศัยบริการที่คุณไม่สามารถควบคุมได้ ให้ ขอ
รายการตรวจสอบ ของคุณ (ติดเทปไว้ใกล้จอภาพของคุณ)
- ตรึงเวอร์ชันภาษาและรันไทม์
- กำหนดความหมายของข้อผิดพลาด (รหัส รูปร่าง)
- ทดสอบก่อน แล้วจึงเขียนโค้ด
- ข้อจำกัดด้านความปลอดภัยที่ชัดเจน
- ระบุงบประมาณด้านประสิทธิภาพ
- จำกัดรูปแบบเอาต์พุต (ชื่อไฟล์ บล็อกโค้ด )
- วงจรการปรับแต่งสั้นๆ พร้อมบันทึกที่วาง
หากคุณทำทั้งสิบข้อได้ โดยทั่วไปจะสร้างโค้ดที่ถูกต้องซึ่งอยู่รอดได้ในเวลากลางวัน
ตัวอย่างที่ใช้งานได้: จากคลุมเครือไปจนถึงได้รับการยืนยัน
คลุมเครือ: "เขียนฟังก์ชันเพื่อแยกวิเคราะห์ อย่างปลอดภัย"
ผลลัพธ์: อาจจะโอเค อาจจะผิด แน่นอนว่าไม่ได้ทดสอบ
ที่แม่นยำ:
"คุณกำลังเขียน แสดงเฉพาะบล็อกโค้ดที่มีชื่อไฟล์
สร้าง และ พร้อมฟังก์ชัน ข้อกำหนด: ใช้ ที่มี และ ไม่อนุญาตไบต์ ปฏิเสธไฟล์ >10MB จำกัดคอลัมน์ไว้ที่ 100 ลบ ถือว่าเซลล์ว่างเป็นสตริงว่าง ยก พร้อมรหัสข้อความ {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS} รวมการทดสอบใน ด้วย ที่ครอบคลุม , ไบต์ , ไฟล์ 11MB, 101 คอลัมน์ และการจัดการ ให้ ที่มีการตรึงการอ้างอิงและการกำหนดค่า
"คุณจะได้รับโค้ด การทดสอบ และการจัดการขอบ จากนั้นคุณเรียกใช้การทดสอบ วางความล้มเหลว และทำซ้ำด้วย ขั้นต่ำ นั่นคือการสร้างโค้ดที่ถูกต้องในการปฏิบัติ
เกี่ยวกับ "ความคิดสร้างสรรค์" และคำทางการตลาดอื่นๆ
ฉันไม่ต้องการโค้ด "สร้างสรรค์" ฉันต้องการโค้ดที่ถูกต้อง ประหยัดความคิดสร้างสรรค์ในการตั้งชื่อแมวของคุณ เมื่อ ความคิดสร้างสรรค์เป็นผลพลอยได้ตามธรรมชาติของข้อจำกัดที่มั่นคง การทดสอบที่ถูกต้องและข้อกำหนดที่ชัดเจนสร้างโซลูชันที่หรูหรา ที่ไม่ถูกต้องสร้าง "ประดิษฐ์ ใหม่ด้วยอิโมจิ" อย่าล่อใจ
ความลับที่ไม่ลับ
วิธี เพื่อสร้างโค้ดที่ถูกต้องนั้นน่าเบื่อ: เขียนสิ่งที่คุณต้องการ ตรึงเวอร์ชัน กำหนด กำหนดให้มีการทดสอบ และทำซ้ำด้วยความล้มเหลวจริง นั่นคือทั้งหมด ไม่มีเวทมนตร์ เพียงแค่ระเบียบวินัยทางวิศวกรรม กับโมเดลที่สามารถพิมพ์ได้เร็วมากและไม่รังเกียจที่จะเขียนกรณีทดสอบที่เหมือนกันเกือบสิบห้ากรณี
และนั่นคือจุดหักมุม: ความถูกต้องไม่น่าดึงดูดใจ ที่ใช้งานได้อ่านเหมือนรายการตรวจสอบ โค้ดที่ส่งอ่านเหมือนว่าเขียนโดยมนุษย์ที่ใส่ใจ คุณจะได้รับทั้งสองอย่างโดยปฏิบัติต่อโมเดลเหมือนวิศวกรจูเนียร์ที่เติบโตภายใต้ข้อกำหนดที่ชัดเจนและเหี่ยวเฉาภายใต้คำแนะนำที่คลุมเครือ ให้สัญญา ทำให้ผ่านการทดสอบ จากนั้นบางทีคุณอาจไว้วางใจได้—ด้วยความไว้วางใจแบบที่คุณให้กับเครื่องมือ ไม่ใช่นักทำนาย
บทสรุป: เวทมนตร์น้อยลง การรับประกันมากขึ้น
หากคุณต้องการเวทมนตร์ ไปดูการแสดงมายากล หากคุณต้องการซอฟต์แวร์ที่คอมไพล์และทำงานได้ ให้เขียน ที่ทำงานเหมือนการรับประกัน วิธี เพื่อสร้างโค้ดที่ถูกต้องไม่ได้เกี่ยวกับการใช้ถ้อยคำที่สวยงามหรือคำหลักลับๆ แต่เกี่ยวกับข้อจำกัด การทดสอบ เวอร์ชัน และวงจรการตอบรับ ทำสี่สิ่งนั้น แล้วคุณจะได้โค้ดที่ทำงานได้ ข้ามไป แล้วคุณจะได้รับนิยายที่จัดรูปแบบอย่างสวยงาม
โค้ดไม่สนใจความรู้สึกของคุณ โชคดีที่การทดสอบก็เช่นกัน
คำถามที่พบบ่อย (FAQ)
คำถามที่ 1: วิธีที่ง่ายที่สุดในการแจ้ง Claude Haiku 4.5 เพื่อสร้างโค้ดที่ถูกต้องแม่นยำคืออะไร?
ปฏิบัติต่อมันเหมือนสัญญา: กำหนดเวอร์ชัน, กำหนด schema, ระบุรูปแบบข้อผิดพลาด และกำหนดให้มีการทดสอบก่อน ยิ่งข้อจำกัดชัดเจนเท่าไหร่ โค้ดก็จะยิ่งแม่นยำมากขึ้นเท่านั้น
คำถามที่ 2: ฉันจะลดอาการหลอนได้อย่างไรเมื่อ Claude เขียนโค้ด?
วางเอกสารหรือข้อกำหนดที่เชื่อถือได้ และกำหนดให้ปฏิบัติตาม API เหล่านั้นอย่างเคร่งครัด สำหรับ endpoints ส่วนตัว ให้ใส่ข้อกำหนดของคุณเอง—อย่าคาดหวังให้มันคาดเดา
คำถามที่ 3: ฉันควรถาม Claude เพื่อขอการทดสอบ หรือเขียนเอง?
ขอให้ Claude สร้างการทดสอบก่อน จากนั้นจึงนำโค้ดไปใช้เพื่อให้เป็นไปตามนั้น การทดสอบกำหนดความถูกต้องได้ดีกว่าคำคุณศัพท์ และทำให้โมเดลมีความซื่อสัตย์
คำถามที่ 4: การตรึงเวอร์ชันใน prompts ควรมีความเฉพาะเจาะจงแค่ไหน?
เฉพาะเจาะจงมาก: runtime ของภาษา, framework major/minor และเวอร์ชัน SDK คำว่า “ล่าสุด” เชิญชวนรูปแบบที่ขัดแย้งกัน ความถูกต้องแม่นยำขึ้นอยู่กับเป้าหมายที่เสถียร
คำถามที่ 5: Sider.AI เหมาะสมกับ prompting เพื่อให้ได้โค้ดที่ถูกต้องแม่นยำตรงไหน?
ใช้ Sider.AI เพื่อเก็บข้อกำหนด, โค้ด, diffs และบันทึกการทดสอบไว้ใน loop เดียว มันไม่ได้ทำเวทมนตร์—มันแค่รักษาบริบทไว้ เพื่อให้การแก้ไขของ Claude ติดตามความล้มเหลวที่แท้จริงของคุณ 
