เราไม่ได้พิเศษ (2021)

 (hillelwayne.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเปลี่ยนแปลงข้อกำหนดและความไม่แน่นอน งานซ้ำ ๆ และวิธีแก้ปัญหาเฉพาะหน้า ซึ่งมักถูกมองว่าเป็นลักษณะเฉพาะของซอฟต์แวร์ ก็พบได้ทั่วไปในวิศวกรรมแบบดั้งเดิมเช่นกัน และทั้งสองสาขามีจุดร่วมมากกว่าความแตกต่าง
  • การแบ่งว่า วิศวกรรมแบบดั้งเดิมคือ Waterfall ส่วนซอฟต์แวร์คือ Agile นั้นเรียบง่ายเกินไป การผลิตทางกายภาพมีต้นทุนการทำซ้ำสูงจึงมีการออกแบบล่วงหน้ามาก แต่สาขาอุโมงค์ โยธา และอิเล็กทรอนิกส์ก็ใช้ การพัฒนาแบบค่อยเป็นค่อยไปและการปรับตัวหน้างาน เช่นกัน
  • วิศวกรรมแบบดั้งเดิมก็เจอปัญหาที่ทำให้แผนพลิกได้ เช่น ซัพพลายเออร์ปิดกิจการ การเปลี่ยนแปลงอุปกรณ์การผลิต หรือคุณสมบัติดินที่ไม่คาดคิด จึงยากที่จะมองว่าซอฟต์แวร์ คาดการณ์ไม่ได้ เป็นพิเศษเพียงสาขาเดียว
  • ความแตกต่างจริงอยู่ที่ ความสม่ำเสมอสูงและการเปลี่ยนแปลงที่รวดเร็ว ของซอฟต์แวร์ รวมถึงข้อจำกัดที่ยืดหยุ่นกว่าโดยเปรียบเทียบ ผลิตภัณฑ์ทางกายภาพต้องรับมือกับความแปรปรวนและการสึกหรอของวัสดุ ข้อจำกัดแบบแข็ง เช่น ความแข็งแรงและขนาด และการเปลี่ยนแปลงที่ย้อนกลับได้ยาก
  • การแก้ไขได้เร็วทำให้การทดลองและตรวจสอบง่ายขึ้น แต่ก็อาจกดดันให้ใช้ โค้ดเลี่ยงปัญหา เพื่อชดเชยข้อบกพร่องทางกายภาพได้เช่นกัน สาขาวิศวกรรมต่าง ๆ สามารถเรียนรู้วิธีออกแบบ ตรวจสอบ และทำอัตโนมัติจากกันและกันได้

เหตุผลปกป้องแนวคิดว่าซอฟต์แวร์พิเศษ

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

ความแตกต่างห้าข้อที่มักถูกหยิบยก

  • หากปฏิบัติต่อวิศวกรรมแบบดั้งเดิมทั้งหมดเหมือนเป็นสาขาเดียว หรือ เหมารวมว่าเท่ากับวิศวกรรมโยธา ความแตกต่างระหว่างสาขาย่อยต่าง ๆ จะหายไป
  • สิ่งที่มักถูกยกเป็นความแตกต่างทั่วไปของซอฟต์แวร์กับวิศวกรรมแบบดั้งเดิม มีดังนี้
    • วิศวกรรมแบบดั้งเดิมเหมาะกับ Waterfall ส่วนซอฟต์แวร์เหมาะกับ Agile
    • วิศวกรรมแบบดั้งเดิมคาดการณ์ได้ แต่ซอฟต์แวร์คาดการณ์ได้ยาก
    • วิศวกรรมส่วนใหญ่คือการผลิต ส่วนโค้ดคือการออกแบบ ดังนั้น “โค้ดก็คือการออกแบบ”
    • วิศวกรรมแบบดั้งเดิมเข้มงวดกว่าวิศวกรรมซอฟต์แวร์
    • ซอฟต์แวร์เคลื่อนไหวเร็วกว่าวิศวกรรมแบบดั้งเดิมมาก
  • บางข้อมีความแตกต่างจริงอยู่ แต่ส่วนใหญ่ผิดหรือ ขาดบริบทสำคัญ ที่จำเป็นต่อการตัดสิน

การแบ่งอย่างง่ายเป็น Waterfall กับ Agile

  • ตามเรื่องเล่าที่แพร่หลาย Winston Royce สร้าง Waterfall ขึ้นในปี 1970 โดยอ้างอิงกระบวนการก่อสร้าง และวิธีนี้ซึ่งเปราะบางต่อการเปลี่ยนแปลงข้อกำหนด ถูกแทนที่ด้วย Agile Manifesto ในปี 2001
  • Waterfall จริง ๆ ไม่ได้เข้มงวดหรือแพร่หลายเท่าภาพจำในปัจจุบัน
    • นักพัฒนาในทศวรรษ 1970–1980 ใช้แบบจำลอง เชิงค่อยเป็นค่อยไป หลายแบบ เช่น แผนชั่วคราว Spiral Model หรือ V Model
    • Agile ใกล้เคียงกับผลลัพธ์ตามธรรมชาติของกระแสในยุคนั้น มากกว่าจะเป็นการปฏิวัติแบบตัดขาด
  • เป็นความจริงที่วิศวกรรมแบบดั้งเดิมใช้การออกแบบล่วงหน้าและเวลาทดสอบแยกต่างหากมากกว่า แต่สาเหตุมาจาก เศรษฐศาสตร์ของต้นทุนการทำซ้ำ มากกว่าความแข็งทื่อของ Waterfall
    • ยิ่งการทำซ้ำใช้เวลาและค่าใช้จ่ายมาก ก็ยิ่งสมเหตุสมผลที่จะวางแผนงานแต่ละครั้งให้นานขึ้น
    • หากแผงวงจรไม่ทำงานตั้งแต่แรก ก็ต้องส่งกลับไปโรงงาน และอาจเพิ่มค่าใช้จ่ายหลายพันปอนด์พร้อมกำหนดการอีก 2 สัปดาห์
  • ขอบเขตระหว่างการออกแบบกับการนำไปทำจริงก็ไม่ชัดเจน
    • แบบจำลองย่อส่วนของวิศวกรโยธา หรือ โมเดลดินเหนียวขนาดจริง ที่วิศวกรยานยนต์ทำขึ้นเพื่อทดสอบสุนทรียศาสตร์และอากาศพลศาสตร์ อาจมองได้ทั้งเป็นการออกแบบและการนำไปทำจริง
  • อุตสาหกรรมอื่นก็มีวิธีที่คล้าย Agile
    • วิธีการขุดอุโมงค์แบบออสเตรีย พึ่งพาการพัฒนาแบบทำซ้ำและการรับมือเฉพาะหน้าหน้างาน
    • Handbook of Industrial Engineering เน้นความร่วมมือข้ามแผนกและฟีดแบ็กลูกค้าที่รวดเร็ว
    • วิศวกรรมโยธาเอง เมื่อเริ่มก่อสร้างแล้ว ก็ขยับไปสู่การสื่อสารแบบเปิดและการปรับตัวเพื่อจัดการปัญหาหน้างาน

วิศวกรรมแบบดั้งเดิมก็คาดการณ์ได้ยาก

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

ข้ออ้างว่า “โค้ดก็คือการออกแบบ”

  • “โค้ดก็คือการออกแบบ” เป็นปฏิกิริยาตอบโต้ความคิดที่ว่า แค่สร้างโมเดลสมบูรณ์แบบด้วย UML แล้วสร้างโค้ดอัตโนมัติจากมันก็พอ
  • Nick Coghlan นักพัฒนาหลักของ CPython และอดีตวิศวกรบูรณาการระบบของ Boeing มองว่านี่เป็นความแตกต่างพื้นฐานระหว่างซอฟต์แวร์กับงานเดิมของเขา
    • เขาประสานทีมระบบอิสระหลายทีม เช่น เครื่องบิน ระบบควบคุมการจราจรทางอากาศ และแผงสายอากาศ ให้สร้าง อินเทอร์เฟซที่เข้ากันได้
  • สำหรับวิศวกรเซมิคอนดักเตอร์ กระบวนการทั้งหมดตั้งแต่แผนผังวงจรแรกของ CPU ไปจนถึงชิปสุดท้ายที่ออกจากโรงหล่อ ล้วนเป็นการออกแบบ และการผลิตอาจเป็นขั้นตอนที่ค่อนข้างง่ายในการส่งแบบออกไปแล้วรับชิปกลับมา
  • หากชิปหรือผลิตภัณฑ์เครื่องกลที่เสร็จแล้วมีข้อบกพร่อง ก็ต้องเปลี่ยนการออกแบบ ดังนั้นการออกแบบกับการผลิตจึงไม่ได้แยกจากกัน
    • “fettling” ในวิศวกรรมเครื่องกลคือการปรับการออกแบบให้เข้ากับความไม่สมบูรณ์เล็ก ๆ ในกระบวนการผลิต
    • เกิดวงจรที่การผลิตเปลี่ยนการออกแบบ และการออกแบบที่เปลี่ยนแล้วก็ย้อนกลับไปเปลี่ยนการผลิตอีกครั้ง
  • ขอบเขตของการออกแบบ เองก็ไม่ชัดเจน
    • ภาพรวมสถาปัตยกรรม ข้อกำหนดแบบ formal และแบบรายละเอียด ล้วนเป็นการออกแบบคนละระดับ
    • ในโครงการซับซ้อน เช่น แบบออกแบบสะพาน มีรายละเอียดหลายชั้นที่ทำซ้ำกัน
  • ลักษณะที่ใช้เวลาและค่าใช้จ่ายส่วนใหญ่ไปกับการก่อสร้างนั้น เป็นเรื่องของวิศวกรรมโยธาบางส่วนที่เน้นสะพานและอาคาร ไม่อาจเหมารวมว่าเป็นภาพแทนของวิศวกรรมแบบดั้งเดิมทั้งหมดได้
  • วิศวกรรมโยธาเองก็ครอบคลุมหลายด้านที่จำเป็นต่อการสร้างเมือง จึงไม่ควรถูกจำกัดไว้แค่สะพานและอาคาร

ความเข้าใจผิดเรื่องความเข้มงวด

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

ความแตกต่างจริงข้อ 1: ความสม่ำเสมอ

  • ซอฟต์แวร์ถูกประกอบขึ้นทั้งหมดด้วยตรรกะ และไม่สึกหรอเหมือนสปริง จึง สม่ำเสมอ กว่าผลลัพธ์ของวิศวกรรมสาขาอื่นมาก
    • หากฟังก์ชันจัดเรียงจัดเรียงรายการตัวเลขที่ไม่ใช่อินพุตผิดปกติได้เพียง 95% ก็คงยากจะยอมรับว่าเป็นพฤติกรรมปกติ
  • วัสดุและชิ้นส่วนทางกายภาพมีความแปรปรวนจากค่าทฤษฎีอยู่เป็นพื้นฐาน
    • ตัวต้านทานมีให้ตั้งแต่ 1Ω ไปจนถึงหลายร้อยล้าน Ω และใช้แถบสีระบุค่าความต้านทานตามทฤษฎี
    • แถบสีเขียว น้ำเงิน แดง หมายถึง 5,600Ω แต่หากมีแถบค่าความคลาดเคลื่อนสีทอง ค่าจริงอาจต่างได้สูงสุด 5%
    • ในตัวต้านทานแบบเดียวกัน 100 ตัว บางตัวอาจเป็น 5,320Ω บางตัวอาจเป็น 5,880Ω จึงต้องวัดทีละตัว
    • เมื่อรวมการสึกหรอและการเปลี่ยนแปลงอุณหภูมิ ความแปรปรวนก็ยิ่งซับซ้อนขึ้น
  • วัสดุทางกายภาพทุกชนิดมีปัญหาคล้ายกัน และผู้ผลิตสกรู Fastenal ก็เตือนว่า อย่าใช้สกรูสเตนเลสกับแผ่นอะลูมิเนียม

ความแตกต่างจริงข้อ 2: ความเร็วในการเปลี่ยนแปลง

  • ซอฟต์แวร์สามารถเปลี่ยนแปลงได้เร็วกว่าระบบวิศวกรรมอื่นมาก
    • ในวิศวกรรมแบบดั้งเดิม หลังแชร์สเปกแล้ว ต้องรอการผลิตและติดตั้งจากโรงงานหรือโรงกลึง รวมถึงการทดสอบหลายสัปดาห์
    • การเปลี่ยนแปลงทางวิศวกรรมบางอย่างมีต้นทุนชัดเจน เช่น งบประมาณหายไป 5,000 ดอลลาร์ ต่อครั้ง
    • โค้ดสามารถเปลี่ยนแล้วรันเทสต์ทั้งหมดได้ภายในไม่กี่วินาที
  • ในบรรดาสาขาที่ไม่ใช่ซอฟต์แวร์ วิศวกรรมเคมีมีความเร็วใกล้เคียงที่สุด แต่การเปลี่ยนรอบในระดับ 1 นาทีก็ยังเป็นสิ่งที่ยากจะจินตนาการ
  • เหตุผลที่วิศวกรรมสาขาอื่นใช้ซอฟต์แวร์ในเครื่องมือออกแบบและการจำลองมากขึ้น ก็เพราะสามารถทำต้นแบบไอเดียได้รวดเร็วก่อนนำไปทำจริง
  • ความสามารถในการเปลี่ยนแปลงได้เร็วก็มีด้านลบ
    • หากปัญหาในอุปกรณ์อิเล็กทรอนิกส์หรือเครื่องกลไม่ได้รับการแก้ไขอย่างสมบูรณ์ แรงกดดันจะไปรวมที่วิศวกรซอฟต์แวร์ให้ชดเชยด้วย วิธีเลี่ยงปัญหาในโค้ด
  • การพึ่งพาเช่นนี้อาจนำไปสู่ผลลัพธ์ร้ายแรง
    • เหตุเครื่องบิน Boeing 737 MAX ตกสองครั้งในปี 2019 ทำให้มีผู้เสียชีวิตมากกว่า 300 คน
    • การสอบสวนชี้ว่าเกิดจากบั๊กใน MCAS ซึ่งเป็นระบบควบคุมการบินอัตโนมัติ
    • Boeing เพิ่ม MCAS แทนที่จะแก้ ปัญหาคุณสมบัติทางอากาศพลศาสตร์ ของเครื่องบินที่พบภายหลังด้วยการออกแบบทางกายภาพ

ความแตกต่างจริงข้อ 3: ข้อจำกัดและการเปลี่ยนแปลงที่ย้อนกลับไม่ได้

  • ผลิตภัณฑ์วิศวกรรมแบบดั้งเดิมมี ขีดจำกัดทางกายภาพ ที่ต้องปฏิบัติตาม เช่น น้ำหนัก ความแข็งแรง ความต้านทาน และอุณหภูมิ
    • ในการออกแบบชิป แม้แต่เผื่อเวลาในระดับเศษส่วนของนาโนวินาทียังต้องเจรจากับทีมอื่นได้
  • ซอฟต์แวร์ก็มีข้อจำกัด เช่น ความจุหน่วยความจำ การตอบสนอง 10 รอบของเซ็นเซอร์ หรือข้อจำกัดการเรียก API
  • อย่างไรก็ตาม ข้อจำกัดของซอฟต์แวร์มักเป็น soft constraint ที่สถานะจะแย่ลงเมื่อเกินขอบเขต จึงอาจปรับเส้นแบ่งเล็กน้อยเพื่อความเร็วในการพัฒนาหรืออัลกอริทึมที่เรียบง่ายได้
  • ข้อจำกัดของวิศวกรรมแบบดั้งเดิมมักเป็น hard constraint ที่หากเกินแล้วผลิตภัณฑ์จะไม่ทำงาน
    • หากกล่องกว้างขึ้นเพียงเล็กน้อย ก็ผ่านประตูไม่ได้
  • ในกรณีที่ screw conveyor ที่จะติดตั้งในสถานีขุดเจาะน้ำมันสูงกว่าห้องอยู่ไม่กี่นิ้ว ไม่สามารถลดขนาดอุปกรณ์หรือยกเพดานได้เพราะมีอีกสี่ชั้นอยู่ด้านบน
    • จึงเจาะรูบนเพดานเพื่อนำอุปกรณ์เข้าไป และติดตั้งกล่องรอบรูเพื่อไม่ให้คนชั้นบนสะดุด
    • การเปลี่ยนแปลงนี้คงอยู่ถาวรในโครงสร้างของสถานี และต้องคำนึงถึงต่อไปในการเปลี่ยนแปลงทั้งหมดภายหลัง
  • วิศวกรซอฟต์แวร์สามารถย้อนคืนวิธีแก้ปัญหาเฉพาะหน้าได้ แต่วิธีแก้ปัญหาเฉพาะหน้าทางกายภาพในวิศวกรรมแบบดั้งเดิมมักกลายเป็น โครงสร้างถาวร ได้ง่าย

ต่างกัน แต่ไม่ได้พิเศษ

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

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นบน Lobste.rs

  • เห็นด้วยกับหลายส่วนของบทความ แต่ก็มองโลกในแง่ดีเกินไปเกี่ยวกับ ความเข้มงวด ของวิศวกรรมซอฟต์แวร์ ทุกวันนี้การมี automated testing โดยเฉพาะชุดทดสอบที่แข็งแรงหลายชั้นเป็นส่วนหนึ่งของกระบวนการพัฒนา ยังไม่ใช่เรื่องที่ถือเป็นมาตรฐานเสมอไป และก็ยังมีทั้งกรณีที่มองว่านักพัฒนาเป็นด่านตรวจเพียงด่านเดียว หรือองค์กรเห็นว่ากระบวนการเป็นอุปสรรคแล้วตัดทิ้งไป
    อุตสาหกรรมนี้มักประดิษฐ์วงล้อขึ้นใหม่ทุกไม่กี่ปีโดยไม่ได้ทำให้ best practice ที่พิสูจน์แล้วเป็นระบบ สิ่งที่ถูกทำให้เป็นมาตรฐานก็มักเป็นแค่คำศัพท์ร่วมแบบหลวม ๆ ที่แต่ละบริษัทตีความต่างกันมาก เช่น ‘Agile’ หรือ ‘testing’ นักพัฒนาจำนวนมากคิดว่า testing หมายถึงแค่ unit test บางส่วนอาจนับรวม component และ integration test ด้วย แต่ในบางบริษัทก็ผ่านแค่เท่านั้นแล้วปล่อยขึ้น production เลย
    อย่างที่เคยเขียนไว้ในคอมเมนต์ ก่อนหน้านี้ ในองค์กรที่ดี code review ควรเป็นเพียงหนึ่งในหลายกระบวนการที่รับผิดชอบคุณภาพ และไม่ควรเป็นประตูด่านเดียวที่ตัดสินการ deploy ขึ้น production ยังมีทีมและบริษัทจำนวนมากที่แทบไม่มีกระบวนการประกันคุณภาพหลัง merge โค้ดแล้ว
    ไม่ได้หมายความว่าควรทำให้ความรับผิดชอบเจือจางลง แต่ควร ฝังคุณภาพไว้ในกระบวนการ ตั้งแต่ก่อนเริ่มเขียนโค้ด ต้องมีทั้ง Three Amigos session ที่หลายสายงานร่วมกันคุยเรื่องสเปกและข้อกำหนด, test-driven development, static analysis ที่ผสานอยู่ใน IDE และในแต่ละด่านตรวจ, รวมถึงผู้เชี่ยวชาญด้าน quality assurance และ test automation ที่แยกจากนักพัฒนา
    ในวิศวกรรมโยธา จะไม่ปล่อยให้คนคนเดียวเป็นทั้งผู้ออกแบบ ผู้ก่อสร้าง และผู้รับผิดชอบเพียงคนเดียวของสะพาน มีหลายขั้นตอนทั้งการคำนวณ การจัดทำเอกสาร การตรวจทานซ้ำ การอนุมัติจากรัฐ การ audit และ inspection ระหว่างก่อสร้าง และแม้แต่บ้านเดี่ยวก็ยังต้องผ่านแบบ อนุมัติ ใบอนุญาต และการตรวจสอบ วิบัติทางวิศวกรรมเองก็มักเป็นความล้มเหลวของทั้งกระบวนการที่หยุดปัญหาไว้ไม่ได้ในหลายจุด
    ถ้าจะเปรียบการพัฒนาซอฟต์แวร์กับวิศวกรรมโยธา ก็ต้องยอมรับด้วยว่าระดับของกระบวนการนั้นต่างกันอย่างสิ้นเชิง บ่อยครั้งที่สุดมันใกล้เคียงกับผู้พัฒนาโครงการบ้านจัดสรรที่พยายามสร้างบ้านให้ถูกที่สุดพร้อมหาทางเลี่ยงข้อกำหนดทางกฎหมายเสียมากกว่า

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

  • ทั้งสามบทความยอดเยี่ยมมาก แนะนำให้อ่าน และยังดูการถกเถียงก่อนหน้านี้ได้ด้วย
    https://lobste.rs/s/fv8swh/crossover_project (ประกาศโครงการ)
    https://lobste.rs/s/lmvroa/are_we_really_engineers (กลับมาถกเถียงอีกครั้ง)
    https://lobste.rs/s/8j8sdc/are_we_really_engineers (กลับมาถกเถียงอีกอีกครั้ง)
    การบรรยายนี้ ของ Glenn Vanderburg ก็เกี่ยวข้องมากเช่นกัน

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

  • สงสัยว่า ~hwayne ปิดการใช้งานบัญชีไปทำไม