Topic 3: Software Entropy

แม้ว่าการพัฒนาซอฟต์แวร์จะไม่ถูกจำกัดโดยกฎทางฟิสิกส์เกือบทั้งหมด แต่การเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้ของ เอนโทรปี (Entropy) ก็ส่งผลกระทบกับเราอย่างหนักครับ เอนโทรปี เป็นคำศัพท์ทางฟิสิกส์ที่หมายถึงปริมาณ “ความไร้ระเบียบ” ในระบบหนึ่งๆ น่าเสียดายที่กฎทางอุณหพลศาสตร์รับประกันว่าเอนโทรปีในเอกภพมีแนวโน้มเพิ่มขึ้นสู่ค่าสูงสุดเสมอ เมื่อความไร้ระเบียบในซอฟต์แวร์เพิ่มขึ้น เราเรียกมันว่า “Software Rot” บางคนอาจเรียกมันด้วยคำที่ดูมองโลกในแง่ดีกว่า อย่าง “Technical Debt” โดยแฝงนัยว่าสักวันหนึ่งพวกเขาจะชดใช้มันคืน แต่ในความเป็นจริงพวกเขาก็คงไม่ทำแบบนั้นหรอกครับ

ไม่ว่าจะเรียกมันว่าอะไรก็ตาม ทั้ง Debt และ Rot ต่างก็ลุกลามได้แบบควบคุมไม่อยู่ครับ

มีหลายปัจจัยที่ทำให้ซอฟต์แวร์เสื่อมสภาพได้ ปัจจัยที่สำคัญที่สุดดูเหมือนจะเป็นเรื่องจิตวิทยา หรือวัฒนธรรมการทำงานในโปรเจกต์นั้นๆ แม้ว่าคุณจะทำงานคนเดียวในทีม จิตวิทยาของโปรเจกต์ก็ยังเป็นเรื่องละเอียดอ่อนมาก ต่อให้วางแผนมาดีแค่ไหน มีคนเก่งแค่ไหน โปรเจกต์ก็ยังสามารถพังทลายและเสื่อมโทรมลงได้ตลอดช่วงชีวิตของมัน ในขณะเดียวกัน ก็มีโปรเจกต์อื่นๆ ที่แม้จะเจอความยากลำบากมหาศาลและอุปสรรครายทางไม่หยุดหย่อน แต่ก็ยังต่อสู้กับแนวโน้มตามธรรมชาติที่จะไร้ระเบียบได้สำเร็จ และจบลงได้อย่างดีครับ

อะไรคือสิ่งที่สร้างความแตกต่าง

ในเขตเมืองชั้นใน อาคารบางหลังสวยงามและสะอาดตา ในขณะที่อาคารอื่นกลับทรุดโทรมจนแทบใช้การไม่ได้ ทำไมถึงเป็นแบบนั้น นักวิจัยในสาขาอาชญากรรมและความเสื่อมโทรมของเมืองค้นพบกลไกกระตุ้นที่น่าสนใจอย่างหนึ่ง ซึ่งสามารถเปลี่ยนอาคารที่สะอาด สมบูรณ์ และมีคนอาศัยอยู่ ให้กลายเป็นซากปรักหักพังที่ถูกทิ้งร้างได้อย่างรวดเร็ว [5]

หน้าต่างที่แตกบานหนึ่ง

หน้าต่างที่แตกเพียงบานเดียว หากปล่อยทิ้งไว้โดยไม่ซ่อมแซมเป็นเวลานานพอสมควร จะปลูกฝังความรู้สึกถูกทอดทิ้งให้กับผู้ที่อาศัยอยู่ในอาคารนั้น—ความรู้สึกว่าผู้มีอำนาจไม่สนใจอาคารหลังนี้อีกต่อไป แล้วหน้าต่างบานอื่นก็จะแตกตามมา ผู้คนเริ่มทิ้งขยะเกลื่อนกลาด กราฟฟิตี้เริ่มปรากฏ ความเสียหายเชิงโครงสร้างที่รุนแรงก็เริ่มขึ้น ในเวลาไม่นานนัก อาคารก็เสียหายจนเกินกว่าที่เจ้าของจะอยากซ่อมแซม และความรู้สึกถูกทอดทิ้งก็กลายเป็นความจริงครับ

ทำไมเรื่องนี้ถึงสร้างความแตกต่างได้ นักจิตวิทยาได้ทำการศึกษา [6] ที่แสดงให้เห็นว่าความสิ้นหวังสามารถแพร่กระจายได้เหมือนโรคติดต่อ ลองนึกถึงเชื้อไวรัสไข้หวัดใหญ่ในพื้นที่แออัดดูสิครับ การเพิกเฉยต่อสถานการณ์ที่เห็นได้ชัดว่าพังแล้ว จะยิ่งตอกย้ำความคิดที่ว่าบางที ไม่มีอะไร ที่จะแก้ไขได้เลย ไม่มีใครสนใจ ทุกอย่างถึงคราวจบสิ้น—ความคิดในแง่ลบเหล่านี้สามารถแพร่กระจายไปในหมู่สมาชิกทีม จนกลายเป็นวงจรอุบาทว์

อย่าปล่อยให้ “หน้าต่างที่แตก” (การออกแบบที่ไม่ดี การตัดสินใจที่ผิดพลาด หรือโค้ดที่ห่วย) ค้างไว้โดยไม่ซ่อมแซม จงแก้ไขมันทันทีที่พบเจอ ถ้าไม่มีเวลาพอที่จะซ่อมมันให้ถูกต้องจริงๆ ก็ ปิดกั้นมันไว้ก่อน บางทีคุณอาจ Comment โค้ดที่มีปัญหาออกไป หรือแสดงข้อความ “Not Implemented” หรือใช้ข้อมูลจำลองแทนก็ได้ ทำ อะไรสักอย่าง เพื่อป้องกันความเสียหายเพิ่มเติม และแสดงให้เห็นว่าคุณกำลังควบคุมสถานการณ์อยู่ครับ

เราเคยเห็นระบบที่สะอาดและใช้งานได้ดีเสื่อมสภาพลงอย่างรวดเร็วทันทีที่หน้าต่างเริ่มแตก ยังมีปัจจัยอื่นๆ ที่ทำให้ซอฟต์แวร์เสื่อมสภาพได้ และเราจะพูดถึงบางส่วนในที่อื่น แต่การเพิกเฉย เร่ง ให้เกิดการเสื่อมสภาพเร็วกว่าปัจจัยอื่นใดทั้งสิ้นครับ

คุณอาจกำลังคิดว่าไม่มีใครมีเวลาไปเก็บกวาดเศษกระจกที่แตกทั่วทั้งโปรเจกต์หรอก ถ้าคิดแบบนั้น คุณก็ควรวางแผนหาถังขยะขนาดใหญ่มาไว้ หรือไม่ก็ย้ายไปอยู่ย่านอื่นเลยดีกว่า อย่าปล่อยให้เอนโทรปีชนะครับ

First, Do No Harm (ข้อแรก อย่าสร้างความเสียหายเพิ่ม)

Andy เคยมีคนรู้จักที่รวยล้นฟ้า บ้านของเขาสะอาดหมดจด เต็มไปด้วยของเก่าล้ำค่าและ ของสะสมทางศิลปะ มากมาย วันหนึ่ง ผ้าทอผนังที่แขวนอยู่ใกล้เตาผิงเกินไปหน่อยก็เกิดไฟไหม้ขึ้นมา หน่วยดับเพลิงรีบมาถึงเพื่อกอบกู้สถานการณ์—และบ้านของเขาไว้ แต่ก่อนที่พวกเขาจะลากสายยางขนาดใหญ่ที่เปื้อนสกปรกเข้าไปในบ้าน พวกเขาหยุดก่อน—ทั้งที่ไฟยังลุกโชนอยู่—เพื่อปูเสื่อรองพื้นระหว่างประตูหน้ากับจุดที่ไฟไหม้

พวกเขาไม่อยากทำให้พรมเลอะเทอะครับ

ฟังดูอาจจะสุดโต่งไปหน่อย แน่นอนว่าความสำคัญอันดับแรกของหน่วยดับเพลิงคือการดับไฟ ต่อให้ต้องมีความเสียหายอื่นๆ ตามมาก็ตาม แต่พวกเขาประเมินสถานการณ์อย่างชัดเจน มั่นใจในความสามารถของตัวเองที่จะควบคุมไฟได้ และระมัดระวังไม่สร้างความเสียหายเพิ่มเติมโดยไม่จำเป็นต่อทรัพย์สิน ซอฟต์แวร์ก็ต้องเป็นแบบนั้นเช่นกัน อย่าสร้างความเสียหายเพิ่มแค่เพราะมันกำลังมีวิกฤตอะไรสักอย่างเกิดขึ้น หน้าต่างที่แตกแม้แต่บานเดียวก็มากเกินไปแล้วครับ

หน้าต่างที่แตกเพียงบานเดียว—โค้ดที่ออกแบบมาไม่ดี หรือการตัดสินใจของฝ่ายบริหารที่ไม่ดีซึ่งทีมต้องทนอยู่กับมันตลอดช่วงชีวิตของโปรเจกต์—ก็เพียงพอแล้วที่จะเริ่มต้นความเสื่อมถอย ถ้าคุณพบว่าตัวเองกำลังทำงานในโปรเจกต์ที่มีหน้าต่างแตกอยู่หลายบาน มันง่ายมากที่จะหลุดเข้าไปในความคิดแบบ “โค้ดที่เหลือทั้งหมดมันก็ห่วยอยู่แล้ว งั้นผมก็ทำตามๆ กันไปก็แล้วกัน” ไม่สำคัญเลยว่าโปรเจกต์จะโอเคมาตลอดจนถึงจุดนี้หรือไม่ ในการทดลองดั้งเดิมที่นำไปสู่ “ทฤษฎีหน้าต่างแตก” รถที่ถูกทิ้งร้างคันหนึ่งจอดอยู่เฉยๆ เป็นเวลาหนึ่งสัปดาห์โดยไม่มีใครแตะต้อง แต่ทันทีที่มีกระจกบานหนึ่งแตก รถคันนั้นก็ถูกรื้อชิ้นส่วนและถูกพลิกคว่ำภายใน ไม่กี่ชั่วโมง .

ในทางกลับกัน ถ้าคุณอยู่ในโปรเจกต์ที่โค้ดสวยงามไร้ที่ติ—เขียนมาอย่างสะอาด ออกแบบมาดี และสง่างาม—คุณก็มีแนวโน้มที่จะระมัดระวังเป็นพิเศษไม่ให้มันเลอะเทอะ เหมือนกับนักดับเพลิงนั่นแหละครับ ถึงแม้จะมีไฟลุกโชนอยู่ (Deadline วันเปิดตัว การสาธิตในงานแสดงสินค้า ฯลฯ) คุณ ก็ไม่อยากเป็นคนแรกที่ทำให้มันเลอะเทอะและสร้างความเสียหายเพิ่มเติม

แค่บอกตัวเองว่า “ห้ามมีหน้าต่างแตก”

Related Sections Include (หัวข้อที่เกี่ยวข้อง)

• Topic 10, ​ Orthogonality ​
• Topic 40, ​ Refactoring ​
• Topic 44, ​ Naming Things ​

Challenges (แบบฝึกหัดชวนคิด)

• ช่วยเสริมความแข็งแกร่งให้ทีมของคุณด้วยการสำรวจ “ย่าน” ของโปรเจกต์คุณดูครับ เลือกหน้าต่างที่แตกสักสองสามบาน แล้วพูดคุยกับเพื่อนร่วมทีมว่าปัญหาคืออะไร และจะแก้ไขมันได้อย่างไรบ้าง

• คุณสังเกตออกไหมว่าหน้าต่างเริ่มแตกตั้งแต่ตอนไหน แล้วปฏิกิริยาของคุณเป็นอย่างไร ถ้ามันเป็นผลจากการตัดสินใจของคนอื่น หรือคำสั่งจากฝ่ายบริหาร คุณจะทำอะไรกับมันได้บ้าง