ระวังผลกระทบแบบ Makefile

 (blog.yossarian.net)
1 คะแนน โดย GN⁺ 2025-01-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • การรับรู้เกี่ยวกับผลกระทบแบบ Makefile

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

  • ปัญหาและผลกระทบ

    • ปัญหาในขั้นตอนการออกแบบ: เครื่องมือซับซ้อนเกินไป หรือใช้งานตั้งแต่ต้นได้อย่างยุ่งยาก
    • การตั้งค่า CI/CD: มักคัดลอกและปรับแก้การตั้งค่า YAML ใน GitHub Actions หรือ GitLab CI/CD
    • การตั้งค่า linter และ formatter: คัดลอกชุดกฎพื้นฐานข้ามโปรเจ็กต์ แล้วค่อยเพิ่มหรือลดความเข้มงวดตามความจำเป็น
    • ระบบบิลด์: ทุกอย่างที่ไม่ใช่เรื่องเล็กน้อยมักเริ่มมีหน้าตาคล้ายระบบบิลด์ก่อนหน้า

  • เหตุใดปรากฏการณ์นี้จึงสำคัญ

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

  • สิ่งที่ควรพิจารณาเมื่อออกแบบเครื่องมือ

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

  • ปรากฏการณ์ที่คล้ายกับผลกระทบแบบ Makefile

    • คล้ายกับ cargo culting หรือ normalization of deviance แต่ผลกระทบแบบ Makefile เป็นเรื่องของผลลัพธ์ที่เกิดจากการออกแบบเฉพาะแบบหนึ่ง
    • ผลกระทบแบบ Makefile ไม่ได้ไร้ประสิทธิภาพหรือเลวร้ายโดยเนื้อแท้เสมอไป แต่เป็นสิ่งที่ควรตระหนักเมื่อออกแบบเครื่องมือและระบบ

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

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

 
GN⁺ 2025-01-12
ความคิดเห็นบน Hacker News

  • ระบบที่ซับซ้อนมักค่อย ๆ พัฒนามาจากระบบที่เรียบง่าย ระบบที่ถูกออกแบบให้ซับซ้อนตั้งแต่แรกมักทำงานได้ไม่ดี และควรเริ่มต้นจากระบบที่เรียบง่าย

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

  • นักพัฒนาราว 10% มีความสามารถในการเริ่มสร้างบางอย่างได้ตั้งแต่ศูนย์ 40% ทำงานด้วยการคัดลอกและวางโค้ด และอีก 50% แทบไม่รู้อะไรนอกจากโจทย์ปริศนา LeetCode Makefiles จำนวนมากถูกสร้างขึ้นจากการคัดลอกและวาง

  • Cargo Cult Development หมายถึงแนวทางพัฒนาที่ไม่เข้าใจหลักการของเทคโนโลยี แต่เลียนแบบเพียงลักษณะภายนอก เป็นวิธีแบบคัดลอก วาง ลอง ปรับ แล้วหวังว่าจะทำงานได้

  • Makefile อาจเป็นอุปมาที่ไม่ค่อยเหมาะนัก โค้ดจำนวนมากถูกคัดลอกมาจากเว็บและมีส่วนที่ไม่ได้ใช้อยู่มาก การลบส่วนที่ไม่จำเป็นออกเป็นนิสัยที่ดี

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

  • เครื่องมืออย่าง LaTeX มักถูกใช้งานไม่บ่อย จึงมักเริ่มจากการคัดลอกและวาง เครื่องมือที่ใช้น้อยย่อมจำได้ยาก

  • Make มีเอกสารที่ดีมาก และถ้าผู้ใช้อ่านเอกสารก็จะเข้าใจได้ง่าย อย่างไรก็ตาม เครื่องมือจำนวนมากมีเอกสารไม่เพียงพอ ทำให้ผู้ใช้เข้าใจเครื่องมือได้ยาก

  • เครื่องมือที่ซับซ้อนนั้นจำเป็น แต่ถ้าแอปพลิเคชันที่เรียบง่ายยังเกิดผลแบบ Makefile ก็แปลว่าเครื่องมือนั้นซับซ้อนเกินไป Makefile อาจเหมาะกับโปรเจ็กต์ขนาดเล็ก

  • "Copy-Pasta Driven Development" ชี้ให้เห็นปัญหาที่เกิดจากการคัดลอกและวางโค้ด และเครื่องมืออย่าง Copilot อาจทำให้ปัญหานี้แย่ลง