ความเชื่อเดิมๆ มักบอกว่าพอโปรเจกต์เข้าสู่ช่วง 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 ก็เหมือนกันครับ—มันอาจจะเป็นงานรูทีนส่วนใหญ่ แต่การมีสติคอยสังเกตสิ่งรอบตัวอยู่เสมออาจช่วยป้องกันไม่ให้เกิดหายนะได้