- ความงามคืออะไร?
- ความงามคือคุณค่าที่มนุษย์รับรู้
- สิ่งที่มอบความน่าทึ่ง ความใหม่ ความเสถียร ความสบายใจ และความเรียบง่าย
- อาจแบ่งได้เป็นสิ่งที่น่าทึ่งกับสิ่งที่เป็นธรรมชาติ
- การจะรู้สึกถึงความงาม (การหยั่งรู้) ได้ จำเป็นต้องมีความรู้พื้นฐานอยู่พอสมควร
- ความงามเป็นสิ่งเพื่อการอยู่รอด เมื่อเห็นสิ่งที่ไม่อาจเข้าใจได้ มนุษย์จะรู้สึกไม่สบายใจ
- นิยามของโค้ดที่สวยงาม
- เพราะโค้ดไม่ได้ทำงานอยู่ลำพัง ยิ่งสวยงามก็ยิ่งดี
- ในอุดมคติ คือโค้ดที่อ่านแล้วไม่มีจุดสะดุดแม้แต่จุดเดียว
- โค้ดที่เป็นธรรมชาตินั้นดี
- องค์ประกอบ 4 อย่างของโค้ดที่สวยงาม
- เชิงสังคม เชิงความน่าเชื่อถือ เชิงเส้น และเชิงประกาศ
- ส่วนที่เป็นเชิงสังคมและเชิงความน่าเชื่อถือ มุ่งแสวงหาความเสถียร
- ส่วนที่เป็นเชิงเส้นและเชิงประกาศ มุ่งแสวงหาสุนทรียะ
- โค้ดเชิงสังคม
- โค้ดที่คำนึงถึงบริบทโดยรอบทั้งหมด
- การปฏิบัติตามธรรมเนียม กฎ หรือภารกิจ
- คล้ายกับความเป็นสังคมของภาษา
- โค้ดเชิงความน่าเชื่อถือ
- โค้ดที่เชื่อใจและใช้งานได้
- หากเชื่อถือไม่ได้ ก็จะกลายเป็นโค้ดที่ต้องลงมือตรวจสอบเองโดยตรง
- คำนึงถึง pure function, idempotency, side effect เป็นต้น
- แม้จะไม่มี side effect เลยไม่ได้ ก็สามารถบอกให้รู้ได้ผ่านเอกสารหรือข้อยกเว้น
- โค้ดเชิงเส้น
- โค้ดที่เวลาอ่านแล้วอ่านจากบนลงล่างเพียงครั้งเดียวก็พอ
- เมื่อเป็นเชิงเส้น ในทางประสาทวิทยาศาสตร์จะทำให้ working memory ประมวลผลได้ง่ายขึ้น
- โค้ดเชิงประกาศ
- โค้ดที่บอกได้อย่างชัดเจนว่ากำลังทำอะไร
- การตั้งชื่อที่เหมาะสมนั้นเป็นสิ่งที่ดี
- ในทางประสาทวิทยาศาสตร์จะทำให้ short-term memory ประมวลผลง่ายขึ้น
- ในโลกความเป็นจริง
- สิ่งที่เรียกว่าโค้ดที่สวยงาม ไม่ได้เกิดขึ้นแบบสำเร็จในครั้งเดียว
- โค้ดที่สวยงามอย่างสมบูรณ์นั้นไม่ใช่สิ่งที่พบได้บ่อย
- ดังนั้นจึงจำเป็นต้องมีแนวคิดเรื่องการปรับปรุงแบบค่อยเป็นค่อยไปและการประดับโค้ด
- การปรับปรุงแบบค่อยเป็นค่อยไป
- คือการทำ refactoring
- ทำการตรวจสอบและปรับปรุงซ้ำ ๆ เพื่อรักษาคุณภาพระดับ 70~80% ไว้อย่างต่อเนื่อง
- ควรตรวจสอบและปรับปรุงเมื่อไร?
- เมื่อ ownership ของโค้ดเริ่มเลือนราง
- เมื่อความรู้เกี่ยวกับโค้ดที่เขียนไว้เริ่มเลือนราง
- เมื่อเริ่มได้กลิ่นไม่ดี
- เมื่อรู้สึกไม่สบายใจเวลามองโค้ด
- การประดับโค้ด
- คือการตกแต่งให้โค้ดดูสวยงาม
- ตัวอย่างที่ใช้กันมากคือ test, code review, documentation และ comment
- test
- ทำให้โค้ดน่าเชื่อถือมากขึ้น
- รับประกันการทำงาน และตัว test เองก็สามารถเป็นเอกสารได้
- code review
- ทำให้โค้ดน่าเชื่อถือมากขึ้นผ่านการตรวจสอบ
- เพราะช่วยกระจาย ownership ของโค้ด จึงเพิ่มความเป็นเชิงสังคมของโค้ดได้ด้วย
- แต่ code review แบบบังคับทุกครั้งก็อาจกลายเป็นคอขวดได้
- documentation
- ช่วยให้เข้าใจโค้ดได้มากขึ้น
- ช่วงเวลาที่ควรทำ documentation คือเมื่อมีความจำเป็นที่นักพัฒนาคนอื่นต้องรู้บริบท การออกแบบ และกฎของโค้ดนั้น
- หากใช้เครื่องมืออย่าง UML ก็จะยิ่งดี
- comment
- สำหรับพื้นที่โค้ดที่ซับซ้อนและเลี่ยงไม่ได้ การอธิบายด้วย comment จะดีกว่าเอกสาร
- คุณภาพโค้ดเป็นเรื่องสำคัญ แต่โค้ดที่สวยงามไม่ได้รับประกันความสำเร็จเสมอไป
- ตรงกันข้าม บางครั้งอาจต้องให้ความสำคัญกับการออกแบบหรือกระบวนการทำงานมากกว่า
- คุณภาพโค้ดไม่ได้รับประกันคุณภาพของผลิตภัณฑ์เสมอไป
9 ความคิดเห็น
55555
โค้ดที่คำนึงถึงสังคมก็คงสำคัญเหมือนกันนะ ฮ่าๆ
คิดว่าเป็นบทความที่ดีและเรียบเรียงไว้ได้ดีมากครับ หากในทีมมีประเด็นเรื่องคุณภาพโค้ดเกิดขึ้นบ่อย ๆ ก็น่าจะเหมาะที่จะอ่านแล้วมารวมตัวกันอภิปรายกันครับ
เป็นหัวข้อที่อาจเข้าใจยากได้ แต่กลับอ่านได้ลื่นมากเลย ขอบคุณครับ!
การปรับปรุงอย่างค่อยเป็นค่อยไปสำคัญจริง ๆ นั่นแหละ ไม่ว่าอะไรก็ย่อมไม่อิ่มได้ตั้งแต่คำแรกอยู่แล้ว
งานอดิเรกอย่างการรู้สึกถึงความงามเชิงสุนทรียะในโค้ดที่ตัวเองเขียน ก็ควรเป็นแค่มุมมองส่วนตัวเท่านั้น นักพัฒนามืออาชีพที่รับเงินทำงานอย่าเข้าไปมองโค้ดของบริษัทด้วยมุมมองแบบศิลปะ แล้วก็อย่าได้กลายเป็นซีเนียร์ที่คอยปลูกฝังแนวคิดแปลก ๆ แบบนั้นให้กับจูเนียร์เลย ได้โปรดเถอะ ไม่อย่างนั้นก็เลิกเป็นนักพัฒนาไปวาดรูปซะ จะพร่ำเรื่องศิลปะอะไรกันนักหนา...
คุณไปยึดติดกับคำว่า “ความงาม” แบบผิดๆ แล้ว
วัยรุ่นที่อ่านแค่พาดหัว
ฮ่าๆ ก็โอเวอร์ไปหน่อยมากเลยนะ