เรากำลังทำให้ซอฟต์แวร์พัง

 (antirez.com)
31 คะแนน โดย GN⁺ 2025-02-09 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการไม่คำนึงถึงความซับซ้อนอีกต่อไป เมื่อเราเพิ่มฟีเจอร์หรือปรับแต่งบางส่วนให้เหมาะสม
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยระบบบิลด์ที่ซับซ้อน
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยโซ่การพึ่งพาที่ไร้สาระ ทำให้ทุกอย่างเทอะทะและเปราะบาง
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการบอกโปรแกรมเมอร์รุ่นใหม่ว่า "Don’t reinvent the wheel!" แต่การประดิษฐ์วงล้อขึ้นมาใหม่คือวิธีเรียนรู้ว่าสิ่งต่าง ๆ ทำงานอย่างไร และเป็นก้าวแรกในการสร้างวงล้อแบบใหม่ที่แตกต่างออกไป
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการไม่คำนึงถึง backward compatibility ของ API อีกต่อไป
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการผลักดันให้เขียนสิ่งที่ทำงานได้อยู่แล้วขึ้นมาใหม่
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการกระโจนเข้าใส่ทุกภาษา กระบวนทัศน์ และเฟรมเวิร์กใหม่ ๆ ทุกครั้งที่มันออกมา
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการประเมินความยากของการจัดการกับไลบรารีซับซ้อนที่มีอยู่ต่ำเกินไปอยู่เสมอ เมื่อเทียบกับการลงมือทำเอง
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการมองว่ามาตรฐานโดยพฤตินัยของ XYZ ย่อมดีกว่าสิ่งที่เราสามารถลงมือทำเองให้เหมาะกับการใช้งานเฉพาะของเราได้เสมอ
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการอ้างว่าคอมเมนต์ในโค้ดไม่มีประโยชน์
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการเข้าใจผิดว่าซอฟต์แวร์เป็นเพียงศาสตร์ทางวิศวกรรมล้วน ๆ
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการสร้างระบบที่ไม่อาจย่อส่วนลงได้อีก: ในทุกระบบ สิ่งที่เรียบง่ายควรทำให้สำเร็จได้อย่างเรียบง่าย
  • เรากำลังทำให้ซอฟต์แวร์พังด้วยการพยายามเขียนโค้ดให้ออกมาให้เร็วที่สุด โดยไม่พยายามสร้างโค้ดที่ออกแบบมาอย่างดีที่สุดเท่าที่จะทำได้
  • เรากำลังทำให้ซอฟต์แวร์พัง และสิ่งที่จะเหลืออยู่จะไม่มอบความสนุกของการแฮ็กอีกต่อไป

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

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

 
dohyun682 2025-02-11

กำลังประดิษฐ์ล้อขึ้นใหม่ <-> ประดิษฐ์สิ่งที่กำลังเขียนอยู่แล้วขึ้นใหม่

สองอย่างนี้ไม่ใช่แนวคิดที่ตรงข้ามกันโดยสิ้นเชิงหรอกเหรอ?
 
roxie 2025-02-10

ยุคบูมของคอมเมนต์กำลังจะมา
 
tujuc 2025-02-10

โดนใจเลย 5555 ทุกครั้งที่รุ่นน้องเข้ามา...ก็กำลังคิดอยู่ว่าควรจะสอนยังไง แบบนี้น่าจะเป็นวิธีที่ดีนะ..
 
ilikeall 2025-02-10

หยุดตีได้แล้ว ฮือ ๆ
 
bus710 2025-02-10

....งั้นฉันจะอยู่นิ่งๆ เฉยๆ...
 
laeyoung 2025-02-09

ดูเหมือนว่าจะมีหลายอย่างที่ซ้อนทับกับ "10 สัญญาณของการล่มสลายของรัฐ" ที่ฮันเฟยจื่อเคยกล่าวไว้ครับ
 
GN⁺ 2025-02-09
ความเห็นบน Hacker News

  • ทำให้นึกถึงคำบรรยายของ Jonathan Blow ว่าซอฟต์แวร์ก็เสื่อมถอยได้เหมือนทุกอย่างอื่นหากไม่ดูแลรักษา

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

  • ทำให้นึกถึง "10 หลักการของการออกแบบที่ดี" ของ Dieter Rams

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

  • แชร์ประสบการณ์การทำงานในบริษัทช่วงยุค 2000

    • ใช้คอมพิวเตอร์หลายสิบเครื่องทำงาน สร้างห้องเซิร์ฟเวอร์ และสร้าง SAN สำหรับเก็บข้อมูล 3TB
    • ประสานงานระหว่างเครื่องต่างๆ เพื่อรันสคริปต์ Object Rexx ด้วยตัวตั้งตารางงาน VB6 ที่พัฒนาขึ้นเอง
    • ใช้ load balancer ภายใน, เว็บเซิร์ฟเวอร์, เมลเซิร์ฟเวอร์, FTP เซิร์ฟเวอร์ เพื่อรับส่งไฟล์ และใช้ซอฟต์แวร์ที่พัฒนาขึ้นเอง
    • ตอนนี้สามารถสร้างสภาพแวดล้อมทั้งหมดขึ้นใหม่ได้ภายในไม่ถึงสัปดาห์ผ่านไฟล์ yaml และบริการคลาวด์
    • สถาปัตยกรรมเซิร์ฟเวอร์ถูก "ทำให้เป็นนามธรรม"
    • มีคำวิจารณ์เรื่อง backward compatibility ว่าเป็นหนึ่งในปัญหาของ Windows
    • Apple ตัด backward compatibility ย้ายผ่านโปรเซสเซอร์มาแล้ว 5 รุ่น และตัดความเข้ากันได้ของโค้ด 32 บิตบนชิป ARM

  • มีความเห็นที่ขัดแย้งกันอยู่มาก

    • ควรรักษา backward compatibility โดยไม่สร้างความซับซ้อน
    • ควรหลีกเลี่ยง dependency tree ขนาดมหึมา และสร้างวงล้อขึ้นใหม่ด้วยตัวเอง
    • วิธีเดียวที่จะตอบโจทย์ทุกความต้องการได้คือไม่ให้ทุกคนเขียนโค้ด
    • วันหนึ่งมีความหวังแบบนั้นอยู่บ้าง แต่ก็ไม่ได้ภูมิใจกับมัน

  • แชร์ประสบการณ์จากงานแรก

    • เขียนซอฟต์แวร์ด้วย C ซึ่งในเวลานั้นเป็นภาษาเดียวที่ใช้เขียนซอฟต์แวร์เชิงพาณิชย์ได้อย่างสมจริง
    • มีเพียงคนเดียวที่ทำ build ได้ ใช้เครื่องมือ build เชิงพาณิชย์ และเขาก็เป็นคนเดียวที่ใช้เครื่องมือนั้นเป็น
    • การ build ใช้เวลาหลายชั่วโมง
    • ตอนนั้นเราคิดว่าเราทำได้ดีแล้ว

  • ความเห็นว่าทำไมเราถึงกำลังทำลายซอฟต์แวร์

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

  • ทุกคำกล่าวล้วนเป็นการแลกเปลี่ยน

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

  • ชื่นชม antirez แต่คิดว่าโพสต์นี้เต็มไปด้วยคำกล่าวสั้นๆ ที่ฟังดูดีแต่ไม่อาจยืนหยัดในวงถกเถียงได้

    • ตัวอย่าง: มือใหม่ไม่ควรสร้างวงล้อขึ้นใหม่
    • พวกเขาควรใช้เครื่องมือที่มีอยู่ในบริบทนั้นๆ
    • หากอยากทดลอง ก็ควรเขียนคอมไพเลอร์ของตัวเอง
    • แต่ไม่ควรนำมันไปใช้ในระบบ production
    • backward API compatibility ในหลายกรณีเป็นการตัดสินใจทางธุรกิจ
    • การขึ้นต้นทุกประโยคด้วย "เรากำลังทำลายซอฟต์แวร์" ไม่ได้ช่วยอะไร
    • มันฟังมืดมนเกินความเป็นจริงมาก

  • ความเห็นเรื่องกราฟความซับซ้อน/กราฟการพึ่งพา

    • กราฟความซับซ้อน/การพึ่งพาของแอปแบบสุ่มๆ นั้นบ้าคลั่งอย่างแท้จริง
    • แม้จะไม่รวมเฟิร์มแวร์และ OS แต่ก็ใกล้เคียงพอแล้ว
    • ต้องแก้ปัญหา transitive dependency
    • มองว่า OS (Win32 API, Linux syscalls) เป็น hard dependency เพียงอย่างเดียวของทุกสิ่งที่เขียนด้วย C
    • หากเปลี่ยนไปใช้ Java/Python ก็จะควบคุมเลเยอร์นี้ไม่ได้
    • การเขียนโค้ดไม่กี่ร้อยบรรทัดให้เหมาะกับสถานการณ์เฉพาะ โดยไม่พึ่งทุกไลบรารี เป็นสิ่งจำเป็น
    • ภาระการบำรุงรักษาจะเพิ่มขึ้น แต่ dependency ก็ต้องบำรุงรักษาเช่นกัน
    • มันอาจมี API ที่ไม่ดี, ทำลายความเข้ากันได้แบบสุ่ม, ถูกทิ้งร้าง หรือกลายเป็นมัลแวร์ได้
    • ขนาดโค้ดสูงสุดส่วนตัวสำหรับโปรเจ็กต์ที่ยังมีประโยชน์คือ Java/JS/Python ราว 5-10KLOC
    • สามารถรีวิวได้ภายในไม่กี่ชั่วโมง และแก้ไขได้ง่ายแม้ผ่านไปหลายปี

  • สิ่งที่กำลังทำลายซอฟต์แวร์

    • การสัมภาษณ์แบบ Leetcode, การพัฒนาตามเรซูเม่, การย้ายงานบ่อย, กลโกงการลงทุนเพื่อการเติบโต, การเล่นเกมกับเมตริก, การไล่ล่าการเลื่อนตำแหน่ง, โรงละครสปรินต์, การพูดโอ้อวดในทุกระดับของผังองค์กร, ความไม่แยแสของทั้งอุตสาหกรรม