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

ทำไมความซับซ้อนจึงชนะในโปรเจกต์จริง

ซอฟต์แวร์ไม่ค่อยซับซ้อนทันทีในครั้งเดียว มันกลายเป็นเช่นนั้นจากการตัดสินใจ "สมเหตุสมผล" ทีละเรื่อง: แคชเล็ก ๆ เพื่อให้ทันกำหนดเวลา, วัตถุที่เปลี่ยนแปลงได้ร่วมกันเพื่อหลีกเลี่ยงการคัดลอก, ข้อยกเว้นกฎเพราะ "อันนี้พิเศษ" แต่ละตัวเลือกดูเหมือนเล็กน้อย แต่รวมกันแล้วจะสร้างระบบที่การเปลี่ยนแปลงรู้สึกเสี่ยง บั๊กยากต่อการทำซ้ำ และการเพิ่มฟีเจอร์เริ่มใช้เวลานานกว่าการพัฒนา

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

บทความนี้คืออะไร (และไม่ใช่อะไร)

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

ทำไมค่าเริ่มต้นจึงสำคัญกว่าที่คุณคิด

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

เราจะมุ่งไปที่สามธีม:

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

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

Rich Hickey และสิ่งที่ Clojure มาตั้งใจแก้

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

Clojure คืออะไร (ในภาพรวม แบบไม่ใช้ศัพท์ลึก)

Clojure เป็นภาษาการเขียนโปรแกรมสมัยใหม่ที่รันบนแพลตฟอร์มที่เป็นที่รู้จักเช่น JVM (runtime ของ Java) และ JavaScript ถูกออกแบบให้ทำงานร่วมกับระบบนิเวศที่มีอยู่ในขณะเดียวกันก็ส่งเสริมสไตล์เฉพาะ: แทนข้อมูลเป็นข้อมูลธรรมดา, ให้ความสำคัญกับค่าที่ไม่เปลี่ยนแปลง และแยก "สิ่งที่เกิดขึ้น" ออกจาก "สิ่งที่แสดงบนหน้าจอ"

คุณสามารถคิดว่ามันเป็นภาษาที่ส่งเสริมให้คุณใช้บล็อกที่ชัดเจนและหลีกเลี่ยงผลข้างเคียงที่ซ่อนอยู่

ปัญหาที่มันต้องการลดลง

Clojure ไม่ได้ถูกสร้างมาเพื่อทำให้สคริปต์เล็ก ๆ สั้นลง แต่มุ่งที่ความเจ็บปวดซ้ำ ๆ ในโปรเจกต์:

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

ค่าเริ่มต้นของ Clojure ผลักดันไปทางชิ้นส่วนเคลื่อนที่น้อยลง: โครงสร้างข้อมูลที่มั่นคง, การอัปเดตที่ชัดเจน, และเครื่องมือที่ทำให้การประสานงานปลอดภัยขึ้น

มีประโยชน์ถึงแม้คุณจะไม่ย้ายไปใช้ Clojure

คุณค่าไม่ได้จำกัดอยู่ที่การเปลี่ยนภาษา แนวคิดสำคัญของ Hickey—ทำให้เรียบง่ายโดยการลดการพึ่งพาที่ไม่จำเป็น, ปฏิบัติต่อข้อมูลเป็นข้อเท็จจริงที่คงทน, และลดสถานะที่เปลี่ยนแปลงได้—สามารถปรับปรุงระบบใน Java, Python, JavaScript และภาษาอื่น ๆ ได้เช่นกัน

ความเรียบง่าย: ไม่ใช่ "ง่าย" แต่ชิ้นส่วนเคลื่อนที่น้อยลง

Rich Hickey แยกเส้นที่ชัดเจนระหว่าง simple และ easy — และนี่เป็นเส้นที่หลายโปรเจกต์ข้ามโดยไม่รู้ตัว

Simple vs. easy (ด้วยตัวอย่างในชีวิตประจำวัน)

Easy คือวิธีที่บางสิ่งรู้สึกตอนนี้ Simple คือจำนวนชิ้นส่วนและการพันกันของมัน

• บะหมี่กึ่งสำเร็จรูปมันง่าย ในขณะที่สตูว์พื้นฐานอาจเรียบง่าย: ส่วนผสมน้อยหนึ่งหม้อ ไม่มีอะไรซ่อนอยู่
• รีโมทที่มีปุ่ม 60 ปุ่มอาจทำให้ฟีเจอร์หนึ่งเป็น "ง่าย" แต่ไม่เรียบง่าย รีโมทที่มีปุ่ม 6 ปุ่มชัดเจนจะเรียบง่ายกว่า แม้ว่าจะต้องใช้เวลาเรียนรู้บ้าง

ในซอฟต์แวร์ "easy" มักหมายถึง "พิมพ์เร็ววันนี้" ในขณะที่ "simple" หมายถึง "ยากที่จะทำให้เสียในเดือนหน้า"

วิธีที่ "ง่ายตอนนี้" สร้างความซับซ้อนในอนาคต

ทีมมักเลือกทางลัดที่ลดแรงเสียดทานทันทีแต่เพิ่มโครงสร้างที่มองไม่เห็นซึ่งต้องบำรุงรักษา:

• "แค่เพิ่มแฟลก" ตอนนี้ทุกฟีเจอร์ต้องพิจารณาแฟลกนั้น
• "เราจะเก็บค่าที่คำนวณแล้วเพื่อประหยัดเวลา" ตอนนี้คุณต้องทำให้มันสอดคล้องกันข้ามเส้นทางโค้ด
• "เราจะแก้ที่ UI" ตอนนี้กฎธุรกิจเดียวกันอยู่ในหลายที่

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

ความเร็วไม่เท่ากับความเรียบง่าย

การส่งงานเร็วอาจดี—แต่ ความเร็วโดยไม่มีการทำให้เรียบง่าย มักหมายความว่าคุณกำลังกู้ยืมจากอนาคต ดอกเบี้ยจะปรากฏเป็นบั๊กที่ยากจะทำซ้ำ การเตรียมทีมที่ลากช้า และการเปลี่ยนแปลงที่ต้องการ "การประสานงานอย่างระมัดระวัง"

เช็คลิสต์ไว้วัดความซับซ้อนที่เกิดโดยไม่ตั้งใจ

ถามคำถามเหล่านี้เมื่อรีวิวการออกแบบหรือ PR:

• เราแนะนำโหมดใหม่ แฟลก หรือสาขาการกำหนดค่าใหม่หรือไม่?
• เรากำลังแคชหรือทำสำเนาข้อมูลที่ต้องรักษาความสอดคล้องหรือไม่?
• โมดูลหลายตัวต้องเปลี่ยนพร้อมกันสำหรับพฤติกรรมเดียวหรือไม่?
• กฎถูกนำไปใช้มากกว่าหนึ่งที่หรือไม่?
• เพื่อนร่วมทีมใหม่จะคาดเดาวิธีการทำงานได้หรือไม่โดยไม่ต้องคำอธิบายเพิ่ม?