งานสร้างชิ้นแรกของคุณ นาทีต่อนาที

ความผิดพลาดแรก: การเขียนสเปคแทนที่จะเขียนประโยค

คนที่เคยเจ็บจากซอฟต์แวร์แย่ๆ มาก่อนมักจะเปิดตัวสร้างแล้วพิมพ์ยาวเป็นพารากราฟ ระบบให้เกรด การตั้งค่าหน่วยวัด โหมดออฟไลน์ ธีมสี ใส่ทุกอย่างมาก่อนที่คำตอบแรกจะกลับมาด้วยซ้ำ มันดูเป็นการเตรียมตัวที่รอบคอบ แต่จริงๆ ไม่ใช่ ตัวสร้างจะอ่านประโยคเดียวของคุณ คาดเดาสิ่งที่คุณต้องการ และตอบกลับมาด้วยแผนภายในประมาณสิบห้าวินาที — "บันทึกการฝึกสำหรับนักไต่ผา" จะถูกแปลงเป็นบันทึกเซสชัน มุมมองติดตามเกรด และแดชบอร์ด โดยเลือกเกรด V-scale สำหรับโบลเดอริ่งและเส้นทาง YDS เป็นค่าเริ่มต้น เพราะนั่นคือสิ่งที่นักไต่ผาส่วนใหญ่ใช้จริง มันจะบอกให้คุณรู้ว่าเลือกอะไรไว้ตรงในแผนนั้นเลย เพื่อให้คุณแก้ไขได้ในหนึ่งบรรทัดหากคุณเป็นข้อยกเว้น การพิมพ์พารากราฟไว้ล่วงหน้าไม่ได้ช่วยข้ามขั้นตอนนี้ไปได้ คุณยังคงได้รับแผน ยังคงต้องอ่านมัน และตอนนี้คุณเสียเวลาสามนาทีในการพิมพ์เงื่อนไขที่แผนจะแสดงให้คุณเห็นอยู่ดี ตามลำดับที่สำคัญจริงๆ สำหรับการสร้างของคุณ

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

ข้อผิดพลาดที่สอง: การเฝ้าดูฟีดเหมือนเทอร์มินัลที่ค้าง

การสร้างจะทำงานฝั่งเซิร์ฟเวอร์ และความเสียหายในกรณีนี้มักเป็นเพียงการเข้าใจผิด บางคนจ้องฟีดกิจกรรมที่นิ่งเงียบอยู่สองนาทีแล้วสรุปว่ามันค้าง ทั้งที่จริงแล้วไม่ได้ค้าง — เพียงแค่อยู่ในเฟสที่ไม่ได้แสดงผลลัพธ์ที่มองเห็นได้ทุกวินาที และฟีดจะระบุว่าคุณอยู่ในเฟสไหนด้วยเหตุผลนี้เอง คุณสามารถปิดแท็บได้เลย การรันงานไม่ได้อยู่ในเบราว์เซอร์ของคุณ

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

ต้นทุนที่แท้จริงของโมเดลนี้คือคุณจะสูญเสียฟีดแบ็กแบบทันทีที่เห็นโค้ดไหลเข้าโปรแกรมแก้ไขทีละตัวอักษร สิ่งที่มาแทนที่คือระบบที่ยังทำงานต่อได้แม้แล็ปท็อปของคุณจะเข้าสู่โหมดสลีปหรือ Wi-Fi หลุด ระบบที่คุณสามารถตรวจสอบได้จากโทรศัพท์ และทำงานต่อไปไม่ว่าคุณจะเฝ้าดูอยู่หรือไม่ สำหรับการสร้างที่ใช้เวลาเก้าสิบวินาที การแลกเปลี่ยนนี้แทบไม่มีนัยสำคัญ แต่สำหรับการสร้างระบบแบ็กเอนด์ที่ใช้เวลาสิบสองนาที มันคือความแตกต่างระหว่างการนั่งเฝ้าเทอร์มินัลกับการไปดื่มกาแฟ

ข้อผิดพลาดที่สาม: สับสนระหว่าง "สร้างเสร็จแล้ว" กับ "เสร็จสมบูรณ์"

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

การตรวจสอบความปลอดภัยจะตามหาสิ่งพื้น ๆ ที่มักสร้างปัญหาจริงในสภาพแวดล้อมโปรดักชัน เช่น API key ที่ถูก commit เข้าไปในโค้ดฝั่งไคลเอนต์ ฟอร์มที่รับข้อมูลโดยไม่มีการกรอง หรือ endpoint ที่เชื่อ user ID ที่ไคลเอนต์ส่งมาแทนที่จะดึงจากเซสชัน การตรวจสอบการเข้าถึง (accessibility) ไม่ใช่ linter ที่คุณปิดเสียงด้วยคอมเมนต์ได้ — มันตรวจสอบอัตราส่วนความคมชัดจริงและว่าองค์ประกอบที่โต้ตอบได้นั้นเข้าถึงได้ด้วยคีย์บอร์ดหรือไม่

ความสอดคล้อง (conformance) คือสิ่งที่คนมักประเมินค่าต่ำเกินไปมากที่สุด เป็นเรื่องง่ายที่รอบการสร้างจะแอบตัดสิ่งที่คุณขอทิ้งไปเงียบ ๆ — เช่นฟิลด์ partner/belay-log จากการแก้ไขแผนของคุณ — ที่ถูกลดความสำคัญลงระหว่างไฟล์ที่สามของการสร้างโดยไม่มีใครตัดสินใจตัดมันออกจริง ๆ การตรวจสอบความสอดคล้องจะอ่านแผนที่คุณอนุมัติเทียบกับผลลัพธ์จริงและจับช่องว่างนั้นได้ เมื่อพบปัญหา การแก้ไขจะถูกดำเนินการและตรวจสอบซ้ำโดยอัตโนมัติ คุณจะไม่ได้รับรายการสิ่งที่ต้องทำ แต่จะได้รับการแก้ไขที่คุณไม่เคยเห็น หรือไม่มีอะไรผิดพลาดตั้งแต่แรก กลไกของสิ่งที่ตัวตรวจสอบแต่ละตัวตรวจ และสิ่งที่เกิดขึ้นเมื่อมีอะไรล้มเหลวติดต่อกันสองครั้ง อยู่ใน How builds verify themselves สิ่งเดียวที่ควรจดจำจากหัวข้อนี้คือ: เสร็จสมบูรณ์หมายถึง ผ่านการตรวจสอบ ไม่ใช่ ถูกสร้างขึ้น หากคุณมองว่าสองสิ่งนี้เหมือนกัน สักวันคุณจะปล่อย key ที่รั่วไหลหรือปุ่มที่กดไม่ถึงออกไปในที่สุด

สิ่งที่คุณจะได้รับหากหลีกเลี่ยงข้อผิดพลาดทั้งสามนี้

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

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