ความเชื่อเดิมๆ มักบอกว่าพอโปรเจกต์เข้าสู่ช่วง Coding แล้ว งานที่เหลือก็แค่ทำตามกลไกไปเรื่อยๆ คือการเปลี่ยน Design ให้กลายเป็นคำสั่งที่รันได้จริง เรามองว่าทัศนคติแบบนี้แหละคือสาเหตุหลักที่ทำให้ซอฟต์แวร์ล้มเหลว และทำให้หลายระบบออกมาดูแย่ ไม่มีประสิทธิภาพ โครงสร้างพัง แก้ไขต่อไม่ได้ หรือถึงขั้นทำงานผิดพลาดไปเลย
Coding ไม่ใช่เรื่องของกลไกเฉยๆ หรอก ถ้ามันใช่จริง เครื่องมือ CASE tools ทั้งหลายที่คนเคยฝากความหวังไว้ตั้งแต่ช่วงต้นยุค 80 ก็คงมาแทนที่ Programmer กันไปนานแล้ว ในทุกๆ นาทีมีเรื่องให้ต้องตัดสินใจเสมอ ซึ่งการตัดสินใจเหล่านี้แหละที่ต้องใช้การคิดและวิจารณญาณอย่างรอบคอบ เพื่อให้ซอฟต์แวร์ของเรามีอายุการใช้งานที่ยาวนาน ถูกต้อง และสร้างมูลค่าได้จริง
บางครั้งเราตัดสินใจไปโดยไม่ทันรู้ตัวด้วยซ้ำ คุณสามารถดึงสัญชาตญาณและความคิดลึกๆ มาใช้ได้ดีขึ้นเมื่ออ่าน Topic 37, Listen to Your Lizard Brain เราจะได้เรียนรู้วิธีรับฟังให้ดีขึ้น และหาวิธีตอบสนองต่อความคิดเล็กๆ น้อยๆ ที่คอยกวนใจเราอยู่เสมอ
แต่การฟังเสียงสัญชาตญาณไม่ได้หมายความว่าคุณจะปล่อยให้ตัวเองรันแบบ autopilot ได้นะ Developer ที่ไม่ยอมคิดทบทวนสิ่งที่ตัวเองกำลังเขียนมักจะ "Programming by Coincidence" หรือการเขียนโปรแกรมโดยบังเอิญ—คือโค้ดอาจจะรันได้แหละ แต่ไม่รู้หรอกว่าทำไมมันถึงรันได้ ใน Topic 38, Programming by Coincidence เราจะแนะนำให้คุณเข้ามามีส่วนร่วมกับกระบวนการเขียนโค้ดอย่างจริงจังมากขึ้น
ถึงแม้โค้ดส่วนใหญ่ที่เราเขียนจะทำงานได้เร็ว แต่บางครั้งเราก็อาจจะสร้าง Algorithm ที่ทำให้แม้แต่ Processor ที่เร็วที่สุดยังต้องอืดได้ ใน Topic 39, Algorithm Speed เราจะพูดถึงวิธีการประมาณความเร็วของโค้ด และให้เทคนิคในการตรวจจับปัญหาที่อาจเกิดขึ้นก่อนที่มันจะสายเกินไป
Pragmatic Programmer จะคิดอย่างมีวิจารณญาณกับโค้ดทุกชุด รวมถึงโค้ดที่ตัวเองเขียนด้วย เรามักจะเห็นช่องทางในการพัฒนาโปรแกรมและ Design ของเราให้ดีขึ้นได้เสมอ ใน Topic 40, Refactoring เราจะมาดูเทคนิคที่ช่วยให้เราปรับปรุงโค้ดเดิมที่มีอยู่ได้อย่างต่อเนื่องในขณะที่ทำงาน
การ Test ไม่ใช่แค่เรื่องของการหาบั๊ก แต่มันคือการรับ Feedback เกี่ยวกับโค้ดของคุณ ไม่ว่าจะเป็นเรื่อง Design, API, การเกิด Coupling และอื่นๆ นั่นหมายความว่าประโยชน์สูงสุดของการ Test เกิดขึ้นตอนที่คุณ "คิด" และ "เขียน" ชุดทดสอบ ไม่ใช่แค่ตอนที่รันมัน เราจะไปสำรวจแนวคิดนี้กันใน Topic 41, Test to Code
แต่แน่นอนว่าเวลาคุณทดสอบโค้ดตัวเอง คุณอาจจะมีความลำเอียง (Bias) ติดไปด้วย ใน Topic 42, Property-Based Testing เราจะมาดูกันว่าเราจะใช้คอมพิวเตอร์ช่วยทดสอบให้ครอบคลุมในหลายๆ แง่มุมได้อย่างไร และจะจัดการกับบั๊กที่หนีไม่พ้นเหล่านั้นได้อย่างไร
มันสำคัญมากที่คุณต้องเขียนโค้ดที่อ่านง่ายและทำความเข้าใจได้ไม่ยาก โลกภายนอกมันโหดร้าย เต็มไปด้วยผู้ประสงค์ร้ายที่คอยหาช่องทางเจาะระบบและสร้างความเสียหาย เราจะมาคุยกันถึงเทคนิคพื้นฐานและแนวทางที่จะช่วยให้คุณ Topic 43, Stay Safe Out There ได้ดียิ่งขึ้น
สุดท้าย หนึ่งในเรื่องที่ยากที่สุดของการพัฒนาซอฟต์แวร์ก็คือ Topic 44, Naming Things หรือการตั้งชื่อนั่นเอง เราต้องตั้งชื่อสิ่งต่างๆ มากมาย และในหลายๆ แง่ ชื่อที่เราเลือกก็เป็นตัวกำหนดนิยามของสิ่งที่เราสร้างขึ้นมา คุณต้องคอยระวังเรื่องการเปลี่ยนแปลงความหมาย (Semantic drift) ที่อาจเกิดขึ้นในระหว่างที่คุณ Coding อยู่เสมอ
พวกเราส่วนใหญ่ขับรถกันแบบแทบจะเป็น autopilot คือไม่ได้สั่งให้เท้าเหยียบคันเร่งหรือสั่งให้แขนหมุนพวงมาลัยชัดเจน เราแค่คิดว่า "ชะลอรถแล้วเลี้ยวขวา" อย่างไรก็ตาม คนขับรถที่ดีและปลอดภัยจะหมั่นประเมินสถานการณ์ คอยเช็กปัญหาที่อาจเกิดขึ้น และเตรียมตัวให้พร้อมเสมอเผื่อเกิดเหตุไม่คาดฝัน การ Coding ก็เหมือนกันครับ—มันอาจจะเป็นงานรูทีนส่วนใหญ่ แต่การมีสติคอยสังเกตสิ่งรอบตัวอยู่เสมออาจช่วยป้องกันไม่ให้เกิดหายนะได้