คิดให้ดีกว่าไปกับโค้ด: ใช้คณิตศาสตร์ทางลัดเพื่อเข้าใจระบบซอฟต์แวร์ขนาดใหญ่

แรงบันดาลใจจากหนังสือ “Thinking Better: The Art of the Shortcut” โดย Marcus du Sautoy

🚀 บทนำ

การเปิดโค้ดเบสขนาดใหญ่ครั้งแรก อาจรู้สึกเหมือนหลงเข้าป่าไฟล์ มีหลายพันไฟล์ หลายเลเยอร์ และฟังก์ชันไม่รู้จบ วิธีที่หลายคนเลือกคือ “อ่านทุกอย่าง” ซึ่งใช้แรงเยอะและเสียเวลา

แต่นักคณิตศาสตร์อย่าง Marcus du Sautoy ชี้ให้เห็นในหนังสือ Thinking Better ว่า ความก้าวหน้าไม่ได้มาจากการทุ่มแรง แต่จาก การใช้ทางลัด (Shortcut)—วิธีที่ฉลาดในการข้ามขั้นตอนที่ไม่จำเป็นแต่ยังไปถึงคำตอบที่ถูกต้องได้

โพสต์นี้จะเล่าว่าเราจะนำแนวคิด “ทางลัดคณิตศาสตร์” มาใช้กับการ เข้าใจและปรับแต่งระบบซอฟต์แวร์ขนาดใหญ่ ได้อย่างไร

🧩 ทางลัด #1: Patterns & Symmetry → หาลักษณะที่ซ้ำกัน

คณิตศาสตร์ชอบความสมมาตรเพราะทำให้ปัญหาง่ายขึ้น โค้ดก็เช่นกัน—ระบบส่วนใหญ่จะมี โครงสร้างที่ซ้ำกัน

👉 วิธีใช้:

• มองหาโครงสร้างโฟลเดอร์ที่ซ้ำ เช่น feature folder
• Django: ทุกแอปมักมี models.py, views.py, serializers.py
• Vue: แต่ละ feature มี routes.ts, api.ts, views/

ผลลัพธ์: เข้าใจ 1 ส่วน = เข้าใจทั้งชุด

🧩 ทางลัด #2: Abstraction → ตัดรายละเอียดเพื่อเห็นภาพรวม

การทำ Abstraction คือการละทิ้งรายละเอียดเล็กน้อยเพื่อให้เห็นโครงสร้างหลัก ในโค้ดคือการดู การเชื่อมโยงของโมดูลและการไหลของข้อมูล

👉 วิธีใช้:

• สร้าง กราฟการ import (Python: pyan3 … > imports.dot)
• สแกนหาส่วนที่กำหนดสัญญา (contract) เช่น BaseModel, Serializer, Schema

ผลลัพธ์: ไม่ต้องตามทุกฟังก์ชัน แต่เห็น เครือข่ายความสัมพันธ์

🧩 ทางลัด #3: Probability & Sampling → อ่านเฉพาะไฟล์ที่สำคัญที่สุด

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

👉 วิธีใช้:

• หาไฟล์ที่ ใหญ่ที่สุด และ แก้ไขบ่อยที่สุด:

  git log --name-only --pretty=format: | sort | uniq -c | sort -nr | head -50

• ไฟล์เหล่านี้มักเก็บ ตรรกะธุรกิจหลัก

ผลลัพธ์: เข้าใจหัวใจของระบบในเวลาไม่กี่ชั่วโมง

🧩 ทางลัด #4: Algorithmic Thinking → ทำให้ค้นหาได้

อัลกอริทึมคือวิธีแก้ปัญหาอย่างมีระบบ นักพัฒนาก็ควรทำให้โค้ด ค้นหาและนำทางได้ง่าย

👉 วิธีใช้:

• เปิดใช้งาน LSP, Treesitter, ctags ใน editor

• เขียน ripgrep queries เพื่อค้นหาประเด็นหลัก:

  • Routes: rg "router\.|urlpattern"
  • จุดสร้าง object: rg "Factory|create\("
  • Side effects: rg "requests\.|axios\("

ผลลัพธ์: เลิกไถไฟล์สุ่ม ๆ แล้วใช้วิธี “query โค้ด” แทน

🧩 ทางลัด #5: Invariants → กฎที่ห้ามเปลี่ยน

คณิตศาสตร์ใช้ “ข้อพิสูจน์” เพื่อล็อกความจริง ในซอฟต์แวร์เราต้องรู้ว่า อะไรที่เปลี่ยนไม่ได้

👉 ตัวอย่าง Invariants:

• โครงสร้างฐานข้อมูล
• รูปแบบ request/response ของ API
• กฎสิทธิ์การใช้งาน
• ชื่อ event ที่ใช้ส่งต่อ

ผลลัพธ์: เขียน contract tests และ smoke tests เพื่อป้องกันการพัง

🛠️ ทางลัดการปรับแต่ง (Customization Shortcuts)

เมื่อเราเห็นโครงสร้างชัดแล้ว จะสามารถเพิ่มฟีเจอร์โดยไม่ไปยุ่งแกนกลาง

• Django:

  • Middleware → ใส่ logic ส่วนกลาง
  • Signals → ดัก event เพื่อทำงานเสริม
  • Serializers → แก้ payload API
  • Management commands → สร้างคำสั่ง custom

• Vue:

  • Axios interceptors → เพิ่ม logic request/response
  • Router guards → เช็ค auth หรือ feature flag
  • Feature folders → ขยายระบบให้ตรง pattern

🔀 แผนผังตัดสินใจ: จะปรับแต่งตรงไหนดี?

flowchart TD
    A["ต้องการพฤติกรรมใหม่?"] --> B{"มี seam อยู่แล้วหรือไม่?<br/>(middleware / signal / interceptor / plugin)"}
    B -- "ใช่" --> C["ใช้ adapter / plugin<br/>(ต่อเข้า seam)"]
    B -- "ไม่ใช่" --> D{"สามารถ wrap ได้หรือไม่?"}
    D -- "ใช่" --> E["สร้าง facade / service layer<br/>ครอบโค้ดเดิม"]
    D -- "ไม่ใช่" --> F["Fork หรือ patch<br/>(ทางเลือกสุดท้าย)"]
    C --> G["ไม่แตะต้อง core"]
    E --> G
    F --> H["เขียน test และ doc ให้รัดกุม"]

Shortcut: ใช้ seam ก่อน → ถ้าไม่มี ให้ wrap → fork เป็นทางสุดท้าย

⏱️ Playbook 90 นาที

1. 0–10 นาที: อ่าน README, config, folder tree วาด symmetry map
2. 10–30 นาที: สร้าง imports graph + list entry points / data contracts
3. 30–60 นาที: อ่านไฟล์ 10 อันดับแรกที่แก้บ่อยที่สุด
4. 60–90 นาที: วางแผนปรับแต่งตาม seam + เขียน smoke tests

🎯 สรุป

โค้ดเบสขนาดใหญ่เหมือนเขาวงกต แต่คณิตศาสตร์บอกเราว่า ทุกเขาวงกตมีทางลัด ถ้าเรามองหา

ด้วยแนวคิด Patterns, Abstraction, Probability, Algorithms, และ Invariants เราจะเข้าใจระบบได้อย่างรวดเร็ว และปรับแต่งได้โดยไม่ทำลายแกนกลาง

นี่คือศิลปะของการ คิดให้ดีกว่าด้วยโค้ด