← All posts · บทความทั้งหมด

On principle, and chaos

ว่าด้วยหลักการ และความวุ่นวาย


ผมมีโพสต์อิทแผ่นเล็ก ๆ แปะอยู่เหนือจอ มันเขียนว่า

"when we lose our principle, we invite chaos." "เมื่อใดที่เราละทิ้งหลักการ เมื่อนั้นเราเชิญความวุ่นวายเข้ามา"

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

The chaos doesn't arrive. It accumulates.

ความวุ่นวายไม่ได้มาถึงปุบปับ — มันสะสม

หลายๆ codebase ที่ผมเคยเห็นพังลง ล้วนพังในแบบคล้ายๆกัน ไม่ใช่การตัดสินใจผิดครั้งใหญ่ ครั้งเดียวแล้วทุกอย่างถล่ม มันคือการยอมจำนนเล็ก ๆ ร้อยครั้ง — กฎที่ถูกงอหรือถูกประนีประนอมในวันอังคาร ลืมในวันพฤหัส หรือแทนที่ในวันศุกร์ด้วย // TODO refactor พอสามเดือนผ่านไป คุณก็ยืนงงอยู่หน้า bug ที่หาต้นตอไม่เจอ เพราะมันไม่มี "ต้นตอ" — มีแต่ "พื้นฐานที่ค่อย ๆ ทรุด"

หลักการในโค้ดหน้าตาเป็นยังไง

หลักการที่หมายถึงไม่ใช่ปรัชญาใหญ่โต มันคือกฎเล็ก ๆ ที่ทำตามแล้ว ถูก ทำตามได้ทุกวัน แต่การฝ่าฝืนในวันที่เหนื่อยจะแพงมาก

อย่างเช่น:

  • One source of truth — state ของอะไรก็ตามต้องอยู่ที่เดียว ห้ามมี derived state สองที่ที่ต้อง sync กันเอง
  • Server boundaries are explicit — โค้ดที่รันบน server กับ client แยกกันชัดเจน ห้ามให้ใครเดา ห้ามให้ใครพลาด
  • Build ผ่านสะอาดหรือไม่ก็ไม่ deploy — ไม่มี // @ts-ignore ค้างคา ไม่มี warning สีเหลืองที่ "เดี๋ยวค่อยดู"
// แต่ละข้อมันเล็กนะ แต่ละ shortcut ก็เล็ก
// ผลรวมของมันต่างหากที่ไม่เล็ก
function shortcut(): never {
  throw new Error("we'll fix this in v2");
}

ผมไม่ได้เก็บกฎพวกนี้ไว้เพราะมันสวย ผมเก็บไว้เพราะ — พอถึงวันที่หนัก ๆ ติดต่อกันสามวัน สมองผมล้าเกินกว่าจะตัดสินใจดี ๆ จากศูนย์ได้ หลักการมันก็เลยตัดสินใจให้ผมแทน

เรื่องของการ "เดี๋ยวค่อยทำ"

ทุกครั้งที่ผมพิมพ์ // TODO หรือ ไม่ใช่ // TODO แต่ comment ไว้ คิดว่าทดๆ ไว้ชั่วคราว ผมก็รู้สึกว่ามันคือสัญญาที่ผมให้กับ "ตัวเองในอนาคต" ปัญหาคือ ตัวเองในอนาคตไม่เคยอยู่ตรงนั้นเพื่อรับสัญญา เขามีงานของเขา มี deadline ของเขา และ TODO ของผมก็กลายเป็นมรดกที่ใครสักคนต้องมาเก็บ

ลอง grep -r "TODO" . ใน codebase อายุสามปี แล้วคุณจะเข้าใจว่าผมหมายถึงอะไร มันไม่ใช่รายการสิ่งที่ค้างทำ มันคือ timeline ของความหวังที่ค่อย ๆ จางหาย

หลักการของผมเลยกลายเป็น: ถ้าจะเขียน TODO ต้องเขียน ticket ตามด้วย ถ้าไม่เขียน ticket แปลว่ามันไม่สำคัญพอที่จะเขียน TODO ตั้งแต่แรก

หลักการคือการคุยกับตัวเองในอนาคต

programming ส่วนใหญ่ไม่ได้แข่งกับคอมพิวเตอร์ — มันแข่งกับตัวเราเองในอีก 6 เดือนข้างหน้า คนที่อ่านโค้ดที่คุณเขียนวันนี้ ส่วนใหญ่ก็คือคุณ — แต่เป็นคุณที่ลืมหมดแล้วว่าตอนเขียน คิดอะไรอยู่

หลักการคือเครื่องมือสื่อสารกับคนคนนั้น

  • ตั้งชื่อตัวแปรให้อ่านแล้วเข้าใจ ไม่ต้องตีความ
  • เขียน function ให้ทำอย่างเดียว เพราะตัวเองในอนาคตจะอ่านชื่อ function แล้วเชื่อ
  • เขียน test ให้คลุมพฤติกรรม (Behavior) ไม่ใช่ implementation เพราะตัวเองในอนาคตจะ refactor แล้วต้องการรู้ว่าอะไรพัง
  • commit เล็ก ๆ message ชัด ๆ เพราะตัวเองในอนาคตจะ git blame แล้วต้องเข้าใจว่าทำไม

ทุกข้อข้างบนผมเคยฝ่าฝืนมาหมดแล้ว และทุกข้อก็มีเรื่องเล่าหลังบ้านที่ผมไม่อยากเล่าซ้ำ — นั่นแหละครับ คือเหตุผลที่มันกลายเป็น "หลักการ" ของผม

chaos ไม่ใช่ศัตรู มันคือต้นทุน

จุดที่ผมเปลี่ยนวิธีคิดจริง ๆ คือตอนที่ผมหยุดมองความวุ่นวายเป็น "ปัญหา" แล้วเริ่มมองว่ามันเป็น "ต้นทุน" ของการเป็น ทางลัด (shortcut)

ทุก shortcut มีดอกเบี้ย แล้วดอกเบี้ยมันทบ ทุกครั้งที่คุณข้าม code review ทุกครั้งที่คุณ skip test ทุกครั้งที่คุณ copy-paste แทนที่จะ refactor — คุณยืมเวลาจากตัวเองในอนาคต ในอัตราดอกเบี้ยที่คุณไม่ได้ตกลงไว้ก่อน

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

หลักการของทีม ไม่ใช่ของคนคนเดียว

อีกอย่างที่ผมเรียนรู้ช้ากว่าที่ควร คือ — หลักการที่อยู่แค่ในหัวคนคนเดียวมันไม่ใช่หลักการ มันคือ "ความชอบส่วนตัว" และวันที่คนคนนั้นไม่ว่าง ก็คือวันที่ความวุ่นวายเริ่มสะสม

หลักการของทีมต้องเขียนออกมาเป็นข้อ ๆ ต้องอ่านออกเสียงได้ ต้องชี้ไปบรรทัดในโค้ดที่ละเมิดมันได้ ไม่งั้นมันก็แค่ vibes — และ vibes ไม่ scale

ผมเคยอยู่ทีมที่มีหลักการแบบ vibes ทุกคน "รู้ ๆ กันอยู่" ว่าเขียนยังไงดี ผลคือพอมีคนใหม่เข้ามา PR ของเขาผ่าน review ลำบาก ไม่ใช่เพราะเขาเขียนไม่ดี — แต่เพราะ "ดี" ไม่เคยถูกนิยาม ทุกคนเลยใช้นิยามของตัวเอง

ส่งท้าย

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

โพสต์อิทของผมยังอยู่เหนือจอ ผมยังเผลอลืมมันเป็นบางวัน แต่อย่างน้อยมันก็คอยเตือนผมเสมอว่า — ตัวเองในอนาคต ก็เป็นคนที่ผมต้องเคารพ

j ↑ k ↓