บทที่ 4: Pragmatic Paranoia — ความระแวงแบบนักปฏิบัติ

ภาพรวม

Tip 36: You Can't Write Perfect Software — คุณไม่มีทางเขียนซอฟต์แวร์ที่สมบูรณ์แบบได้

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

---

Topic 23: Design by Contract — การออกแบบด้วยสัญญา

Tip 37: Design with Contracts — ออกแบบด้วยสัญญา

DBC (Design by Contract) มาจาก Bertrand Meyer และภาษา Eiffel — เป็นเทคนิคที่ระบุว่า function หรือ method จะทำอะไรภายใต้เงื่อนไขอะไร โดยใช้สามองค์ประกอบ:

ปรัชญาของ DBC: "Be strict in what you will accept before you begin, and promise as little as possible in return."

Semantic Invariants: ข้อกำหนดที่ไม่สามารถละเมิดได้ เช่น "จะไม่มีทางที่ transaction จะถูก apply ซ้ำสองครั้ง" — ต้องเป็นส่วนหนึ่งของความหมายของระบบ ไม่ใช่แค่นโยบายที่เปลี่ยนได้

---

Topic 24: Dead Programs Tell No Lies — โปรแกรมที่ตายแล้วไม่โกหก

Tip 38: Crash Early — พังให้เร็ว

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

แนวคิดจาก Erlang/Elixir: "Defensive programming is a waste of time. Let it crash!" — ใช้ supervisors จัดการ failure — เมื่อ process ล้ม supervisor จะ restart หรือ clean up ให้ — สร้าง supervisor trees

อย่า: catch exception ทั้งหมดแล้ว re-raise — มันเพิ่มความซับซ้อนและ coupling โดยไม่จำเป็น แต่ให้: ปล่อยให้ exception propagate ตามธรรมชาติ

---

Topic 25: Assertive Programming — การเขียนโปรแกรมแบบ assert

Tip 39: Use Assertions to Prevent the Impossible — ใช้ assertions เพื่อป้องกันสิ่งที่เป็นไปไม่ได้

ทุกครั้งที่คุณคิดว่า "แต่นี่มันไม่มีทางเกิดขึ้นแน่นอน" — ให้เพิ่มโค้ดเพื่อตรวจสอบมัน Assertions ตรวจสอบสิ่งที่ควรจะเป็นจริงเสมอ — ไม่ใช่การจัดการ error ปกติ

ข้อควรระวัง:

• Assertions ต้องไม่มี side effects — การตรวจสอบไม่ควรเปลี่ยน state ของระบบ
• เปิด assertions ทิ้งไว้ใน production — การปิด assertions ตอน deploy คือการเดินไต่ลวดโดยไม่มีตาข่าย เพราะคุณเคยเดินผ่านมาแล้วในการซ้อม
• ปิดเฉพาะ assertions ที่กระทบ performance จริง ๆ

"Use Assertions in Production, Win Big Money" — startup ทำ network devices ที่เปิด assertions ทิ้งไว้ใน production ได้ feedback จากผู้ใช้จริงจนซอฟต์แวร์เสถียรมาก และถูกซื้อกิจการด้วยราคาหลายร้อยล้าน

---

Topic 26: How to Balance Resources — การจัดการทรัพยากร

Tip 40: Finish What You Start — ทำสิ่งที่เริ่มให้เสร็จ
Tip 41: Act Locally — กระทำเฉพาะที่

function หรือ object ที่ allocate resource ควรเป็นผู้ deallocate มัน — เปิดไฟล์ที่ไหน ปิดที่นั่น

รูปแบบที่ถูกต้อง:

thing = allocate_resource()
begin
  process(thing)
finally
  deallocate(thing)
end

ผิด: allocate อยู่ใน try block — ถ้า allocate ล้มเหลว finally จะพยายาม deallocate สิ่งที่ไม่มีอยู่

กฎการซ้อน allocations:

• deallocate ในลำดับย้อนกลับกับที่ allocate
• allocate ชุดทรัพยากรเดียวกันในลำดับเดียวกันเสมอ — ลดโอกาส deadlock

เมื่อ balance ไม่ได้ (เช่น dynamic data structures): กำหนด semantic invariant ว่าใครรับผิดชอบ deallocation — และต้องทำให้ชัดเจน สื่อสารให้รับรู้ และทำอย่างสม่ำเสมอ

---

Topic 27: Don't Outrun Your Headlights — อย่าวิ่งเร็วกว่าไฟหน้า

Tip 42: Take Small Steps—Always — ก้าวเล็ก ๆ เสมอ
Tip 43: Avoid Fortune-Telling — หลีกเลี่ยงการทำนายอนาคต

ไฟหน้ารถมีระยะส่องสว่างจำกัด — ถ้าคุณขับเร็วกว่าระยะที่มองเห็น คุณจะชนก่อนที่จะเบรกทัน ในการพัฒนาซอฟต์แวร์ "ไฟหน้า" ของเราก็จำกัดเช่นกัน — เรามองเห็นอนาคตได้แค่หนึ่งหรือสองก้าว ไม่กี่ชั่วโมงหรือไม่กี่วัน

Feedback คือ speed limit ของคุณ: unit tests, REPL results, user demos — ทุกอย่างที่ยืนยันหรือหักล้างการกระทำของคุณ

สิ่งที่เสี่ยงต่อการ "ทำนายอนาคต":

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

Black Swans (Nassim Taleb): เหตุการณ์ที่หายากแต่ส่งผลกระทบมหาศาล — ไม่มีใครเดาได้ (Motif vs OpenLook ในยุค 90s — ถามผิดคำถาม ไม่มีใคร "ชนะ" เพราะ browser-based web มากลบทุกอย่าง)

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