ริช ฮิคกีย์และ Clojure: ความเรียบง่าย ความไม่เปลี่ยนแปลง และค่าเริ่มต้นที่ดีกว่า

ทำไมความซับซ้อนจึงชนะในโปรเจกต์จริง\n\nซอฟต์แวร์ไม่ค่อยซับซ้อนทันทีในครั้งเดียว มันกลายเป็นเช่นนั้นจากการตัดสินใจ "สมเหตุสมผล" ทีละเรื่อง: แคชเล็ก ๆ เพื่อให้ทันกำหนดเวลา, วัตถุที่เปลี่ยนแปลงได้ร่วมกันเพื่อหลีกเลี่ยงการคัดลอก, ข้อยกเว้นกฎเพราะ "อันนี้พิเศษ" แต่ละตัวเลือกดูเหมือนเล็กน้อย แต่รวมกันแล้วจะสร้างระบบที่การเปลี่ยนแปลงรู้สึกเสี่ยง บั๊กยากต่อการทำซ้ำ และการเพิ่มฟีเจอร์เริ่มใช้เวลานานกว่าการพัฒนา\n\nความซับซ้อนชนะเพราะมันให้ความสบายระยะสั้น มักจะเร็วกว่าในการเสียบ dependency ใหม่มากกว่าการทำให้สิ่งที่มีอยู่เรียบง่ายขึ้น ง่ายกว่าที่จะแก้ไขสถานะมากกว่าการถามว่าทำไมสถานะถึงกระจายอยู่ในห้าบริการ และมันน่าหยิบยืมความรู้ด้วยประเพณีเมื่อระบบเติบโตเร็วกว่าการจัดเอกสาร\n\n### บทความนี้คืออะไร (และไม่ใช่อะไร)\n\nนี่ไม่ใช่บทแนะนำ Clojure และคุณไม่จำเป็นต้องรู้ Clojure เพื่อให้ได้ประโยชน์ เป้าหมายคือยืมชุดแนวคิดปฏิบัติที่มักเกี่ยวข้องกับงานของ Rich Hickey—แนวคิดที่คุณสามารถนำไปใช้กับการตัดสินใจวิศวกรรมประจำวันได้ โดยไม่จำกัดภาษา\n\n### ทำไมค่าเริ่มต้นจึงสำคัญกว่าที่คุณคิด\n\nความซับซ้อนส่วนใหญ่ไม่ได้สร้างจากโค้ดที่คุณตั้งใจเขียน มันเกิดจากสิ่งที่เครื่องมือของคุณทำให้สะดวกโดยค่าเริ่มต้น ถ้าค่าเริ่มต้นคือ "วัตถุที่เปลี่ยนแปลงได้ทุกที่" คุณจะจบด้วยการผูกมัดแบบลับ ๆ ถ้าค่าเริ่มต้นคือ "สถานะอยู่ในหน่วยความจำ" คุณจะมีปัญหาเรื่องดีบักและการติดตามต้นตอ ค่าเริ่มต้นกำหนดนิสัย และนิสัยกำหนดระบบ\n\nเราจะมุ่งไปที่สามธีม:\n\n- ความเรียบง่าย: ไม่ใช่ฟีเจอร์น้อยลง แต่ชิ้นส่วนเคลื่อนที่น้อยลงและกรณีพิเศษน้อยลง\n- ความไม่เปลี่ยนแปลง: การปฏิบัติต่อข้อมูลเป็นค่าที่ไม่เปลี่ยน เพื่อให้คุณสามารถอธิบายได้ง่ายขึ้น\n- ค่าเริ่มต้นที่ดีกว่า: เลือกแนวทางที่ทำให้ตัวเลือกที่ปลอดภัยและคาดเดาได้เป็นทางเลือกที่ง่ายที่สุด\n\nแนวคิดเหล่านี้ไม่ทำให้ความซับซ้อนในโดเมนของคุณหายไป แต่สามารถหยุดซอฟต์แวร์ไม่ให้เพิ่มความซับซ้อนให้มากขึ้น\n\n## Rich Hickey และสิ่งที่ Clojure มาตั้งใจแก้\n\nRich Hickey เป็นนักพัฒนาซอฟต์แวร์และผู้ออกแบบที่มีประสบการณ์ยาวนาน เป็นที่รู้จักจากการสร้าง Clojure และการบรรยายที่ท้าทายนิสัยการเขียนโปรแกรมทั่วไป จุดสนใจของเขาไม่ใช่ตามเทรนด์ แต่เป็นสาเหตุซ้ำ ๆ ที่ทำให้ระบบยากต่อการเปลี่ยนแปลง ยากต่อการคิด และยากจะไว้วางใจเมื่อระบบเติบโต\n\n### Clojure คืออะไร (ในภาพรวม แบบไม่ใช้ศัพท์ลึก)\n\nClojure เป็นภาษาการเขียนโปรแกรมสมัยใหม่ที่รันบนแพลตฟอร์มที่เป็นที่รู้จักเช่น JVM (runtime ของ Java) และ JavaScript ถูกออกแบบให้ทำงานร่วมกับระบบนิเวศที่มีอยู่ในขณะเดียวกันก็ส่งเสริมสไตล์เฉพาะ: แทนข้อมูลเป็นข้อมูลธรรมดา, ให้ความสำคัญกับค่าที่ไม่เปลี่ยนแปลง และแยก "สิ่งที่เกิดขึ้น" ออกจาก "สิ่งที่แสดงบนหน้าจอ"

\nคุณสามารถคิดว่ามันเป็นภาษาที่ส่งเสริมให้คุณใช้บล็อกที่ชัดเจนและหลีกเลี่ยงผลข้างเคียงที่ซ่อนอยู่\n\n### ปัญหาที่มันต้องการลดลง\n\nClojure ไม่ได้ถูกสร้างมาเพื่อทำให้สคริปต์เล็ก ๆ สั้นลง แต่มุ่งที่ความเจ็บปวดซ้ำ ๆ ในโปรเจกต์:\n\n- : เมื่อหลายส่วนของระบบสามารถแก้ไขข้อมูลเดียวกันได้ บั๊กจะขึ้นกับจังหวะเวลาและยากต่อการทำซ้ำ\n- : เมื่อข้อมูลถูกล็อกไว้ภายในอ็อบเจ็กต์หรือคลาส การนำกลับมาใช้ใหม่ยากขึ้นและการเปลี่ยนแปลงส่งผลกระทบทั่วโค้ดเบส\n- : เมื่อระบบเพิ่มงานแบ็กกราวด์ คิว และงานขนาน คำถามว่า "ใครเปลี่ยนอะไร เมื่อไร" จะเป็นปัญหารายวัน\n\nค่าเริ่มต้นของ Clojure ผลักดันไปทางชิ้นส่วนเคลื่อนที่น้อยลง: โครงสร้างข้อมูลที่มั่นคง, การอัปเดตที่ชัดเจน, และเครื่องมือที่ทำให้การประสานงานปลอดภัยขึ้น\n\n### มีประโยชน์ถึงแม้คุณจะไม่ย้ายไปใช้ Clojure\n\nคุณค่าไม่ได้จำกัดอยู่ที่การเปลี่ยนภาษา แนวคิดสำคัญของ Hickey—ทำให้เรียบง่ายโดยการลดการพึ่งพาที่ไม่จำเป็น, ปฏิบัติต่อข้อมูลเป็นข้อเท็จจริงที่คงทน, และลดสถานะที่เปลี่ยนแปลงได้—สามารถปรับปรุงระบบใน Java, Python, JavaScript และภาษาอื่น ๆ ได้เช่นกัน\n\n## ความเรียบง่าย: ไม่ใช่ "ง่าย" แต่ชิ้นส่วนเคลื่อนที่น้อยลง\n\nRich Hickey แยกเส้นที่ชัดเจนระหว่าง และ — และนี่เป็นเส้นที่หลายโปรเจกต์ข้ามโดยไม่รู้ตัว\n\n### Simple vs. easy (ด้วยตัวอย่างในชีวิตประจำวัน)\n\n คือวิธีที่บางสิ่งรู้สึกตอนนี้ คือจำนวนชิ้นส่วนและการพันกันของมัน\n\n- บะหมี่กึ่งสำเร็จรูปมันง่าย ในขณะที่สตูว์พื้นฐานอาจเรียบง่าย: ส่วนผสมน้อยหนึ่งหม้อ ไม่มีอะไรซ่อนอยู่\n- รีโมทที่มีปุ่ม 60 ปุ่มอาจทำให้ฟีเจอร์หนึ่งเป็น "ง่าย" แต่ไม่เรียบง่าย รีโมทที่มีปุ่ม 6 ปุ่มชัดเจนจะเรียบง่ายกว่า แม้ว่าจะต้องใช้เวลาเรียนรู้บ้าง\n\nในซอฟต์แวร์ "easy" มักหมายถึง "พิมพ์เร็ววันนี้" ในขณะที่ "simple" หมายถึง "ยากที่จะทำให้เสียในเดือนหน้า"\n\n### วิธีที่ "ง่ายตอนนี้" สร้างความซับซ้อนในอนาคต\n\nทีมมักเลือกทางลัดที่ลดแรงเสียดทานทันทีแต่เพิ่มโครงสร้างที่มองไม่เห็นซึ่งต้องบำรุงรักษา:\n\n- "แค่เพิ่มแฟลก" ตอนนี้ทุกฟีเจอร์ต้องพิจารณาแฟลกนั้น\n- "เราจะเก็บค่าที่คำนวณแล้วเพื่อประหยัดเวลา" ตอนนี้คุณต้องทำให้มันสอดคล้องกันข้ามเส้นทางโค้ด\n- "เราจะแก้ที่ UI" ตอนนี้กฎธุรกิจเดียวกันอยู่ในหลายที่\n\nแต่ละตัวเลือกอาจรู้สึกว่าเร็ว แต่เพิ่มจำนวนชิ้นส่วนเคลื่อนที่ กรณีพิเศษ และการพึ่งพาข้ามกัน นั่นคือวิธีที่ระบบกลายเป็นเปราะบางโดยไม่มีความผิดพลาดใหญ่เพียงครั้งเดียว\n\n### ความเร็วไม่เท่ากับความเรียบง่าย\n\nการส่งงานเร็วอาจดี—แต่ มักหมายความว่าคุณกำลังกู้ยืมจากอนาคต ดอกเบี้ยจะปรากฏเป็นบั๊กที่ยากจะทำซ้ำ การเตรียมทีมที่ลากช้า และการเปลี่ยนแปลงที่ต้องการ "การประสานงานอย่างระมัดระวัง"\n\n### เช็คลิสต์ไว้วัดความซับซ้อนที่เกิดโดยไม่ตั้งใจ\n\nถามคำถามเหล่านี้เมื่อรีวิวการออกแบบหรือ PR:\n\n- เราแนะนำโหมดใหม่ แฟลก หรือสาขาการกำหนดค่าใหม่หรือไม่?\n- เรากำลังแคชหรือทำสำเนาข้อมูลที่ต้องรักษาความสอดคล้องหรือไม่?\n- โมดูลหลายตัวต้องเปลี่ยนพร้อมกันสำหรับพฤติกรรมเดียวหรือไม่?\n- กฎถูกนำไปใช้มากกว่าหนึ่งที่หรือไม่?\n- เพื่อนร่วมทีมใหม่จะคาดเดาวิธีการทำงานได้หรือไม่โดยไม่ต้องคำอธิบายเพิ่ม?