อ่านโค้ดคนอื่นยังไงไม่ให้ท้อ

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

อย่าเริ่มจากไฟล์แรก

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

1. หา entry point — main, index, หรือ script ใน package.json
2. ตามหนึ่ง request จาก route ไปจนถึงฐานข้อมูล จดไว้ว่าผ่านชั้นไหนบ้าง
3. ดูไฟล์เทสต์ก่อนโค้ดจริง เทสต์คือเอกสารที่รันได้
4. อ่าน README และไฟล์ migration ชื่อตารางบอกโมเดลธุรกิจได้เยอะ

ใช้ git เป็นไกด์นำเที่ยว

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

# ไฟล์ไหนถูกแก้บ่อยที่สุดในปีที่ผ่านมา
git log --since="1 year ago" --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -20

# ใครเป็นคนดูแลไฟล์นี้
git log --format='%an' -- path/to/file.ts | sort | uniq -c | sort -rn

# ทำไมบรรทัดนี้ถึงเขียนแบบนี้
git log -L 120,140:path/to/file.ts

แยกให้ออกระหว่าง "เขียนแปลก" กับ "เขียนผิด"

โค้ดที่ดูประหลาดส่วนใหญ่มักมีเหตุผล มันอาจเป็นทางอ้อมของบั๊กเมื่อสามปีก่อน ก่อนจะ refactor ให้ หาคอมมิตที่สร้างบรรทัดนั้นก่อน

เขียนสิ่งที่เข้าใจไว้ระหว่างทาง

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

อย่ารอให้เข้าใจทั้งหมดก่อนลงมือ

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

ความรู้สึกท้อวันแรกๆ เป็นเรื่องปกติ มันจะค่อย ๆ หายไปเองเมื่อแผนที่ในหัวเริ่มชัดขึ้น