ลาก่อน Clean Code (2020)

 (overreacted.io)
4 คะแนน โดย GN⁺ 2023-12-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คำอำลาการจัดระเบียบโค้ด

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

เช้าวันถัดมา...

  • หัวหน้าขอคุยเป็นการส่วนตัวและขอให้ย้อนการเปลี่ยนแปลงโค้ดกลับ
  • ตอนแรกตกใจ แต่สุดท้ายก็ตระหนักว่าการตัดสินใจของหัวหน้านั้นถูกต้อง

ช่วงหนึ่งของการเติบโต

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

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-09
ความเห็นจาก Hacker News

  • "Clean Code" จำเป็นต้องรีแบรนด์

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

  • การเขียนโค้ดซ้ำบางครั้งอาจเป็นเรื่องที่ดีได้ แต่ไม่ใช่หลักฐานว่า Clean Code แย่

    • ถ้าแทนที่การคำนวณทางคณิตศาสตร์ที่ซ้ำกัน 10 บรรทัดด้วยฟังก์ชัน ก็อาจทำให้โค้ดสะอาดขึ้นได้
    • ควรรีวิว PR และปฏิเสธหากไม่ตรงตามมาตรฐาน
    • ทัศนคติที่เมินความสำคัญของ Clean Code สุดท้ายจะนำไปสู่โค้ดเบสที่ไม่มีใครอยากทำงานด้วย
    • บทเรียนคือจำเป็นต้องมีการสื่อสารที่ดีกว่าและความยับยั้งชั่งใจมากขึ้น

  • เพื่อนร่วมงานคนหนึ่งเขียนโค้ดจำนวนมากด้วยการคัดลอกและวาง

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

  • มีความเป็นไปได้สูงว่าเวอร์ชัน Clean Code เข้าไปแทนที่โค้ดที่สกปรกกว่า

    • จำเป็นต้องมีบทเรียนเกี่ยวกับวิธีการทำงานร่วมกันในทีม

  • เมื่อมีการเปลี่ยนแปลงโค้ด จำเป็นต้องมีการรีวิวจากเพื่อนร่วมงาน

    • ต้องยอมรับว่ากำลังขาดกระบวนการที่ดี
    • ควรรีแฟกเตอร์โค้ดเมื่อจำเป็นเท่านั้น

  • ในสายการเงินมักต้องจัดการกับผลิตภัณฑ์ที่คล้ายกันแต่แตกต่างกัน

    • การหลีกเลี่ยง abstraction ที่มากเกินไปพร้อมกับรักษา Clean Code ไว้เป็นเรื่องสำคัญ

  • ภาษาอย่าง Haskell ผลักดัน abstraction ไปสูงสุดในระดับภาษา

    • แม้จะลด abstraction เฉพาะโปรเจกต์ให้เหลือน้อยที่สุด แต่ต้นทุนการเรียนรู้ก็ยังสูง

  • การย้ายการคำนวณทางคณิตศาสตร์ที่ซ้ำกันไปไว้ในฟังก์ชันแยกต่างหากถือเป็น Clean Code

    • แต่การรีแฟกเตอร์ฟังก์ชัน resize ที่ดูเหมือนสร้างอินเทอร์เฟซขึ้นมานั้นเป็นสิ่งที่ผิด

  • คำอธิบายเกี่ยวกับ abstraction ที่แย่

    • ปัญหาคือการออกแบบโดยไม่ได้พิจารณาการใช้งานในอนาคตอย่างเพียงพอ

  • Rob Pike กล่าวว่า "การคัดลอกเล็กน้อยดีกว่าการพึ่งพาเล็กน้อย"

    • หลักการ DRY บางครั้งเพิ่ม abstraction เข้ามา แต่ถ้า abstraction นั้นไม่ orthogonal มากพอ ก็อาจยิ่งทำให้ปัญหาแย่ลง