บทที่ 3: The Basic Tools — เครื่องมือพื้นฐาน
3 min readภาพรวม
เครื่องมือขยายความสามารถของคุณ — ยิ่งเครื่องมือดีและคุณรู้วิธีใช้มันมากเท่าไหร่ คุณก็ยิ่ง productive มากขึ้นเท่านั้น เริ่มจากชุดเครื่องมือพื้นฐาน แล้วเพิ่มตามความจำเป็น — อย่าติดอยู่ใน comfort zone ของ IDE เดียว
Topic 16: The Power of Plain Text — พลังของ Plain Text
Tip 25: Keep Knowledge in Plain Text — เก็บความรู้ใน plain text
Plain text คือข้อมูลที่อ่านได้โดยมนุษย์โดยตรง (human-readable) — ไม่ใช่ binary format หรือ markup ที่ซับซ้อน ข้อดี: ประกันการใช้งานได้ในอนาคต (ไม่มี legacy format lock-in), ใช้ประโยชน์จากเครื่องมือทั้งหมดที่ทำงานกับ text ได้ (source code control, diff, merge), และทดสอบได้ง่ายกว่า
"All software becomes legacy software as soon as it's written."
Topic 17: Shell Games — เปลือกหอย
Tip 26: Use the Power of Command Shells — ใช้พลังของ command shell
Command shell คือ workbench ของนักพัฒนา — จาก shell คุณสามารถใช้เครื่องมือทั้งหมด ต่อท่อ (pipe) ให้ทำงานร่วมกันในแบบที่นักออกแบบเครื่องมือไม่เคยคิดฝัน GUI มีข้อดีคือ WYSIWYG (What You See Is What You Get) แต่ข้อเสียคือ WYSIAYG (What You See Is All You Get)
ปรับแต่ง shell ของคุณ: ตั้ง color theme, ปรับ prompt, สร้าง aliases และ shell functions, ใช้ command completion
Topic 18: Power Editing — การใช้ editor อย่างเชี่ยวชาญ
Tip 27: Achieve Editor Fluency — เข้าถึงความคล่องแคล่วในการใช้ editor
เป้าหมายไม่ใช่แค่ประหยัดเวลา — แต่คือการที่การแก้ไข text กลายเป็นสัญชาตญาณ ระยะห่างระหว่างความคิดกับการพิมพ์ลดลงจนแทบเป็นศูนย์ ทำให้ความคิดไหลลื่น
ทักษะที่ควรทำได้โดยไม่ใช้เมาส์:
- เลื่อนและเลือกตามตัวอักษร, คำ, บรรทัด, ย่อหน้า
- เลื่อนตามหน่วย syntax (matching delimiters, functions, modules)
- reindent โค้ด, comment/uncomment blocks, undo/redo
- แยกหน้าต่าง editor เป็นหลาย panel
- ค้นหาด้วย string และ regular expressions
- ใช้ multiple cursors
- แสดง compilation errors และ run tests
วิธีพัฒนา: ทุกครั้งที่เจออะไรที่ทำซ้ำ ๆ — ให้คิดว่า "ต้องมีวิธีที่ดีกว่านี้" แล้วหาให้เจอ ทำซ้ำจนกลายเป็น muscle memory ขยาย editor ด้วย extensions และเรียนรู้ extension language เพื่อ automate งานที่ทำบ่อย ๆ
Topic 19: Version Control — ระบบควมคุมเวอร์ชัน
Tip 28: Always Use Version Control — ใช้ version control เสมอ
VCS คือปุ่ม undo ระดับโปรเจกต์ — เครื่องย้อนเวลาที่พาคุณกลับไปยังวันที่โค้ดยัง compile และ run ได้ ใช้กับทุกอย่าง: โค้ด, เอกสาร, phone number lists, memos, makefiles, build procedures, shell scripts — แม้แต่ข้อความในหนังสือเล่มนี้ก็อยู่ใน VCS
Branches: แยกการพัฒนาเป็นเกาะอิสระ — พัฒนาฟีเจอร์ A ใน branch หนึ่ง ไม่กระทบฟีเจอร์ B ในอีก branch — แล้ว merge กลับเมื่อพร้อม
VCS as Project Hub: เลือก hosting ที่มี features: security, intuitive UI, command-line support, automated builds/tests, pull requests, issue management, Kanban boards, team communications
Topic 20: Debugging — การดีบัก
Tip 29: Fix the Problem, Not the Blame — แก้ปัญหาอย่าโทษคน
Tip 30: Don't Panic — อย่าตกใจ
กฎข้อแรกของการดีบัก: อย่าตกใจ ถ้าปฏิกิริยาแรกของคุณคือ "มันเป็นไปไม่ได้" — คุณคิดผิด เพราะมันเกิดขึ้นแล้ว
Tip 31: Failing Test Before Fixing Code — เขียน test ที่ fail ก่อนแก้โค้ด
Tip 32: Read the Damn Error Message — อ่าน error message ให้ดีก่อน!
Tip 33: "select" Isn't Broken — OS ไม่ได้พัง — โค้ดคุณนั่นแหละ
Tip 34: Don't Assume It — Prove It — อย่าทึกทัก — พิสูจน์มัน
กลยุทธ์การดีบัก:
- Reproduce bug ด้วยคำสั่งเดียว (ไม่ใช่ 15 ขั้นตอน)
- Binary Chop: เมื่อต้องหาจุดผิดพลาดใน stacktrace ยาว ๆ — เริ่มตรวจที่ตรงกลางแล้วแบ่งครึ่งไปเรื่อย ๆ (O(log n) vs O(n))
- Logging/Tracing: ใช้ trace statements ในระบบที่เวลาเป็นปัจจัย (concurrent processes, real-time systems)
- Rubber Ducking: อธิบายปัญหาให้คนอื่นฟัง (หรือเป็ดยาง) — การอธิบายทีละขั้นทำให้ปัญหาลอยมาเอง
- Process of Elimination: ถ้าได้ยินเสียงกีบเท้า — คิดถึงม้าไม่ใช่ม้าลาย OS ไม่ได้พัง, compiler ไม่ได้พัง — โค้ดคุณนั่นแหละ
Debugging Checklist: มันเป็น root cause หรือแค่อาการ? bug อยู่ใน framework, OS, หรือโค้ดของคุณ? ถ้าอธิบายให้เพื่อนร่วมงานฟังจะพูดว่าอะไร? unit tests ครอบคลุมพอหรือยัง? มีที่อื่นในระบบที่อาจเกิด bug แบบเดียวกันอีกไหม?
Topic 21: Text Manipulation — การจัดการข้อความ
Tip 35: Learn a Text Manipulation Language — เรียนรู้ภาษา text manipulation สักหนึ่งภาษา
Text manipulation languages (เช่น awk, sed, Perl, Python, Ruby) เปรียบเสมือนเราเตอร์ของช่างไม้ — เสียงดัง, ยุ่งเหยิง, ค่อนข้าง brute force แต่ทรงพลังอย่างเหลือเชื่อเมื่อใช้ถูกวิธี ช่วยให้คุณทำ utility และ prototype ได้ในเวลาอันสั้น — 30 นาทีทดลองไอเดียบ้า ๆ ดีกว่า 5 ชั่วโมง
Topic 22: Engineering Daybooks — สมุดบันทึกของวิศวกร
Tip 36: Keep an Engineering Daybook — จดบันทึกแบบวิศวกร
วิศวกรไฟฟ้าและเครื่องกลพกสมุดบันทึกติดตัว — จดทุกอย่าง: สิ่งที่ทำ, สิ่งที่เรียนรู้, ภาพสเก็ตซ์ไอเดีย, ค่าที่วัดได้
ประโยชน์ของ daybook:
- น่าเชื่อถือกว่าความจำ
- เป็นที่เก็บไอเดียที่ไม่เกี่ยวกับงานตรงหน้า — ได้ concentrate ต่อโดยรู้ว่าไอเดียดี ๆ จะไม่หายไป
- เป็น rubber duck — เวลาหยุดเขียน สมองอาจเปลี่ยนเกียร์และค้นพบว่าสิ่งที่กำลังทำนั้นผิด
ใช้กระดาษ — ไม่ใช่ไฟล์หรือ wiki — มีอะไรพิเศษในการเขียนด้วยมือ