บทที่ 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 มีอะไรพิเศษในการเขียนด้วยมือ