ทำให้ AI เป็นลูกค้าที่เขียนสเปกตามระดับของคุณ พร้อมหมุดหมายและเกณฑ์ความสำเร็จที่ตรวจสอบได้ แต่ไม่เขียนโค้ดให้เด็ดขาด
เปิดบทเรียนนี้ใน Kodokonเมื่อคุณผ่านพ้นพื้นฐานไปแล้ว บทเรียนสำเร็จรูปจะหยุดพาคุณก้าวหน้า: มันให้คุณคัดลอกวิธีแก้ไปตามเส้นทางที่ปูไว้แล้ว สิ่งที่พานักพัฒนาผู้มีฝีมือให้ก้าวหน้าคือโปรเจกต์ที่สูงกว่าระดับของตัวเองเล็กน้อย ยากพอจะบีบให้ต้องตัดสินใจ มีกรอบพอจะไม่จมปลัก ปัญหาคือ: การปรับเทียบระดับตัวเองแทบเป็นไปไม่ได้ คุณมักเลือกอะไรที่ง่ายเกินไปหรือทะเยอทะยานเกินไป AI เก่งเรื่องการปรับเทียบนั้น ตราบใดที่คุณให้บทบาทที่ถูกต้องแก่มัน แนวทางที่ผิด: "เขียนแอปติดตามค่าใช้จ่ายให้ฉันหน่อย" คุณจะได้ผลิตภัณฑ์สำเร็จรูปและทักษะเป็นศูนย์ แนวทางที่ถูกต้อง: AI เล่นบทบาทลูกค้าที่เขียนสเปก ส่วนนักพัฒนาคือคุณ
คุณคือลูกค้าของโปรเจกต์ (product owner) คุณเขียนสเปก คุณไม่เขียนโค้ดเด็ดขาด
โปรไฟล์ของผม: ผมฝึก [ภาษา/เทคโนโลยี] เป็นประจำ ผมรู้อยู่แล้ว: [รายการตามจริง] ผมอยากพัฒนาในเรื่อง: [แนวคิดที่เจาะจง เช่น การจัดการข้อผิดพลาดแบบ async, การทดสอบ, การแบ่งเป็นโมดูล]
เวลาที่มี: ประมาณ [X] ชั่วโมง กระจายไปตลอด [ระยะเวลา]
เขียนสเปกสำหรับมินิโปรเจกต์:
- ความต้องการในไม่เกิน 5 บรรทัด เรียบเรียงอย่างที่ลูกค้าจริงจะพูด (บอกว่า อะไร ไม่ใช่ อย่างไร)
- หมุดหมาย 3 ถึง 5 จุดที่เรียงลำดับ แต่ละจุดจบลงด้วยสิ่งที่ใช้งานได้จริงและสาธิตได้
- สำหรับแต่ละหมุดหมาย: เกณฑ์ความสำเร็จที่**สังเกตได้** ("คำสั่ง X แสดง Y", "กรณี Z ถูกปฏิเสธพร้อมข้อความที่ชัดเจน" ไม่ใช่ "โค้ดสะอาด")
- ข้อจำกัดทางเทคนิคหนึ่งข้อที่บีบให้ผมต้องใช้แนวคิดที่เจาะจงไว้
- ส่วนขยายเสริม 2 อย่างเผื่อผมทำเสร็จก่อน
ข้อห้าม: ห้ามมีโค้ด, ห้ามบังคับชื่อฟังก์ชันหรือไลบรารี, ห้ามใบ้วิธีทำ การลงมือทำเป็นงานของผมการปรับเทียบระดับตั้งอยู่บนข้อมูลสองอย่างที่มีเพียงคุณเท่านั้นที่รู้: สิ่งที่คุณรู้อยู่แล้ว (จงซื่อสัตย์ ไม่งั้นโปรเจกต์จะง่ายเกินไป) และสิ่งที่คุณอยากฝึก (หนึ่งหรือสองแนวคิด ไม่ใช่หกอย่าง) หมุดหมายเปลี่ยนโปรเจกต์ให้เป็นวงจรป้อนกลับ: แต่ละขั้นส่งมอบพฤติกรรมที่สาธิตได้ ซึ่งกันไม่ให้คุณจมปลักกับการก่อวิหารสถาปัตยกรรม ส่วนเกณฑ์ความสำเร็จที่สังเกตได้นั้นเปลี่ยนทุกอย่าง: "โค้ดสะอาด" พิสูจน์ไม่ได้ ส่วน "การนำเข้าไฟล์ที่เสียหายแสดงข้อผิดพลาดที่ชัดเจนโดยไม่แครช" พิสูจน์ได้ในสิบวินาที เกณฑ์ที่สังเกตไม่ได้คือความคิดเห็น เกณฑ์ที่สังเกตได้คือการทดสอบเพื่อรับมอบงาน
คุณคือลูกค้าของโปรเจกต์ต่อไปนี้: [ทวนสเปกอีกครั้งหรือวางหมุดหมายปัจจุบัน].
ผมคิดว่าผมทำหมุดหมาย [X] เสร็จแล้ว นี่คือสิ่งที่โปรแกรมของผมทำ จากมุมมองของผู้ใช้: [อธิบายพฤติกรรมที่สังเกตได้ ไม่ใช่โค้ด].
1. ไล่ดูเกณฑ์ความสำเร็จของหมุดหมายนี้ทีละข้อ: ถามผมด้วยคำถามที่เจาะจงเพื่อพิสูจน์ว่ามันบรรลุจริง รวมถึงกรณีขอบ (อินพุตว่างเปล่า, ค่านอกช่วง, การกระทำที่ทำซ้ำสองครั้ง)
2. ถ้าเกณฑ์ข้อใดยังไม่บรรลุ ให้บอกว่าข้อไหนและอย่างไร โดยไม่บอกวิธีแก้แก่ผม
3. ถ้าผ่านทุกข้อ ให้ระบุหมุดหมายถัดไป โดยยังคงไม่มีโค้ดหรือคำใบ้วิธีทำพิธีกรรมการพิสูจน์นี้จำลองการทดสอบเพื่อรับมอบงานของโปรเจกต์จริง: ลูกค้าไม่อ่านโค้ดของคุณ พวกเขาซักถามพฤติกรรม คำถามเกี่ยวกับกรณีขอบคือส่วนที่มีค่า นั่นคือจุดที่คุณค้นพบว่าการนำไปใช้ของคุณจัดการอะไรไม่ได้ ยังเหลือช่วงเวลาสำคัญของทุกโปรเจกต์เดี่ยว: การติดขัด สิ่งล่อใจที่จะพลิกไปพิมพ์ "เขียนส่วนนี้ให้ฉันหน่อย" พุ่งขึ้นสูงสุด จงต้านมันด้วยโปรโตคอลคำใบ้แบบขั้นบันได: แต่ละระดับบอกมากขึ้นนิดหน่อย และคุณใช้เพียงระดับที่จำเป็นต่อการขยับต่อไปเท่านั้น
ผมติดขัดในโปรเจกต์ของผม [บริบท] จุดที่ติด: [สิ่งที่คุณพยายามทำ, สิ่งที่คุณลองแล้ว, ตรงไหนที่มันพัง].
ให้คำใบ้แบบ**ขั้นบันได**แก่ผม ทีละระดับ:
- คำใบ้ 1: แนวทางกว้าง ๆ แนวคิดที่ควรกลับไปทบทวน หรือทิศทางหนึ่ง ในหนึ่งประโยค
- คำใบ้ 2 (เฉพาะเมื่อผมขอ): เจาะจงขึ้น ส่วนไหนของแนวทางของผมที่ควรพิจารณาใหม่
- คำใบ้ 3 (เฉพาะเมื่อผมขอ): หลักการของวิธีแก้ อธิบายเป็นภาษาเข้าใจง่าย ไม่มีโค้ด
เริ่มด้วยคำใบ้ 1 แล้วรอคำตอบของผม อย่าข้ามระดับเด็ดขาด แม้ผมจะใจร้อนหรือยืนกราน