วิกฤตซอฟต์แวร์
(wryl.tech)- คำว่า “software crisis” ที่เกิดขึ้นจากการประชุม NATO Software Engineering conference ปี 1968 กลายเป็นสำนวนที่ใช้น้อยลงแล้ว แต่ภาระที่เกิดจากความซับซ้อนและ abstraction ของซอฟต์แวร์ยังคงอยู่
- Edsger Dijkstra มองไว้ในการบรรยายรับรางวัล Turing Award ปี 1972 ว่า แม้ ประสิทธิภาพและความซับซ้อนของฮาร์ดแวร์ จะเพิ่มขึ้นอย่างรวดเร็ว แต่วิธีการเชิงองค์กรในการรับมือกลับตามไม่ทัน
- การทำให้คอมพิวเตอร์ส่วนบุคคลกลายเป็นธุรกิจเชิงพาณิชย์และรอบการออกผลิตภัณฑ์ที่รวดเร็ว ทำให้ผู้ใช้ต้องการความจุมากขึ้นก่อนที่จะได้เรียนรู้เครื่องมืออย่างเพียงพอ และ “abstract it away” ก็กลายเป็นปฏิกิริยาเริ่มต้น
- ชั้น abstraction ที่ซ้อนกันสร้างต้นทุนด้านประสิทธิภาพและโมเดลทางความคิดที่บิดเบี้ยว อีกทั้งทำให้เข้าถึงความสามารถพื้นฐานของเครื่อง เช่น กราฟิกและเสียง ได้ยากขึ้น
- ทางแก้ไม่ใช่การย้อนกลับไปยังแพลตฟอร์มที่มีข้อจำกัดในอดีต แต่คือการ ลดจำนวนชั้น abstraction และรักษาข้อมูลระหว่างชั้นต่าง ๆ เพื่อคืนอำนาจในการควบคุมให้ผู้ใช้เครื่องมือ
ความตระหนักถึงปัญหาในปี 1968 ยังไม่สิ้นสุด
- คำว่า “software crisis” ถูกบัญญัติขึ้นในการประชุม NATO Software Engineering conference ครั้งแรกเมื่อปี 1968
- การประชุมเหล่านี้เป็นหนึ่งในความพยายามยุคแรก ๆ ในการรวบรวมและจัดระบบแนวปฏิบัติด้านการเขียนโปรแกรมสำหรับเครื่องคำนวณอัตโนมัติ
- ภารกิจ Apollo 11 ถูกปล่อยขึ้นในวันที่ 16 กรกฎาคม 1969 และการประชุม NATO Software Engineering conference ครั้งสุดท้ายจัดขึ้นในเดือนตุลาคมปีเดียวกัน
- Edsger Dijkstra ระบุในการบรรยายรับรางวัล Turing Award ปี 1972 ว่าสาเหตุของวิกฤตอยู่ที่ เครื่องจักรที่ทรงพลังขึ้น และการขาดวิธีการเชิงองค์กรที่จะรับมือกับมัน
- เขาได้กล่าวในทำนองว่า “ตอนที่ยังไม่มีเครื่องจักร การเขียนโปรแกรมไม่ใช่ปัญหา เมื่อมีคอมพิวเตอร์กำลังต่ำอยู่ไม่กี่เครื่อง มันเป็นปัญหาเล็กน้อย และเมื่อมีคอมพิวเตอร์ขนาดมหึมา การเขียนโปรแกรมก็กลายเป็นปัญหาขนาดมหึมาเช่นกัน”
- ปัจจุบัน ในการปฏิบัติงานด้านการเขียนโปรแกรม คำว่า “software crisis” ไม่ได้ปรากฏให้เห็นบ่อยนัก
- ความก้าวหน้าของภาษาใหม่ ๆ และวิธีการเชิงองค์กร รวมถึงระยะห่างทางเวลาจากปัญหาในอดีต ทำให้อุตสาหกรรมรู้สึกโล่งใจในระดับหนึ่งว่าได้แก้ปัญหาไปแล้ว
- แต่ความโล่งใจนั้นยังคงเป็นสภาวะที่ใกล้เคียงกับ ความพ่ายแพ้และการยอมรับ มากกว่าความสบายใจอย่างแท้จริง
Abstraction ทำให้อำนาจควบคุมของผู้ใช้ห่างออกไป
- ความก้าวหน้าของคอมพิวติ้งยุคแรกและสาขาใกล้เคียงเกิดขึ้นในเครื่องและสภาพแวดล้อมที่การสร้าง หอคอย abstraction มีต้นทุนโดยตรง
- เมื่อไม่สามารถหลีกเลี่ยงข้อจำกัดได้ ก็เกิดวัฏจักรการเติบโตที่ตามมาด้วยการอัปเกรดฮาร์ดแวร์
- ในความเป็นจริง เรามักต้องการความจุที่มากขึ้นก่อนที่จะเข้าใจข้อจำกัดปัจจุบันอย่างเพียงพอ
- หลังจากคอมพิวเตอร์ส่วนบุคคลถูกทำให้เป็นธุรกิจเชิงพาณิชย์ บริษัทที่ขายอุปกรณ์ไม่ได้รอให้ผู้ใช้เชี่ยวชาญผลิตภัณฑ์อย่างสมบูรณ์ และวัฏจักรการเติบโตก็เร็วขึ้นเรื่อย ๆ
- พร้อมกับรอบการเปิดตัวฮาร์ดแวร์ที่รวดเร็ว “abstract it away” จึงกลายเป็นกรอบความคิดพื้นฐาน
- หากผลักรายละเอียดที่ไม่ชอบเข้าไปไว้ในโครงสร้างที่ควบคุมได้ ก็จะได้ความเป็นอิสระบางส่วนมา แต่ต้องแลกด้วยต้นทุนด้านประสิทธิภาพ
- abstraction หลายชั้นและการซ่อนข้อมูลย้ายปัญหาการสร้างซอฟต์แวร์ขึ้นไปยังชั้นที่สูงกว่า
- ชั้นเหล่านี้ถูกรวมเข้าไปในซอฟต์แวร์ที่จำเป็นต่อการใช้คอมพิวเตอร์ และซอฟต์แวร์ที่ขับเคลื่อนชีวิต
- อุตสาหกรรมซอฟต์แวร์ที่กว้างขึ้นเร่งอิทธิพลของรอบการเปิดตัวและทุนให้เร็วขึ้น และพื้นที่ที่นักพัฒนารายบุคคลจะเข้าถึงได้ง่ายก็อ่อนแรงลง
- วิกฤตซอฟต์แวร์ไม่ได้เป็นปัญหาของนักพัฒนาเท่านั้น แต่ยังส่งต่อไปถึง ผู้ใช้ซอฟต์แวร์ ด้วย
- ผู้ใช้แทบไม่มีอำนาจควบคุมนอกเหนือจากฟังก์ชันที่ผู้เขียนอนุญาตไว้
- ความจริงที่ว่าทั้งการสร้างและการใช้ซอฟต์แวร์ล้วนเป็นกิจกรรมของมนุษย์เริ่มเลือนรางลง
จุดหมายไม่ใช่อดีต แต่คือชั้นที่ตื้นกว่า
- ทางแก้ที่เสนอไม่ใช่การกลับไปใช้แพลตฟอร์มที่มีข้อจำกัดมากกว่าเดิม
- ควรจำกัด จำนวนชั้น abstraction ที่อนุญาตให้มี
- จำเป็นต้องรักษาข้อมูลระหว่างชั้นต่าง ๆ
- โมเดลการเขียนโปรแกรม อินเทอร์เฟซผู้ใช้ และฮาร์ดแวร์พื้นฐานควรตื้นและประกอบเข้าด้วยกันได้
- ความเคลื่อนไหวอย่างชุมชน Handmade, Permacomputing และเรโทรคอมพิวติ้ง เชื่อมโยงไปสู่กระแสที่ช่วยเพิ่มการตระหนักรู้เกี่ยวกับวิกฤตซอฟต์แวร์
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สวัสดีครับ ผมเป็นผู้เขียนบทความนี้ ผมคิดว่าสำคัญที่จะต้องชี้แจงส่วนที่มักถูกเข้าใจผิดในบทความนี้ จึงขอสรุปไว้ตรงนี้ ผมไม่ได้คัดค้าน การทำ abstraction เอง แต่คัดค้านการนำไปใช้โดยไม่มีข้อจำกัด
แนวทางแก้ไขก็ไม่ใช่การย้อนกลับไปสู่แพลตฟอร์มที่มีข้อจำกัดมากกว่า และไม่ใช่ข้อเรียกร้องแบบให้ผู้ใช้ “อดทนแล้วทำตัวให้เป็นสายเทคนิคมากขึ้น” หัวใจในการทำความเข้าใจวิกฤตซอฟต์แวร์คือเส้นโค้งของ “ความเชี่ยวชาญแพลตฟอร์ม” กับ “วงจรการเติบโต/การปล่อยเวอร์ชัน” ตลอดกว่า 40 ปีที่ผ่านมา นอกจากบางสาขาแล้ว เส้นโค้งเหล่านี้แยกห่างกันออกไป และเราแก้ไม่ทันตอนที่มันยังอยู่ใกล้กัน แต่ช่วงเวลาที่ดีที่สุดเป็นอันดับสองก็คือตอนนี้
มีปฏิกิริยาว่าบทความนี้เป็น clickbait ด้วย แต่นี่เป็นโพสต์แรกในบล็อกของผม และเป็นความคิดเกี่ยวกับสถานการณ์ที่ผมเผชิญในฐานะนักพัฒนา อารมณ์ความรู้สึกคล้าย ๆ กันนี้เห็นได้ในหลายชุมชน โดยเฉพาะในบางชุมชนที่มีพื้นฐานแบบ counterculture ในหลากหลายรูปแบบ ผมตั้งใจจะเขียนบทความต่อเนื่องแนว “ผมจะแสดงให้ดูว่าทำอย่างไร” เพราะอยากแสดงให้เห็นส่วนหนึ่งของการแก้ปัญหา ผมทำคนเดียว จึงขอเวลาและความกรุณาด้วยครับ
ตราบใดที่มีคนสร้างซอฟต์แวร์อยู่เป็นล้าน ๆ คน เราไม่สามารถแก้ปัญหานี้ให้หมดจดได้ ย่อมต้องมีบางส่วนที่เห็นต่างกับผู้เขียน และไม่ใช่ทุกคนจะเชี่ยวชาญได้เท่าผู้เขียน ดังนั้นบทความนี้จึงอ่านได้ว่า สุดท้ายแล้วกำลังบอกว่าควรยกระดับเกณฑ์ของ “abstraction ที่ยอมรับได้” ให้สูงกว่าปัจจุบัน
การพูดภาพใหญ่เป็นเรื่องง่าย แต่ถ้าลองลงไปดูพื้นที่เฉพาะที่ถูกมองว่า “ถูกทำให้เป็น abstraction มากเกินไป” จริง ๆ ก็น่าจะทำให้ถ่อมตัวลงได้มาก เพราะ “abstraction ที่มากเกินไป” แบบนั้นมักมีเหตุผลที่ค่อนข้างดีอยู่เบื้องหลัง และวิศวกรในพื้นที่นั้น ๆ ก็รู้สึกว่าสถานการณ์ abstraction นั้นรกเหมือนกัน แต่เห็นว่ามันจำเป็น หรือการแก้ไขนั้นไม่สมจริง
ตัวอย่างเช่น ซอฟต์แวร์จำนวนมากสร้างขึ้นโดยวาง abstraction ที่ดีไว้บน abstraction ระดับกลางที่ใช้กันอย่างแพร่หลาย เช่น Kubernetes ที่วางอยู่บน Linux, container runtime และโครงสร้างดั้งเดิมแบบ control plane / ชั้นการตั้งค่า / data plane เราอาจนำตรรกะทั้งหมดนี้ไป implement โดยตรงในระบบปฏิบัติการใหม่ได้ แต่ก็จะเกิดปัญหาความเข้ากันได้สำหรับผู้ใช้ ต่อให้สร้างได้ก็อาจไม่มีผู้ใช้ และถ้าเป็นเช่นนั้นก็ต้องกลับไป implement abstraction แย่ ๆ ที่พยายามหลีกเลี่ยงอยู่ดี ยิ่งไปกว่านั้น แนวทางแบบนั้นยังยากกว่ามากในการ implement ผมไม่ชอบการออกแบบของ Kubernetes จึงอยากแก้ปัญหานี้ แต่ผมมองว่าการทำด้วย “วิธีที่ถูกต้อง” นั้นยากหรือแพงเกินไปจนไม่คุ้มค่า
ขึ้นอยู่กับว่าคุณเข้ามาในวงการนี้เมื่อไรและมีพื้นเพอย่างไร abstraction ของคนรุ่นก่อน ๆ ก็มีความเป็นไปได้ไม่น้อยที่จะถูกผนวกเข้าเป็นแนวปฏิบัติที่ยอมรับกันแล้ว ตัวอย่างเช่น ครั้งหนึ่ง การใช้ระบบปฏิบัติการที่มีระบบไฟล์ทั่วไปเคยกลายเป็นสมมติฐานพื้นฐานที่ถือว่าเป็นเรื่องปกติ
ผมคิดว่าปัญหาที่พูดถึงตอนนี้ใกล้เคียงกับความยากลำบากเมื่อเข้ามาในวงการนี้ในปัจจุบันมากกว่า หากตั้งสมมติฐานว่าต้องเข้าใจ abstraction ทุกอย่างที่ถูกใช้โดยละเอียดจึงจะมีส่วนร่วมได้ ความรู้พื้นฐานที่ต้องมีก่อนก็สูงมาก มันอาจทำให้รู้สึกท่วมท้นได้ แต่ก็มีทางเลือกคือยอมรับ abstraction ไปก่อน จนกว่าจะสามารถเข้าใจได้ลึกขึ้น
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
อย่างไรก็ตาม ผมคิดว่าเหตุผลที่สถานการณ์นี้ไม่เปลี่ยนไปนั้นเป็นเรื่องเศรษฐศาสตร์อย่างชัดเจน ไม่ได้หมายความว่าซอฟต์แวร์ที่แย่นั้นถูกกว่า แต่การตัดมุมทำให้บุคคลหรือองค์กรประหยัดต้นทุนได้ในตอนนี้ และต้นทุนที่ใหญ่กว่าจะถูกผลักไปให้ตัวองค์กรเอง ลูกค้า หรือสังคมโดยรวมในภายหลัง จึงมีแรงจูงใจอย่างแรงกล้าต่อแนวปฏิบัติที่ถูกและแย่ อีกทั้งซอฟต์แวร์ยังยากที่จะนำมาตรฐานของวิศวกรรมสาขาอื่นมาใช้ จึงยากที่จะทำสัญญาหรือกฎระเบียบที่กำหนดให้ซอฟต์แวร์ต้องมีมาตรฐานหรือคุณภาพบางอย่าง
ทางออกเดียวที่พอจินตนาการได้ น่าจะเป็นการปฏิวัติทางเทคโนโลยีที่ทำให้สร้างซอฟต์แวร์ที่ดีกว่าและถูกกว่าด้วยเทคโนโลยีเดียวกันได้ พร้อมกันนั้นก็ทำให้ไม่สามารถสร้างซอฟต์แวร์ที่ถูกกว่าแต่แย่กว่าได้
มีซอฟต์แวร์มากเกินไปบนแพลตฟอร์มมากเกินไป และภูมิทัศน์ก็แตกกระจายมากจนพูดเป็นหลักทั่วไปได้ยาก บางโปรเจกต์โงนเงนและพังทลายลง ขณะที่บางโปรเจกต์ก็ทำงานได้ดี
มีซอฟต์แวร์ที่เป็นปฏิปักษ์ต่อผู้ใช้อยู่เหมือนกัน แต่นั่นคือเจตนาในการออกแบบ มีความเหยียดหยันและความโลภอยู่เบื้องหลัง ไม่ใช่เพราะโปรแกรมเมอร์ไม่รู้ว่าตัวเองกำลังทำอะไร แต่เพราะพวกเขาทำตามที่ถูกสั่ง
ผู้ใช้เองก็มีส่วนเร่งเรื่องนี้ แม้จะสร้างซอฟต์แวร์ดี ๆ ให้ก็ไม่สนใจ ผู้ใช้เรียกร้องสิ่งอื่นที่ไม่ใช่ซอฟต์แวร์ที่ดี ผู้ใช้หนึ่งคนที่ต้องการซอฟต์แวร์ที่ดี กลายเป็นเหยื่อของผู้ใช้ห้าสิบคนที่ไม่ได้ต้องการแบบนั้น ซอฟต์แวร์ตลาดมวลชนตอนนี้กลายเป็นวัฒนธรรมมวลชนไปแล้ว
Word ในตอนนั้นก็ไม่ได้ด้อยกว่ารุ่นปัจจุบันมากนักเมื่อเทียบกัน แต่ตอนนี้ Windows และ Office ต้องการดิสก์ 50–100GB แค่เพื่อให้ทำงานได้ เราได้อะไรมาแลกกับขนาดที่เพิ่มขึ้น 1000 เท่ากันแน่
มันบ้าบออย่างสิ้นเชิง แต่เราก็ปล่อยผ่านไปเฉย ๆ ระบบสมัยใหม่มีดิสก์, RAM, CPU เพิ่มขึ้นราว 5000–10000 เท่า และอินเทอร์เน็ตตามบ้านก็เร็วกว่าโมเด็มยุคแรก ๆ เป็นล้านเท่าตามตัวอักษร
บทความนี้ตั้งอยู่บนสมมติฐานว่า วิกฤตซอฟต์แวร์ มีอยู่จริงหรือเป็นปัญหาร้ายแรง โดยยกองค์ประกอบของวิกฤต เช่น งบประมาณบานปลาย กำหนดการล่าช้า ความไร้ประสิทธิภาพ คุณภาพต่ำ ไม่ตอบโจทย์ข้อกำหนด โปรเจกต์ที่จัดการไม่ได้ โค้ดที่บำรุงรักษายาก และการส่งมอบงานไม่ได้
แต่ถ้าตัดคำว่า “ซอฟต์แวร์” ออกไป จะมีกิจกรรมของมนุษย์สักกี่อย่างที่ไม่เจอปัญหาอย่างน้อยหนึ่งข้อในบรรดานี้ ในทางกลับกัน ซอฟต์แวร์ที่ดีมากจริง ๆ ก็มีอยู่ไม่น้อย เรามักเลือกมองแต่ความล้มเหลวและข้อบกพร่อง ส่วนความสำเร็จ แม้มันจะดีขึ้นเรื่อย ๆ ก็ถูกมองข้ามราวกับเป็นเส้นฐานที่ควรเป็นอยู่แล้ว
ตั้งแต่กดปุ่มเปิดคอมพิวเตอร์จนไปถึงเดสก์ท็อป เราก็ผ่าน abstraction ไปแล้วหลายร้อยชั้น แค่เดสก์ท็อปนั้นเองก็เป็นสิ่งของที่ซับซ้อนที่สุดในบรรดาเครื่องจักรที่เราจะโต้ตอบด้วยตลอดทั้งวัน เรื่องแบบนี้เกิดขึ้นทั่วโลกวันละหลายพันล้านครั้ง และโดยมากก็ผ่านไปได้โดยไม่มีปัญหา นี่ยังเป็นเพียงตัวอย่างเล็กมากเท่านั้น
เพียงแต่ผมคิดว่าแรงจูงใจที่แท้จริงของบทความแบบนี้ไม่ได้อยู่ที่รายการเหล่านั้น แต่อยู่ที่ความรู้สึกว่าทุกอย่างมันเกินกว่าจะรับมือได้ โปรแกรมเมอร์ที่มีประสบการณ์ควรต้องสร้างสมดุลระหว่างความรู้สึกท่วมท้นนั้นกับงานที่ต้องทำ กว่าจะมาถึงจุดนี้ต้องใช้เวลา แต่ผมเชื่อว่าสำคัญ ไม่มีทางที่ทุกอย่างจะถูกจัดระเบียบจนสมบูรณ์ และเราต้องยอมรับความจริงข้อนั้น
สำหรับซอฟต์แวร์ แทบไม่มีขีดจำกัดแบบนั้นนอกจากข้อจำกัดด้านประสิทธิภาพและหน่วยความจำ แต่ทั้งสองอย่างก็มักมีเหลือเฟือจนสามารถพอกขยะทับไปเรื่อย ๆ แล้วผ่านไปได้ พวกเราทุกคนเคยมีช่วงเวลาที่คิดหรือพูดว่า “นี่มันรันได้ยังไงกัน?” จนกว่าผู้ใช้จะไปเหยียบ edge case ที่ผิดพลาด เราก็ไม่รู้ว่าโค้ดข้างใต้นั้นเปราะบางแค่ไหน
“ลองปิดแล้วเปิดใหม่หรือยัง” คือหลักฐานของเรื่องนี้ ระบบซอฟต์แวร์มักเข้าสู่สถานะเสียที่ละเอียดอ่อนและไม่อาจรู้ได้ จนทางแก้มีเพียงล้างทุกอย่างแล้วเริ่มขึ้นใหม่ตั้งแต่ต้น เช่น หลังรับสายแล้วโทรศัพท์ยังสั่นต่อไปจนกว่าจะมีสายหรือข้อความถัดไปเข้ามา, บางส่วนของเว็บแอปโหลดไม่ครบ 100% ทำให้ตัวเลือกหายไป, หรือการจับคู่ Bluetooth ที่เดี๋ยวติดเดี๋ยวไม่ติด
การสื่อสารคือวิธีถ่ายทอดความเข้าใจและแก้ไขการขาดความเข้าใจ ส่วนความเข้าใจเป็นพื้นฐานของความสำเร็จในทุกงาน หากไม่มีความเข้าใจ อาการอย่างน้อยหนึ่งข้อข้างต้นก็จะปรากฏขึ้น แม้มีความเข้าใจก็ยังอาจเกิดขึ้นได้ แต่ก็อย่างน้อยมีเส้นทางไปสู่ความสำเร็จ
จากประสบการณ์ของผม ปัญหาส่วนใหญ่ในอุตสาหกรรมวิศวกรรมซอฟต์แวร์คือปัญหาเรื่องคน ไม่ใช่เทคโนโลยี ไม่ใช่ตัวเทคโนโลยีเอง และไม่ใช่กระบวนการ ดังนั้นการสื่อสารและความเข้าใจจึงจำเป็นต่อความสำเร็จ
เมื่อดูประวัติของผู้นำในบริษัทวิศวกรรมหรือบริษัทรถยนต์ จะเห็นลำดับขั้นที่พวกเขารับผิดชอบมากขึ้นเรื่อย ๆ ในการออกแบบชิ้นส่วน·คอมโพเนนต์·ผลิตภัณฑ์ หรือการดำเนินงานโรงงานผลิต แม้แต่ CEO ก็ยังเน้นความรู้ทางเทคนิค และบุคลากรที่ไม่ใช่สายเทคนิคอย่างน้อยก็แสร้งทำเช่นนั้น
ในทางกลับกัน ใน การพัฒนาซอฟต์แวร์แบบ Agile ความสามารถทางเทคนิคมักสิ้นสุดอยู่ที่ชั้นล่างสุด ในทีมสกรัมมีคนที่สร้างซอฟต์แวร์อยู่ และนั่นก็หมดแล้ว Scrum Master และ Business Analyst จำนวนมากมีแนวโน้มว่าไม่เคยเขียนโค้ดมากนัก และหัวหน้าตัวจริงคนแรกตามลำดับชั้นก็มักทำงานเลขานุการ·งานบริหารเป็นหลัก จึงแทบไม่ค่อยดูโค้ด
ประเด็นไม่ใช่แค่ว่าการพัฒนาซอฟต์แวร์เกิดขึ้นในหน่วยขนาดเท่าตั๋วงาน จนยากจะครุ่นคิดเชิงปรัชญาว่าตนกำลังสร้างและดูแล abstraction layer กี่ชั้น แต่คือนักพัฒนาซอฟต์แวร์ไม่มีแม้แต่ที่นั่งบนโต๊ะตัดสินใจ พวกเขาถูก Scrum Master ดูแลประคบประหงม ต้องประนีประนอมในการรีวิวโค้ด ถูกกดดันไม่ให้คิดนอกขอบเขตตั๋วงาน และโดยมากก็ไม่มีเส้นทางเลื่อนตำแหน่งที่จะพาความสามารถทางเทคนิคขึ้นไปสู่ภาวะผู้นำ
ดังนั้นความเคลื่อนไหวที่พยายามประกาศ “วิกฤตซอฟต์แวร์” จึงดูมีแนวโน้มจะคงอยู่ในขอบเขตงานอดิเรกอย่าง Handmade, Permacomputing, retro computing ตามถ้อยคำช่วงท้ายบทความ ผมคิดว่า Hollywood ก็มีส่วนรับผิดชอบอยู่บ้างที่พรรณนาคนซอฟต์แวร์/IT อย่างน่าอับอายซ้ำแล้วซ้ำเล่า ขณะที่ให้บทนำแก่แพทย์และทนายความไม่รู้จบ และร้อยศัพท์เฉพาะซับซ้อนให้กลายเป็นเรื่องเล่าน่าสนใจ ฝั่งเราทำไม่ได้จริง ๆ หรือ? บางที AI เขียนบทอาจทำอะไรได้ในไม่ช้า
การพัฒนาซอฟต์แวร์คือการสนทนาอย่างเคร่งครัดกับคอมพิวเตอร์ทั้งวัน เป็นการแก้เรื่องธรรมดาที่เคยแก้ไปแล้วในแอปพลิเคชันใหม่ หรือจัดการปัญหาที่หากไม่มีพื้นฐานทางเทคนิคก็ยากแม้แต่จะเข้าใจ ผมเป็นนักพัฒนาที่เขียนโปรแกรมเป็นงานอดิเรกมากว่า 20 ปี แต่ถึงอย่างนั้น งานส่วนใหญ่ก็น่าเบื่อจนแทบบ้า ผมไม่คิดจะพยายามอธิบายให้คนที่ไม่ใช่นักพัฒนาฟังด้วยซ้ำ มันไม่น่าสนุกพอ ๆ กับบัญชี และคงมีหลายคนที่จะได้ข้อมูลที่มีประโยชน์กว่าจากเรื่องเล่าแบบอื่น
บริษัทที่หมกมุ่นกับ Agile มากที่สุดที่ผมเคยทำงานด้วย ปฏิบัติกับจูเนียร์และซีเนียร์เหมือนเฟืองที่สับเปลี่ยนกันได้ ความต่างมีเพียงซีเนียร์ต้องจัดการพอยต์ต่อสปรินต์ให้มากกว่าเท่านั้น มีการกดไม่ให้คิดนอกขอบเขตตั๋วงานอย่างแข็งขัน และบรรยากาศคือให้ก้มหน้าแล้วหุบปาก
แต่มีปัญหาสองอย่าง พวกเขาไม่สามารถลงลึกในรายละเอียดการ implementation ได้ และยังถูกผูกไว้กับแรงจูงใจที่บิดเบี้ยวซึ่งให้รางวัลเมื่อสร้างความซับซ้อน แน่นอนว่ามีคนที่ต่อต้านสิ่งนั้น แต่คนแบบนั้นมีโอกาสเลื่อนตำแหน่งต่ำ ไม่มีใครได้รางวัลจากการลดจำนวนคนใต้บังคับบัญชาหรือทำให้บทบาทของตัวเองหายไป
ถ้าพูดสั้น ๆ เหตุผลที่นักพัฒนาจัดการกับความต้องการจริงได้แค่หน่วยขนาดตั๋วงาน ก็เพราะพวกเขาโง่เกินไป พวกเขาเก็บภาพรวมไว้ในหัวไม่ได้ และไม่เข้าใจ ฟังดูน่าหงุดหงิดไหม? ใช่ มันเข้าใจยากจริง ๆ ขอโทษด้วย
บทความนี้วาดภาพ abstraction ราวกับเป็นสิ่งชั่วร้าย แต่ถ้าจะสร้างซอฟต์แวร์โดยมนุษย์ที่มีความสามารถเกินระดับหนึ่ง มันเป็นเครื่องมือที่หลีกเลี่ยงไม่ได้
Rich Hickey เคยพูดทำนองว่า “นักเล่นโยนของมือใหม่อาจจัดการลูกบอลได้สองสามลูก แต่แม้แต่นักเล่นโยนของที่เก่งที่สุดในโลกก็คงมีขีดจำกัดราวเก้าลูก ความสามารถมนุษย์ไม่ได้ต่างกันเป็นลำดับหลัก และชนเพดานอย่างรวดเร็ว” ถ้าจะข้ามขีดจำกัดนั้น ก็ไม่มีทางอื่นนอกจากต้องใช้ abstraction
แน่นอนว่าในบางกรณีอาจมี abstraction ที่แย่หรือมี abstraction มากเกินไป และผมคิดว่านั่นคือจุดที่ผู้เขียนโกรธ แต่การแยกแยะตรงนี้สำคัญ
ส่วนที่ว่า “ตอนนี้การสร้างซอฟต์แวร์ไม่ใช่เรื่องง่าย และไม่มีอะไรที่มาพร้อมคู่มือ” นั้นผิดอย่างชัดเจน การสร้างซอฟต์แวร์ง่ายกว่าที่เคย และเอกสารก็พร้อมกว่าด้วย
การทำความเข้าใจภาพรวมที่ซับซ้อนไม่จำเป็นต้องอาศัยการ indirect เสมอไป หากจะจัดการความซับซ้อน เราต้องคลายสิ่งที่พันกันออก เพื่อให้เข้าใจแต่ละส่วนได้อย่างเป็นอิสระ การซ่อนความซับซ้อนด้วยการ indirect จะสร้างระยะห่างระหว่างเรากับสิ่งที่เราต้องใช้เหตุผลพิจารณา
abstraction นั้นดีสำหรับผู้ใช้ เพราะไม่ว่าจะเป็นนักพัฒนาหรือไม่ ก็ไม่ต้องสนใจรายละเอียด แต่ไม่ได้ทำให้งานสร้างมันง่ายขึ้นสำหรับเรา
ตรงกันข้ามกับคำกล่าวที่ว่า “ตอนนี้การทำซอฟต์แวร์ไม่ใช่เรื่องง่ายแล้ว” ถ้ารู้จักเครื่องมือที่เหมาะกับงานที่ถูกต้อง มันก็ง่ายมาก เพียงแต่ข้อมูลเกี่ยวกับเครื่องมือเหล่านั้นถูกกดไว้จนแทบไม่ได้ยิน
ภาพของระบบนิเวศเครื่องมือทางเทคนิคที่คนส่วนใหญ่คิด กับความเป็นจริงนั้นต่างกันมาก เครื่องมือส่วนใหญ่ที่เรารู้จักนั้นแย่มาก พยายามทำตัวเหมือนเป็นคำตอบสารพัดประโยชน์ แต่จริง ๆ แล้วไม่ได้ดีนักกับงานอะไรเลย ถึงอย่างนั้นก็ยังเป็นเครื่องมือที่ได้รับความนิยมที่สุด ผมคิดว่าเป็นเพราะ อิทธิพลของทุน อย่างที่บทความสื่อเป็นนัย
ตัวอย่างเช่น ด้วยเครื่องมือที่ผมใช้อยู่ตอนนี้ ผมเคยอัดวิดีโอสร้างแอป marketplace ที่ค่อนข้างซับซ้อน มีล็อกอิน การควบคุมสิทธิ์เข้าถึง การตรวจสอบ schema และมุมมองตัวกรองที่ซับซ้อน ตั้งแต่เริ่มต้นภายใน 3 ชั่วโมง โดยใช้แค่เบราว์เซอร์ ไม่ต้องดาวน์โหลดซอฟต์แวร์ใด ๆ และเป็นแบบ serverless ทั้งแอปมี HTML markup น้อยกว่า 700 บรรทัด และ JavaScript 12 บรรทัด ยอดดูก็ประมาณ 10 ครั้ง
ตรงกันข้ามกับ twist แบบทฤษฎีสมคบคิด เครื่องมือยุคใหม่ยืดหยุ่นและใช้งานง่ายกว่าที่เคย แม้จะมีข้อบกพร่อง แต่ก็เทียบไม่ได้เลยกับสิ่งที่นักพัฒนาต้องเผชิญเมื่อหลายสิบปีก่อน ไม่มีแผนสมคบคิดขนาดใหญ่ที่พยายามกลบเครื่องมือของคุณอยู่หรอก
ผมเชื่อใน no-code/low-code และเครื่องมือที่รันได้ทุกที่อย่างมาก เพียงแต่สิ่งที่ผมหมายถึงอาจไม่ใช่แบบที่คุณคิดก็ได้ อย่างไรก็ดี ผมยอมรับว่าคุณสร้างมันขึ้นมา
คำถามแรกที่ผุดขึ้นมาตอนเริ่มดูวิดีโอคือ Codespaces คืออะไร? ความปลอดภัยเป็นอย่างไร? แอปสุดท้ายไปรันที่ไหน? รันบนฮาร์ดแวร์ของผมเองได้ไหม? รันโดยไม่ต้องเข้าถึงคลาวด์ได้ไหม? คลาวด์ไหน? มันจะยังอยู่สัปดาห์หน้า เดือนหน้า ปีหน้า หรืออีก 10 ปีข้างหน้าหรือไม่? แน่นอนว่าอย่าใส่ใจกับตัวอย่างเดียวนี้มากเกินไป
สถานการณ์ของ no-code/low-code เปรียบได้กับ desktop publishing ใน DTP ไม่มี CI/CD pipeline แค่กดพิมพ์ก็พอ เป็นสภาพแวดล้อมที่ผสานรวมอย่างสมบูรณ์ ในทางกลับกัน สภาพแวดล้อม “continuous integration” ทุกแบบตามตัวอักษร ดูเหมือนกำลังกินตัวเองเพราะพยายามตะโกนมากเกินไป ที่ไหนสักแห่งคงมีเครื่องมือสำหรับการแยกสี การตั้งค่าขอบกระดาษ การนำเข้าแบบอักษร ไลบรารี header ของ PostScript หรือการสร้าง LaTeX แต่คนส่วนใหญ่ไม่เคยเห็นและไม่เคยใช้ ที่ไหนสักแห่งอาจมีคนทำงานพิมพ์หลายเพลตด้วย pigment ที่หลากหลายกว่า CMYK มาก และคมชัดเฉพาะภายใต้แสงธรรมชาติ แต่คนส่วนใหญ่เห็นแค่ snapshot ห่วย ๆ จากโทรศัพท์ จึงไม่รู้สึกว่ามีความหมายอะไร
นี่ไม่ใช่ปัญหาของผู้สร้างเท่านั้น ผู้บริโภคไม่รู้ว่าอะไรเป็นไปได้บ้าง และไม่มีอุปกรณ์ที่จะเผยให้เห็นขอบเขตทั้งหมดของความเป็นไปได้ อุปกรณ์ผู้บริโภคบั่นทอนขอบเขตนั้นอย่างแข็งขันด้วยเหตุผลมากมายจากระบบนิเวศปิด และจากความสะเพร่า·ความไม่รู้แบบธรรมดา
หลายปีก่อนผมได้ Cadillac เป็นรถเช่า และผมจะไม่ซื้อ Cadillac รุ่นใหม่เด็ดขาด และถ้าเลี่ยงได้ก็จะไม่ขับด้วย ผมควบคุมที่ปัดน้ำฝนไม่ได้ และหน้าจอคอนโซลก็ขึ้นคำเตือนที่เด่นสะดุดตามากหลายครั้งว่าผมไม่ได้มองถนน ดูเหมือนมันคงจับไม่ได้ว่าผมใส่แว่นอยู่ ผมอยู่บนถนนที่ไม่คุ้นในสภาพการจราจรความเร็วสูง จึงไม่ได้มองหน้าจอจริง ๆ และถามคนนั่งข้าง ๆ ว่า “หน้าจอกะพริบนั่นมันบอกว่าอะไรกันแน่?” ทำได้ดีมาก Cadillac
โครงสร้างที่ตื้นและประกอบกันได้ เป็นสิ่งที่ทุกคนได้สัมผัสเวลาใช้เครื่องมือ UNIX
GUI พังทลายตรงจุดนี้ GUI เป็นเกาะโดดเดี่ยวตามตัวอักษรที่ไม่สื่อสารกันในแบบที่ประกอบกันได้
ผมกำลังทดลองผสมแนวคิด GUI กับ shell pipeline ด้วยเครื่องมือชื่อ guish
https://github.com/williamcotton/guish
อยากรู้ว่ามีใครรู้จักเครื่องมือคล้าย ๆ กัน หรือแนวทาง GUI ที่ประกอบกันได้บ้างไหม
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
ผมเองก็กำลังทำไอเดียที่เกี่ยวข้องอยู่ และจากภายนอกมันก็ดูคล้ายของคุณอยู่บ้าง แต่ขอแนะนำให้ลองดูว่าสิ่งนี้ทำงานอย่างไรใน emacs ผมยังไม่ได้ดูลงลึกนัก แต่แนวทางของคุณดูไม่ค่อย “ประกอบกันได้” เท่าไร
เผื่อยังไม่รู้จัก สิ่งนี้ก็อาจให้แรงบันดาลใจได้: https://gtoolkit.com/ เป็นสภาพแวดล้อม Smalltalk ที่ทุกอย่างโปรแกรมได้ตามตัวอักษรเหมือน emacs แต่แทบจะเป็นอีกทิศทางหนึ่ง GUI ไม่ใช่ผลลัพธ์ของคำสั่ง แต่เป็นตัวภาษานั้นเอง
แต่ปัญหาที่ใหญ่กว่านั้นไม่ใช่ GUI แม้ GUI จะเป็นปัญหาเหมือนกัน แต่มันจำเป็นต้องอยู่บนสุดของ abstraction stack จึงไม่ทำให้ปัญหาลากยาวและประกอบต่อกันมากนัก น่าสนใจว่ามันเป็นปัญหาใหญ่เกินไปจนกลับกลายเป็นว่าไม่ใช่ปัญหาอีกต่อไป
ช้างตัวใหญ่ในวันนี้คือ distributed systems
แต่ GUI เป็นจุดอ่อนมาตั้งนานแล้ว ผมคิดว่าเพราะการที่ UI จะดีหรือไม่นั้นมีข้อพิจารณาแบบ “ทั่วทั้งระบบ” อยู่มาก จึงไม่ใช่คุณสมบัติแบบ modular
ส่วนตัวแล้ว ผมอยากให้มี UI มากขึ้นแต่ยังคง automation ไว้ คุณสมบัติแบบที่สิ่งที่พิมพ์ใน shell สามารถบันทึกเป็นไฟล์แล้วนำมารันใหม่ภายหลัง แก้ไขแล้วรันใหม่ หรือคัดลอกคำสั่งส่งอีเมลให้เพื่อนได้
เพื่อให้บริบทเพิ่มเติม ผมสร้าง shell ใหม่จากศูนย์มาหลายปีแล้ว และมี headless mode สำหรับ GUI มีเดโมจริงที่คนอื่นเขียนไว้ด้วย แต่ตอนนี้ไม่มีใครทำงานต่ออยู่
ภาพหน้าจอ:
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
ลิงก์เพิ่มเติมอยู่ที่นี่ - https://github.com/oilshell/oil/wiki/Interactive-Shell - มีโปรเจกต์ที่น่าสนใจแต่ไม่ active แล้วอย่าง Xiki ด้วย
ถ้าคุณต้องการ shell ที่เข้ากันได้ซึ่งแยกออกจาก terminal หรือ shell ใหม่แบบนั้น แจ้งผมทางอีเมลหรือ https://oilshell.zulipchat.com ได้เลย
โดยพื้นฐานแล้ว เราต้องการคนมาทดสอบ headless protocol และบอกจุดที่ควรปรับปรุง ผมคิดว่าเราควรสร้าง shell GUI ที่ “มี” terminal แต่ไม่ได้เป็น “ตัว terminal เอง” มันก็ดูเกี่ยวข้องกับสิ่งที่คุณกำลังสร้างอยู่เหมือนกัน
ตอนนี้ผมทำงานกับภาษา YSH ใหม่เป็นหลัก แต่ก็อยากรื้อฟื้นงาน GUI ด้วย ผมไม่มีประสบการณ์เป็น UI programmer มากนัก จึงอยากได้มุมมองอื่น ๆ
และดีใจที่คุณใส่ ggplot ไว้ด้วยเพราะผมชอบ ggplot จริง ๆ แล้ว ggplot นี่แหละคือจุดที่ผมเสียดายว่า shell น่าจะมีกราฟิก
ประโยคท้าย ๆ ที่ว่า “มันดีขึ้นได้ ผมจะแสดงให้ดูว่าทำอย่างไร” ดูเหมือนเป็นแค่ บทนำสำหรับ clickbait
คำกล่าวที่ว่า “โมเดลเหล่านี้แทบไม่ค่อยสะท้อนความเป็นจริงเลย ถ้าสะท้อนก็เป็นความบังเอิญที่ดี แต่ถ้าไม่สะท้อนก็เป็นหายนะ” ไม่ตรงกับประสบการณ์ของผม
โดยทั่วไปซอฟต์แวร์ส่วนใหญ่ในตลาด ไม่ได้มีผลถึงชีวิต เว็บแอปอ้วนเทอะทะไร้คุณภาพจำนวนมากอาจดูดทรัพยากรมากเกินจำเป็นตลอดทั้งวัน เผยบั๊กประปรายไปทั่ว และทำงานที่ผู้ใช้คาดหวังได้อย่างย่ำแย่ ทั้งหมดนี้จริง
แต่มันไม่ได้มีผลถึงชีวิตเหมือนซอฟต์แวร์ที่จัดการเครื่องกระตุ้นหัวใจหรือจรวดอวกาศ ซอฟต์แวร์ส่วนใหญ่จะเละเทะก็ได้ เพราะโปรเจกต์ส่วนใหญ่เกี่ยวข้องกับความเอาแน่เอานอนไม่ได้ของมนุษย์ และผลเลวร้ายที่สุดของการขาดคุณภาพก็คือความหงุดหงิดเล็กน้อย ไม่ใช่ความพินาศหรือความตาย
อีกอย่าง นักพัฒนาซอฟต์แวร์ส่วนใหญ่ก็คงไม่ได้ทำงานภายใต้แรงจูงใจแบบเงินของ Silicon Valley และไม่ได้หาเลี้ยงชีพจากโปรเจกต์ที่อยากทำด้วยความหลงใหล ซอฟต์แวร์ส่วนใหญ่ที่ออกสู่ตลาดถูกสร้างขึ้นผ่านโครงสร้างผลตอบแทนห่วย ๆ จากภายนอก แล้วคุณจะคาดหวังให้ผลผลิตของกระบวนการแบบนั้นเป็นอะไรได้ นอกจากขยะ
ผมเกลียดขั้นบันไดที่หายไปจริง ๆ
เราอยู่ห่างไกลจากการใช้งานจริงของซอฟต์แวร์ที่เราสร้างมาก และได้สัมผัสเพียงสัญญาณสั้น ๆ ที่ปฏิบัติได้ซึ่งใช้บอกทิศทางกระบวนการพัฒนาเท่านั้น ตราบใดที่เราไม่สามารถสลับร่างกับผู้ใช้ใหม่ได้ ก็ยากที่จะรู้สึกถึงความเจ็บปวดจริงของ “การตายด้วยบาดแผลเล็ก ๆ นับพันครั้ง” นี้ได้อย่างถูกต้อง
ผมมองการเขียนโปรแกรมเป็นวิชาชีพหนึ่ง และมองว่าเรามีพลังที่จะกำกับคุณภาพซอฟต์แวร์ได้ เพียงแต่มีแรงจูงใจบางอย่าง ไม่ว่าจะเป็นด้านการเงินหรือไม่ก็ตาม ที่ทำให้เราเมินเฉย
ผมไม่คิดว่ามีวิกฤตซอฟต์แวร์ โปรแกรมเมอร์หลายล้านคนทั่วโลกกำลังสร้างโปรแกรมที่มีประโยชน์ในระดับหนึ่ง และแทบทุกอย่างรวมถึงเครื่องปิ้งขนมปังก็รันซอฟต์แวร์ได้สำเร็จเพียงพอ ชุมชนยังสร้างโปรแกรมที่ทุกคนเข้าถึงได้ ตั้งแต่เด็ก 5 ขวบจนถึงปู่ย่าตายาย วิกฤตอยู่ตรงไหน
แต่มี วิกฤตการจัดการโปรเจกต์ อยู่จริง ไม่ได้จำกัดแค่ซอฟต์แวร์ แต่เป็นปัญหาที่คนวางแผนกับคนส่งมอบอยู่ห่างกัน และดูเหมือนเราจะถมช่องว่างนั้นไม่ได้ Agile, Scrum ฯลฯ เป็นตัวชี้วัดช่องว่างนี้ ที่พวก “กูรู” ปฏิบัติกับพวกเราทุกคนเหมือนคนโง่ และพวกเราก็ยังสร้างสิ่งที่ดีกว่านี้ไม่ได้
การทำให้การพัฒนาซอฟต์แวร์กลายเป็นสินค้าโภคภัณฑ์ก็มีส่วนต่อความสับสนนี้เช่นกัน ด้วยลักษณะของสาขาที่เข้าสู่ตลาดได้ง่าย คนทุกระดับจึงเข้ามามีส่วนร่วมด้วยอัตราความสำเร็จที่หลากหลาย นี่ไม่ใช่เรื่องดีหรือแย่ แต่เป็นธรรมชาติของปรากฏการณ์ ไม่ต่างจากอุตสาหกรรมอาหารที่มีทั้งร้านอาหารดาว Michelin และ MacDonalds และทั้งคู่ก็มีผู้บริโภค แต่นั่นก็ไม่ได้ถูกเรียกว่าวิกฤตร้านอาหาร
สิ่งนี้ทำให้อายุการใช้งานของเครื่องปิ้งขนมปังสั้นลง สมัยก่อนอาจเคยมีเครื่องปิ้งขนมปังที่ใช้ได้ 10 ปี ตอนนี้เพราะซอฟต์แวร์แย่ ๆ และบางทีเพราะการเชื่อมต่อ WiFi หรือ Bluetooth ที่ถูกบังคับ เมื่อซัพพลายเออร์หยุดอัปเดต มันก็กลายเป็นขยะหลังผ่านไป 2 ปี อาจไม่เคยมีอัปเดตเลยด้วยซ้ำ วิกฤตนี้แค่ไม่ได้มองเห็นโดยตรงเสมอไป หรือไม่ค่อยสะดุดตาเพราะการบริโภคเกินพอดีในปัจจุบันและการซื้อของใหม่ไม่รู้จบ
แม้เครื่องปิ้งขนมปังจะหยุดทำงานหลัง 2 ปี เราก็อาจมองว่าไม่เป็นไร และอาจไม่สนใจหรือไม่รู้ว่าทำไม แต่มันอาจเคยเป็นส่วนหนึ่งของบ็อตเน็ต Mirai ก็ได้ https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
เครื่องปิ้งขนมปังน่าจะไม่ใช่ เพราะใช้ชิปที่เรียบง่ายกว่า แต่ใครจะไปรู้
อนึ่ง เครื่องปิ้งขนมปัง Dualit ของผมไม่ได้รันซอฟต์แวร์
ตอนที่ว่า “เราได้สร้างวิธีซ้อนชั้น abstraction และซ่อนข้อมูลในหลายระดับ เปลี่ยนปัญหาการสร้างซอฟต์แวร์ให้กลายเป็นชั้นสูงตระหง่าน” ทำให้นึกถึง abstraction ที่รั่วไหล และหอคอยบาเบล
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
น่าลองนำมาเทียบกันดู