นักพัฒนาถกเถียงสิ่งที่ทำให้ Functional Programming เข้าใจยากในโค้ดเบสสมัยใหม่

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

Method Chaining เทียบกับ True Functional Programming

การถกเถียงมุ่งเน้นไปที่ว่า method chaining ควรถือเป็น functional programming หรือไม่ นักพัฒนาหลายคนชี้ให้เห็นว่าความสับสนเกิดจากการผสมผสานแนวคิดการเขียนโปรแกรมที่แตกต่างกัน Method chaining แม้จะคล้ายกับ applicative style ของ functional programming แต่เป็นเพียง syntax sugar ที่ทำให้โค้ดดูเรียบง่ายขึ้น ปัญหาที่แท้จริงไม่ใช่ functional programming เอง แต่เป็นการเชื่อมโยงการดำเนินการที่ยาวเกินไปซึ่งทำให้โค้ดติดตามได้ยากขึ้น

นักพัฒนาบางคนแย้งว่า for-loop แบบง่ายๆ ที่มีการดำเนินการที่ชัดเจนภายในลูปสามารถอ่านได้ง่ายกว่า method chains ที่ซับซ้อนมาก สิ่งนี้เน้นย้ำว่าการเลือกรูปแบบการเขียนโปรแกรมควรขึ้นอยู่กับสถานการณ์เฉพาะและความชอบของทีม

ปัจจัยความซับซ้อนทั่วไปในการเขียนโปรแกรมเชิงฟังก์ชัน:

• ระบบการอนุมานประเภทข้อมูลแบบโกลบอล
• ไวยากรณ์แบบโดยนัย (ไม่มีวงเล็บ เครื่องหมายอัฒภาค)
• การใช้ Currying และรูปแบบ point-free
• นิพจน์ที่ซ้อนกันลึก
• การเชื่อมโยงเมธอดเทียบกับลูปแบบง่าย

การเลือกออกแบบภาษาสร้างความซับซ้อน

การสนทนาเผยให้เห็นว่าภาษา functional programming มักมาพร้อมกับฟีเจอร์ที่ทำให้เรียนรู้ได้ยาก ซึ่งรวมถึง global type inference, implicit syntax ที่เอาวงเล็บและเซมิโคลอนออก, currying และการเขียนโปรแกรมแบบ point-free style นิพจน์ที่ซ้อนลึกซึ่งค่าจริงอาจอยู่ห่างจากการประกาศหลายร้อยบรรทัดก็มีส่วนทำให้เกิดความสับสนเช่นกัน

หากโค้ดนี้ซับซ้อนเกินไปสำหรับคุณ คุณควรพิจารณาอาชีพของคุณใหม่

น่าสนใจที่ Rust ได้รับการยกย่องในการหลีกเลี่ยงกับดักความซับซ้อนเหล่านี้หลายอย่างในขณะที่ยังคงรองรับแนวคิด functional programming สิ่งนี้ชี้ให้เห็นว่าความยากไม่ได้อยู่ที่ functional programming โดยธรรมชาติ แต่เป็นวิธีที่มันถูกนำไปใช้ในภาษาต่างๆ

ภาษาโปรแกรมมิ่งที่กล่าวถึงในการอภิปราย:

• Scala: อธิบายว่าเป็นภาษาเฉพาะกลุ่มที่มีความซับซ้อนของ FP
• Kotlin: มีลักษณะเป็น "Java ที่ดีขึ้นเล็กน้อย"
• Rust: ได้รับการยกย่องในการหลีกเลี่ยงกับดักความซับซ้อนของ FP
• JavaScript: อ้างอิงถึงการอภิปรายเรื่อง promises และ monads

พลวัตของทีมและการนำเทคโนโลยีมาใช้

นักพัฒนาที่มีประสบการณ์หลายคนได้แบ่งปันความเข้าใจเกี่ยวกับการจัดการความขัดแย้งในทีมเรื่องรูปแบบการเขียนโปรแกรม การถกเถียงเน้นย้ำว่าการเลือกใช้ภาษาเฉพาะกลุ่มอย่าง Scala ต้องการการฝึกอบรมและการสนับสนุนทีมที่เหมาะสมมากกว่าการจำกัดนักพัฒนาที่มีประสบการณ์ เมื่อทีมนำเทคโนโลยีขั้นสูงมาใช้ พวกเขาจำเป็นต้องลงทุนในการศึกษาและ pair programming เพื่อยกระดับทุกคนให้ทันกัน

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

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

อ้างอิง: How to stop functional programming