ชุมชนการพัฒนาซอฟต์แวร์กำลังถกเถียงอย่างคึกคักเกี่ยวกับการโต้แย้งที่น่าสนใจระหว่างบุคคลที่มีอิทธิพลสองคนในวงการออกแบบซอฟต์แวร์: Robert Uncle Bob Martin ผู้เขียน Clean Code และ John Ousterhout ผู้เขียน A Philosophy of Software Design การอภิปรายของพวกเขาได้จุดประกายความคิดเห็นมากมายเกี่ยวกับแนวทางพื้นฐานในการพัฒนาซอฟต์แวร์และแนวปฏิบัติที่ดีที่สุด
ปัญหาของความเคร่งครัดในหลักการ
หนึ่งในประเด็นที่มีการอภิปรายมากที่สุดคือความเคร่งครัดที่รับรู้ได้ในหลักการของ Clean Code นักพัฒนาหลายคนแสดงความกังวลเกี่ยวกับการนำกฎไปใช้อย่างเคร่งครัดเกินไป โดยเฉพาะเกี่ยวกับความยาวของฟังก์ชันและแนวปฏิบัติในการเขียนคอมเมนต์ ชุมชนเน้นย้ำว่าการยึดมั่นในหลักการอย่างเคร่งครัด เช่น ฟังก์ชันควรมีความยาวเพียง 2-4 บรรทัด อาจนำไปสู่สิ่งที่นักพัฒนาบางคนเรียกว่า ลาซานญ่าโค้ด - ชั้นของนามธรรมบางๆ หลายชั้นที่ทำให้โค้ดซับซ้อนมากกว่าจะทำให้ชัดเจน
สำหรับผม เป้าหมายพื้นฐานของการออกแบบซอฟต์แวร์คือการทำให้ระบบเข้าใจง่ายและแก้ไขได้ง่าย ผมใช้คำว่า 'ความซับซ้อน' เพื่ออ้างถึงสิ่งที่ทำให้การทำความเข้าใจและแก้ไขระบบเป็นเรื่องยาก
ประเด็นหลักที่มีการโต้แย้ง:
- ความยาวของฟังก์ชัน (Clean Code: 2-4 บรรทัด เทียบกับ วิธีการตามบริบท)
- การใช้คอมเมนต์ (ใช้น้อยที่สุด เทียบกับ การเขียนเอกสารอย่างมีจุดประสงค์)
- หลักการของการทำแอบสแทรกชัน (กฎที่เข้มงวด เทียบกับ การวัดอัตราส่วนความซับซ้อน)
- แนวทางการพัฒนา (แบบกำหนดตายตัว เทียบกับ แบบอิงหลักฐาน)
บทบาทของคอมเมนต์
ประเด็นขัดแย้งที่สำคัญหมุนรอบการจัดการกับคอมเมนต์ในโค้ด ในขณะที่ Clean Code สนับสนุนให้โค้ดอธิบายตัวเองได้โดยมีคอมเมนต์น้อยที่สุด นักพัฒนาหลายคนโต้แย้งถึงบทบาทสำคัญของคอมเมนต์ในการอธิบาย เหตุผล เบื้องหลังการตัดสินใจในโค้ด โดยเฉพาะเมื่อต้องทำงานกับระบบภายนอก อินเตอร์เฟซฮาร์ดแวร์ หรือกระบวนการที่ไม่เป็นไปตามสามัญสำนึก ชุมชนเน้นย้ำถึงคุณค่าของคอมเมนต์ในการบันทึกวิธีแก้ปัญหาเฉพาะหน้า ข้อกำหนดด้านเวลา และพฤติกรรมเฉพาะของระบบที่ไม่สามารถถ่ายทอดผ่านชื่อเมธอดได้อย่างมีประสิทธิภาพ
แนวทางที่อิงหลักฐาน
A Philosophy of Software Design ของ Ousterhout ได้รับความสนใจเป็นพิเศษสำหรับแนวทางที่อิงหลักฐานมากกว่าในหลักการออกแบบซอฟต์แวร์ หนังสือเล่มนี้แนะนำแนวคิดการวัดคุณภาพของนามธรรมผ่านอัตราส่วนระหว่างความซับซ้อนที่มีอยู่กับความซับซ้อนของอินเตอร์เฟซ วิธีการปฏิบัตินี้ได้รับการตอบรับจากนักพัฒนาหลายคนที่พบว่ามันให้กรอบการทำงานที่ยืดหยุ่นและใช้งานได้จริงมากกว่าสำหรับการตัดสินใจในการออกแบบ
วิวัฒนาการของความคิดนักพัฒนา
รูปแบบที่น่าสนใจปรากฏขึ้นจากการอภิปราย: นักพัฒนาหลายคนอธิบายถึงการเดินทางจากการเริ่มต้นยอมรับแนวทางที่เคร่งครัดของ Clean Code ไปสู่การนำแนวทางที่มีความละเอียดอ่อนและตระหนักถึงบริบทมากขึ้นในการออกแบบซอฟต์แวร์ วิวัฒนาการนี้มักใช้เวลาประมาณห้าปี ซึ่งบ่งชี้ว่าในขณะที่กฎที่เคร่งครัดอาจเป็นประโยชน์สำหรับผู้เริ่มต้น นักพัฒนาที่มีประสบการณ์มักจะชอบวิธีการแก้ปัญหาที่ยืดหยุ่นและขึ้นอยู่กับสถานการณ์มากกว่า
สรุปได้ว่า ในขณะที่หนังสือทั้งสองเล่มมีส่วนสำคัญต่อแนวคิดการออกแบบซอฟต์แวร์ ชุมชนนักพัฒนาสนับสนุนแนวทางที่สมดุลมากขึ้น ซึ่งพิจารณาถึงบริบท ความเป็นไปได้ในทางปฏิบัติ และความต้องการเฉพาะของแต่ละโครงการมากกว่าการยึดติดกับกฎที่เคร่งครัด การถกเถียงนี้เน้นย้ำถึงวิวัฒนาการอย่างต่อเนื่องของหลักการออกแบบซอฟต์แวร์และความสำคัญของการรักษาความยืดหยุ่นในทางปฏิบัติในการพัฒนา
อ้างอิง: Introductions