เปลี่ยนทีละนิด เพื่อจะรู้ว่าอะไรพัง

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

แล้วมีบางอย่างพัง

หน้าจอเพี้ยน หรือปุ่มที่เคยกดได้กดไม่ได้แล้ว หรือรูปหาย คุณนั่งมองอยู่หน้าจอ แล้วคำถามเดียวที่โผล่ขึ้นมาในหัวคือ "มันพังเพราะข้อไหนในห้าข้อที่สั่งไป" และคุณตอบไม่ได้ ทั้งห้าข้อถูกแก้พร้อมกัน พันกันอยู่ในที่เดียว คุณไม่มีทางแยกออกเลยว่าตัวไหนคือตัวการ

นี่คือความกลัวที่ทำให้หลายคนหยุดอยู่แค่นี้ "แก้อย่างเดียว พังไปสามอย่าง" มันน่ากลัวเพราะมันเหมือนคุณคุมอะไรไม่ได้เลย แต่จริง ๆ แล้วปัญหาไม่ได้อยู่ที่ AI หรือที่โค้ด ปัญหาอยู่ที่ขนาดของการเปลี่ยนแปลง คุณเปลี่ยนก้อนใหญ่เกินไปในครั้งเดียว จนพอมันพัง คุณก็มองไม่เห็นว่าพังตรงไหน

บทนี้จะสอนวิธีคิดที่กลับด้านความกลัวนี้ คุณจะเปลี่ยนทีละนิด ทำเป็นวงรอบเดิมซ้ำ ๆ ที่เชื่อถือได้ และจะไม่สั่ง AI ว่า "ทำให้ห้าอย่าง" อีกเลย

ทำไมการเปลี่ยนก้อนใหญ่ถึงซ่อนต้นตอ

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

พอมีอะไรพัง คุณต้องไปหาว่าต้นตออยู่ที่ไหน แล้วคุณต้องไปไล่ดูทั้งหมดที่เพิ่งเปลี่ยน เพราะตัวการอาจซ่อนอยู่ในจุดไหนก็ได้ในนั้น ยิ่งคุณเปลี่ยนเยอะ พื้นที่ที่ต้องไปไล่หาก็ยิ่งกว้าง

กลับกัน ถ้าคุณเปลี่ยนแค่อย่างเดียว แก้ไปแค่ไม่กี่บรรทัด แล้วมันพัง คุณรู้ทันทีว่าต้นตออยู่ตรงไหน เพราะมีของใหม่อยู่แค่ที่เดียวให้ดู ที่ที่ต้องไปหาเล็กลง การหาก็ง่ายขึ้น

มีคำที่ช่วยให้เห็นภาพนี้ชัดขึ้น เวลาคุณเปลี่ยนอะไรสักอย่างในโปรแกรม ขอบเขตของสิ่งที่การเปลี่ยนนั้นอาจไปกระทบได้ เราเรียกว่า blast radius หรือ "รัศมีการกระทบ" การเปลี่ยนก้อนใหญ่มีรัศมีกว้าง พังได้หลายที่ และตามหายาก การเปลี่ยนทีละนิดมีรัศมีแคบ ถ้าพังก็พังในวงแคบ ๆ ที่คุณมองออกทันที

💡 ใจความสำคัญ: การเปลี่ยนเล็ก ไม่ได้ทำให้พังน้อยลงเสมอไป แต่มันทำให้ตอนพัง คุณรู้ทันทีว่าอะไรเป็นต้นเหตุ เพราะมีของใหม่อยู่แค่ที่เดียวให้ตรวจ นี่คือทั้งหมดของเรื่อง

ทำไมแตะที่นี่ แล้วพังที่โน่น

แต่ยังมีปริศนาที่ค้างอยู่ ทำไมคุณแก้ปุ่มล็อกอิน แล้วหน้าจ่ายเงินถึงพัง ทั้งที่สองอย่างนี้ดูไม่เกี่ยวกันเลย

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

ความที่ส่วนต่าง ๆ พึ่งพากันแบบนี้ เราเรียกในวงการว่า coupling แปลคร่าว ๆ ว่า "การผูกติดกัน" ยิ่งสองส่วนผูกติดกันแน่น การไปแตะส่วนหนึ่งก็ยิ่งมีโอกาสกระเทือนอีกส่วน และความผูกติดนี้แหละคือต้นเหตุที่ทำให้ blast radius กว้างกว่าที่คุณเดา

นี่คือเหตุผลว่าทำไม "แก้อย่างเดียว พังไปสามอย่าง" ถึงเกิดขึ้นได้จริง ไม่ใช่เพราะ AI ซุ่มซ่าม แต่เพราะของที่ดูไม่เกี่ยวกัน จริง ๆ มันผูกกันอยู่ใต้ผิว และคุณมองไม่เห็นเส้นที่ผูก

บ้านที่สร้างเร็ว กับบ้านที่แยกระบบ

ลองนึกถึงบ้านสองหลัง

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

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

โค้ดที่ผูกติดกันแน่นคือบ้านหลังแรก โค้ดที่แยกส่วนชัดคือบ้านหลังที่สอง

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

และนี่แหละคือเหตุผลที่คุณต้องให้ AI บอกคุณว่ารัศมีของการเปลี่ยนกว้างแค่ไหน ก่อน ที่มันจะลงมือแก้ เพราะคุณเคาะผนังเองไม่ได้ คุณต้องถามคนที่มองทะลุผนังได้ ว่าถ้าขยับตรงนี้ จะมีท่ออะไรขาดบ้าง

พิธีกรรมเปลี่ยนทีละนิด

ทีนี้มาดูวิธีทำจริง ทุกครั้งที่คุณจะเปลี่ยนอะไร ให้เดินตามวงรอบเดิมนี้ทุกรอบ จนมันกลายเป็นนิสัย เรียกมันว่าพิธีกรรมก็ได้ เพราะมันคือชุดท่าที่ทำซ้ำเหมือนเดิมทุกครั้ง

1. ทำจุดเซฟก่อน ก่อนแตะอะไร บันทึกสภาพปัจจุบันที่ยังดีอยู่ไว้ก่อน เผื่อต้องถอยกลับ จุดเซฟนี้คือสิ่งที่ทำให้คุณกล้าทดลอง เพราะคุณรู้ว่าถอยกลับได้เสมอ (จุดเซฟทำด้วย git ซึ่งอยู่ใน บทเรื่อง git ส่วนการคิดเรื่องถอยกลับได้ทั้งหมดอยู่ใน บทเรื่องการถอยกลับได้ บทนี้แค่บอกว่า ต้องทำตรงนี้ก่อน)

2. บอกเป็นประโยคเดียวว่าจะเปลี่ยนอะไร เขียนออกมาให้ตัวเองอ่านว่า รอบนี้จะทำอะไร อย่างเดียว เช่น "เปลี่ยนสีปุ่มล็อกอินเป็นน้ำเงิน" ถ้าคุณเขียนแล้วต้องใช้คำว่า "และ" หรือ "แล้วก็" แสดงว่ามันยังไม่ใช่อย่างเดียว มันใหญ่เกินไป (เดี๋ยวเราจะกลับมาที่เทคนิคนี้)

3. ชี้ให้ AI เห็นว่าของที่จะแก้อยู่ตรงไหน บอกให้ชัดว่าสิ่งที่จะเปลี่ยนอยู่ไฟล์ไหนหรือส่วนไหนของแอป (โค้ดอยู่เป็นไฟล์ ๆ ตามที่อธิบายไว้ใน บทเรื่องไฟล์ โปรเจกต์ และ repo) ยิ่งคุณชี้ได้ตรง AI ยิ่งไม่ต้องเดา และยิ่งไม่ไปแตะที่ที่ไม่เกี่ยว (วิธีชี้ให้แม่นอยู่ใน บทเรื่องการชี้ให้ตรงจุด)

4. ให้ AI วางแผนก่อนลงมือแก้ นี่คือขั้นที่คนข้ามบ่อยที่สุด และเป็นขั้นที่สำคัญที่สุด อย่าเพิ่งให้ AI แก้ ให้มันบอกคุณก่อนว่า มันจะแก้ไฟล์ไหนบ้าง แตะตรงไหนบ้าง และที่สำคัญคือ การเปลี่ยนนี้อาจไปกระทบส่วนอื่นตรงไหนได้บ้าง พูดง่าย ๆ คือให้มันบอก blast radius ออกมาเป็นคำพูด ก่อนจะลงมือ

ที่ AI ทำแบบนี้ได้ เพราะมันไล่อ่านโค้ดได้ว่าไฟล์ไหนบ้างเรียกใช้โค้ดที่คุณกำลังจะแก้ พอมีไฟล์อื่นเรียกใช้อยู่ นั่นแหละคือเส้นที่ผูกกัน (coupling) ที่คุณมองไม่เห็น การให้มันวางแผน ก่อน จึงเป็นการบังคับให้เส้นที่ซ่อนอยู่โผล่ออกมาเป็นตัวหนังสือ นี่คือการเคาะผนังในแบบที่โค้ดทำได้

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

สั่งแบบนี้ "อย่าเพิ่งแก้ บอกฉันก่อนว่าจะแก้ไฟล์ไหนบ้าง และการเปลี่ยนนี้อาจกระทบส่วนไหนของแอปได้บ้าง แล้วรอให้ฉันบอกว่าโอเค"

5. แก้แค่อย่างเดียว พอแผนโอเค ให้ AI ลงมือ แต่ทำแค่อย่างที่คุณเขียนไว้ในข้อ 2 ไม่ใช่พ่วงอย่างอื่นเข้ามาด้วย

6. ตรวจว่าเรื่องสำคัญยังใช้ได้ และของข้าง ๆ ยังไม่พัง ดูสองอย่าง หนึ่งคือสิ่งที่คุณเพิ่งเปลี่ยน มันทำงานอย่างที่ต้องการไหม สองคือของที่อยู่ข้าง ๆ ของที่ AI บอกว่าอาจกระทบในข้อ 4 มันยังดีอยู่ไหม นี่คือการเช็คว่าการเปลี่ยนของคุณไม่ได้ไปโดนอะไรที่ไม่ตั้งใจในรัศมีที่กว้างกว่าที่คิด (วิธีตรวจอย่างเป็นระบบ และการทำตาข่ายกันพังอัตโนมัติ อยู่ใน บทเรื่องการตรวจสอบ)

7. เซฟอีกจุด หรือถอยกลับ ถ้าทุกอย่างผ่าน ทำจุดเซฟใหม่ ปักหมุดความก้าวหน้าไว้ ถ้าไม่ผ่าน ถอยกลับไปจุดเซฟในข้อ 1 ทันที อย่าพยายามแก้ของที่พังต่อไปเรื่อย ๆ ถอยกลับให้สะอาด แล้วเริ่มรอบใหม่

แล้ววนกลับไปข้อ 1 สำหรับการเปลี่ยนถัดไป

การทดสอบ "พูดเป็นประโยคเดียว"

กลับมาที่ข้อ 2 เพราะมันคือเครื่องมือที่ใช้ง่ายที่สุดในบทนี้ และคุณใช้ได้ทันที

วิธีรู้ว่าการเปลี่ยนของคุณเล็กพอหรือยัง ให้ลองพูดมันออกมาเป็นประโยคเดียว ถ้าพูดได้จบในประโยคเดียวโดยไม่ต้องมีคำว่า "และ" หรือ "แล้วก็" แสดงว่ามันเล็กพอ

"เปลี่ยนสีปุ่มล็อกอินเป็นน้ำเงิน" ประโยคเดียว จบ เล็กพอ

"เพิ่มปุ่มล็อกอิน และทำหน้าโปรไฟล์ แล้วก็เปลี่ยนสีปุ่ม" มีสาม "และ" นี่คือสามการเปลี่ยน ไม่ใช่หนึ่ง แยกมันออกเป็นสามรอบ ทำทีละรอบ

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

นี่คือกฎข้อสองของการสร้างของกับ AI เปลี่ยนทีละอย่าง กฎข้อแรกคือทำให้ทุกอย่างถอยกลับได้ (อยู่ใน บทเรื่องการถอยกลับได้) สองข้อนี้ทำงานคู่กัน ถอยกลับได้ทำให้คุณกล้าลอง เปลี่ยนทีละอย่างทำให้คุณรู้ว่าตอนพัง พังเพราะอะไร

เรื่องจริง: ตอนรูปอวาตาร์ขึ้นเป็นกล่องขาว

เว็บที่คุณกำลังอ่านอยู่นี้ สร้างโดยคนที่ไม่ใช่โปรแกรมเมอร์ ด้วยการสั่ง AI และมันก็เคยเจอบั๊กที่ดูน่ากลัวมาก

หน้าแรกของเว็บมีรูปอวาตาร์ของเจ้าของเว็บ แต่อยู่ดี ๆ รูปนั้นกลับขึ้นเป็นกล่องสีขาวทึบ มองไม่เห็นรูปเลย เป็นปัญหาที่เห็นชัดและน่ารำคาญ

ถ้าทำตามสัญชาตญาณแรก คนส่วนใหญ่จะสั่ง AI ว่า "รูปขึ้นเป็นกล่องขาว ช่วยแก้ให้หน่อย แล้วก็ทำให้รูปคมขึ้นด้วย แล้วก็เช็คให้ด้วยว่าหน้าอื่นไม่มีปัญหานี้" สั่งรวดเดียวทุกอย่าง แล้วก็จะเจอกับ "แก้อย่างเดียว พังสามอย่าง" เหมือนเดิม

แต่ครั้งนี้ไม่ได้ทำแบบนั้น มันถูกแก้เป็นการเปลี่ยนเล็ก ๆ แยกกันทีละอย่าง

อย่างแรก หาต้นตอของกล่องขาวก่อน ต้นเหตุจริงคือลูกเล่นทาง CSS ตัวหนึ่งที่ชื่อ mix-blend-mode: multiply ซึ่งใช้ลบพื้นหลังขาวของรูปออก แต่เบราว์เซอร์ Safari ดันไม่รองรับลูกเล่นนี้ มันเลยเงียบ ๆ ไม่ทำตาม รูปเลยเหลือพื้นขาวเต็มกล่อง แก้ตรงนี้อย่างเดียว ตรวจ ผ่าน

อย่างที่สอง พอกล่องขาวหาย ก็เจอบั๊กถัดมาที่ขอบรูปมีสีเลอะออกมา (เรียกว่า poster bleed) อันนี้เป็นคนละปัญหา ก็แก้แยกอีกรอบหนึ่ง ตรวจ ผ่าน

อย่างที่สาม ค่อยมาทำให้รูปคมขึ้น เพราะวิธีลบพื้นหลังทำให้รายละเอียดบางส่วนหายไป อันนี้ก็เป็นอีกรอบแยกต่างหาก

สามปัญหา สามรอบ แต่ละรอบแก้อย่างเดียวและตรวจก่อนไปต่อ พอครบทุกรอบ ยังเช็คข้ามเบราว์เซอร์อีกที ว่ารูปขึ้นถูกทั้งใน Safari และเบราว์เซอร์อื่น

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

สังเกตว่าทั้งสามอย่างนี้ พูดเป็นประโยคเดียวได้หมด "แก้กล่องขาว" "แก้ขอบรูปเลอะ" "ทำให้รูปคม" แต่ละอย่างคือกฎข้อสองในการกระทำ เปลี่ยนทีละอย่าง และนั่นแหละคือเหตุผลที่ต้นตอหาเจอเสมอ

ความเข้าใจผิดที่ต้องแก้

หลายคนคิดว่า การสั่งทีเดียวหลายอย่างคือการทำงานที่มีประสิทธิภาพ ในหัวมันดูเหมือนเร็วกว่า สั่งครั้งเดียวได้ห้าอย่าง ดีกว่าสั่งห้าครั้ง จริง ๆ แล้วมันเร็วกว่าก็จริง แต่เร็วกว่าแค่ตอนที่ทุกอย่างไปได้สวย พอมันพัง การสั่งทีเดียวหลายอย่างกลายเป็นฝันร้าย เพราะคุณต้องไปรื้อหาในกองที่พันกัน เวลาที่คุณคิดว่าประหยัดไปตอนแรก คุณจ่ายคืนเป็นสิบเท่าตอนหาต้นตอ การเปลี่ยนทีละนิดช้ากว่าตอนเริ่ม แต่เร็วกว่ามากเมื่อนับรวมเวลาที่ไม่ต้องเสียไปกับการหลงทาง

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

สรุป

กลับไปที่ความกลัวตอนต้น "แก้อย่างเดียว พังไปสามอย่าง" ตอนนี้คุณรู้แล้วว่ามันเกิดจากอะไร ของในแอปแอบผูกกันอยู่ใต้ผิว (coupling) ที่คุณมองไม่เห็น พอคุณเปลี่ยนก้อนใหญ่ รัศมีที่อาจพัง (blast radius) ก็กว้าง และพอมันพังจริง คุณก็หาต้นตอไม่เจอ เพราะของใหม่กระจายอยู่หลายที่เกินไป

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

นี่คือกฎข้อสอง เปลี่ยนทีละอย่าง พอคุณทำแบบนี้ ตอนมีอะไรพัง คุณจะไม่นั่งงงหน้าจออีก คุณจะรู้ทันทีว่าต้องไปดูที่ไหน เพราะคุณเพิ่งเปลี่ยนของอยู่แค่ที่เดียว

---

อ่านต่อ: Preview ก่อนขึ้นจริง

แหล่งอ้างอิง

• https://git-scm.com/docs