การสร้างซอฟต์แวร์อาจให้ความรู้สึกเหมือนการแสดงบนเวทีสาธารณะ อินเทอร์เน็ตมักจะให้รางวัลกับการเปิดตัว (launches), ภาพสกรีนช็อต และรายการการเปลี่ยนแปลง (changelog) ดังนั้น เมื่อนักพัฒนาใช้เวลาทั้งวันไปกับโปรเจกต์หนึ่งแต่ไม่มีอะไรที่มองเห็นได้มาแสดงให้ดู สัญชาตญาณแรกคือการคิดว่าวันนั้นเสียเปล่า บันทึกการพัฒนา (dev log) ล่าสุดจาก Food Blog Platform พิสูจน์ให้เห็นในทางตรงกันข้าม ไม่มีการแสดงสูตรอาหารใหม่ๆ ไม่มีการออกแบบการ์ดใหม่ ไม่มีการเพิ่มปุ่มให้ผู้ใช้คลิก มีเพียงโค้ดที่ถูกแยกส่วน ตรวจสอบ และประกอบกลับเข้าไปใหม่ให้ดีกว่าเดิม
นี่คืองานที่มองไม่เห็นซึ่งช่วยให้โปรเจกต์ระยะยาวดำเนินต่อไปได้
ฟีเจอร์คือสิ่งที่สร้างชื่อเสียง แต่การ Refactoring คือสิ่งที่ทำให้ระบบยังคงดำเนินต่อไปได้
เมื่อคุณดูแลแพลตฟอร์มบล็อกอาหาร พื้นผิวภายนอกดูเหมือนจะเรียบง่าย ผู้ใช้โพสต์สูตรอาหาร อัปโหลดรูปภาพ และเลือกดูตามหมวดหมู่ แต่ภายใต้พื้นผิวนั้น คุณกำลังจัดการกับ image pipelines, ความสัมพันธ์ของฐานข้อมูลระหว่างวัตถุดิบและวิธีทำ, search indexes และ caching layers เมื่อเวลาผ่านไป การแก้ไขปัญหาเฉพาะหน้า (quick fixes) ก็จะสะสมมากขึ้นเรื่อยๆ เช่น ฟังก์ชันช่วยเหลือ (helper function) ที่ถูกคัดลอกไปไว้ในสามไฟล์ที่ต่างกัน, คำสั่ง query ฐานข้อมูลที่เคยใช้งานได้ดีเมื่อมีแค่สิบโพสต์ แต่กลับทำงานช้าอืดอาดเมื่อมีถึงหนึ่งพันโพสต์ หรือ CSS ที่เคยจัดระเบียบไว้อย่างดีจนกระทั่งการแก้ไขฉุกเฉินห้าครั้งทำให้มันกลายเป็นเขาวงกต
การ Refactoring หมายถึงการเผชิญหน้ากับความยุ่งเหยิงเหล่านั้นโดยตรง มันอาจหมายถึงการรวม logic ที่ซ้ำซ้อนเข้าด้วยกัน เพื่อให้ฟอร์มแก้ไขสูตรอาหารและแดชบอร์ดของผู้ดูแลระบบดึงข้อมูลจาก validation layer เดียวกัน แทนที่จะต้องดูแลเวอร์ชันที่แยกจากกัน มันอาจหมายถึงการทำให้กระบวนการจัดการรูปภาพง่ายขึ้น เพื่อให้ขั้นตอนการบีบอัด (compression routine) ทำงานเพียงครั้งเดียว แทนที่จะทำงานทุกครั้งที่โหลดหน้าเว็บใหม่ หรืออาจเป็นการปรับโครงสร้าง codebase เพื่อให้การเพิ่มประเภทเนื้อหาใหม่ในภายหลังไม่จำเป็นต้องไล่หาตามไดเรกทอรีที่ไม่เกี่ยวข้องกันถึงหกแห่ง
สิ่งเหล่านี้ไม่มีปรากฏในส่วนติดต่อผู้ใช้ (user interface) ผู้เยี่ยมชมที่เข้ามาในเว็บไซต์จะไม่เห็นแบนเนอร์ที่เขียนว่า "query optimized" หรือ "component decoupled" แต่พวกเขาจะรู้สึกได้เมื่อเว็บไซต์โหลดเร็วขึ้น พวกเขาจะสังเกตเห็นเมื่อฟีเจอร์ใหม่ปรากฏขึ้นภายในสามวันหลังจากที่มีการร้องขอ แทนที่จะเป็นสามสัปดาห์ นักพัฒนาไม่ได้เพิ่มความสามารถใหม่ๆ ในวันนี้ แต่พวกเขาได้เคลียร์เส้นทางเพื่อให้สามารถเพิ่มความสามารถเหล่านั้นได้โดยไม่ต้องต่อสู้กับ codebase
Clean Code คือการลงทุนเพื่อป้องกันความล้มเหลวในอนาคต
ทุกโปรเจกต์ที่ดำเนินมานานกว่าหนึ่งเดือนจะเกิดแรงเสียดทานสะสม คุณสร้างต้นแบบ (prototype) อย่างรวดเร็วเพื่อทดสอบไอเดีย จากนั้นผู้ใช้ก็เริ่มเข้ามาจริงๆ จากนั้นคุณก็ต้องการชั้นการยืนยันตัวตน (authentication layer), คิวสำหรับการตรวจสอบเนื้อหา (moderation queue) และเลย์เอาต์สำหรับมือถือ การเพิ่มสิ่งเหล่านี้แต่ละอย่างจะถูกนำไปต่อเติมเข้ากับโครงสร้างที่มีอยู่เดิม หากไม่มีการบำรุงรักษาอย่างสม่ำเสมอ สถาปัตยกรรมจะเริ่มดูเหมือนบ้านที่ห้องใหม่แต่ละห้องถูกออกแบบโดยคนละคนกัน ซึ่งไม่เคยเห็นแปลนบ้านมาก่อนเลย
หนี้ทางเทคนิค (Technical debt) ไม่ใช่ความล้มเหลวของวินัย แต่มันคือผลพลอยได้ตามธรรมชาติจากการตัดสินใจเลือก (trade-offs) เพื่อให้สามารถส่งมอบงานที่ใช้งานได้จริง ความอันตรายไม่ใช่การที่โค้ดของคุณไม่สมบูรณ์แบบ แต่ความอันตรายคือการปล่อยให้มันไม่สมบูรณ์แบบนานเกินไปจนการเปลี่ยนตัวแปรเพียงตัวเดียวกลับทำให้ฟีเจอร์อื่นที่ไม่เกี่ยวข้องกันถึงสามอย่างพังลง คุณจะพบว่าตัวเองไม่กล้าแตะต้องแถบค้นหา เพราะครั้งล่าสุดที่ลองทำ ระบบแท็กก็พัง คุณเลื่อนการเพิ่ม widget วางแผนมื้ออาหารออกไป เพราะรู้ว่า schema ของฐานข้อมูลกลายเป็นปมที่ต้องใช้เวลาหลายชั่วโมงในการแก้
การใช้เวลาหนึ่งวันในการ Refactoring ก็เหมือนกับการทยอยชำระหนี้นั้นก่อนที่ดอกเบี้ยจะท่วมตัว มันช่วยป้องกันไม่ให้ปัญหาเล็กๆ กลายเป็นปัญหาใหญ่ เมื่อ Food Blog Platform เพิ่มฟีเจอร์หลักครั้งต่อไป นักพัฒนาจะไม่ต้องคอยหลบเลี่ยงโค้ดที่เปราะบาง พวกเขาจะเขียน logic ใหม่ เชื่อมต่อเข้ากับ interface ที่สะอาด และก้าวต่อไป นั่นคือผลตอบแทนจากการลงทุน (return on investment)
ก้าวเล็กๆ คือการเรียนรู้ที่แท้จริง
มีตำนานเกี่ยวกับโลกของการพัฒนาซอฟต์แวร์ที่บอกว่าความก้าวหน้าต้องดูเหมือนการค้นพบที่อัจฉริยะ หรือการเขียนโค้ดมาราธอนที่เขียนทุกอย่างใหม่ข้ามคืน แต่นักพัฒนาที่ทำงานจริงส่วนใหญ่จะบอกคุณว่านั่นคือเรื่องเพ้อฝัน ความก้าวหน้าที่แท้จริงดูเหมือนความแตกต่าง (diff) ในบ่ายวันอังคารที่ฟังก์ชันสามตัวสั้นลง, dependency ที่ซ้ำซ้อนหนึ่งอย่างถูกลบออก และชื่อตัวแปรที่ชวนสับสนถูกเปลี่ยนเพื่อให้ผู้อ่านคนถัดไปเข้าใจได้จริงๆ ว่ามันทำหน้าที่อะไร
บันทึกการพัฒนาของ Food Blog Platform จับจังหวะนี้ได้อย่างสมบูรณ์แบบ การสร้างซอฟต์แวร์คือเรื่องของการปรับปรุงอย่างสม่ำเสมอและทีละเล็กทีละน้อย คุณเรียนรู้จากทุกความท้าทาย บางทีวันนี้ความท้าทายคือการทำความเข้าใจว่าทำไมโมดูลหนึ่งถึงต้องพึ่งพาอีกโมดูลหนึ่งมากขนาดนั้น บางทีมันคือการตระหนักว่าทางลัดที่เลือกใช้เมื่อสองสัปดาห์ก่อนเริ่มทำให้เสียเวลามากกว่าที่ประหยัดไป ทุกๆ commit ทำให้โปรเจกต์ดีขึ้น แม้ว่า commit นั้นจะลบมากกว่าที่สร้างขึ้นก็ตาม
This approach also protects your motivation. Massive rewrites are exhausting and risky. They introduce new bugs while solving old ones. Incremental refactoring, done