ความจริงที่เราไม่ได้เรียนรู้วิธีพัฒนาซอฟต์แวร์คุณภาพสูง

 (florianbellmann.com)
3 คะแนน โดย GN⁺ 2023-12-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลายโปรเจกต์เลื่อน มาตรการ QA ออกไป แล้วพึ่งพา QA sprint ครั้งใหญ่ก่อนปล่อยรีลีส และทำความวุ่นวายแบบเดิมซ้ำในรอบถัดไป
  • การศึกษาด้านวิทยาการคอมพิวเตอร์ใช้เวลากับอัลกอริทึม ภาษา และการจัดการโปรเจกต์ แต่บ่อยครั้งไม่ได้สอน การประกันคุณภาพซอฟต์แวร์ ในระดับปฏิบัติจริง
  • ในบริษัท เมื่อเกิดปัญหางบประมาณ การพัฒนาล่าช้า หรือ scope เพิ่ม QA มักเป็นสิ่งแรกที่ถูกลดทอน และมีการปล่อย ซอฟต์แวร์ที่เปราะบาง หลังผ่านเพียงการทดสอบขั้นต่ำแบบไม่มีโครงสร้าง
  • หากต้องการโน้มน้าวเรื่อง QA ควรอธิบาย ต้นทุนเมื่อไม่ทำ ในรูปของต้นทุนการพัฒนาที่เพิ่มขึ้นหรือระยะเวลาทำให้รีลีสเสถียรที่ยาวขึ้น มากกว่าคำพูดนามธรรมอย่าง “เสถียรกว่า”
  • แทนที่จะสร้างระบบคุณภาพทั้งหมดในครั้งเดียว ควรเริ่มปกป้อง ฟีเจอร์หลัก ที่เชื่อมโยงโดยตรงกับคุณค่าของลูกค้า และสำหรับฟีเจอร์ใหม่ควรเขียนเทสต์ควบคู่ไปกับการ implement ตั้งแต่ตอนนั้น

QA ที่ถูกเลื่อนไปไว้ก่อนรีลีส

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

ช่องว่างด้านคุณภาพระหว่างการศึกษาและงานจริง

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

โครงสร้างที่ทำให้ QA ถูกลดก่อนในบริษัท

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

ก้าวแรกในการตัดวงจรปัญหาคุณภาพซ้ำๆ

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

อธิบาย QA ด้วยภาษาของเงิน

  • คำพูดอย่าง “ซอฟต์แวร์จะเสถียรกว่า” หรือ “ดูแลรักษาง่ายขึ้น” อาจไม่เป็นรูปธรรมสำหรับคนที่ไม่ได้ทำงานกับ codebase
  • นักพัฒนาควรพูดถึง ต้นทุนของการไม่ทำ QA
  • ตัวอย่างถ้อยคำมีดังนี้
    • ถ้าไม่ทำตอนนี้ อีก 4 เดือน effort และต้นทุนการพัฒนาจะเพิ่มขึ้น 15%
    • หากไม่ใส่ unit test ให้ทุกฟีเจอร์ ขั้นตอนทำให้รีลีสเสถียรจะยาวขึ้นทุกครั้ง
    • ยิ่งมีฟีเจอร์ใหม่มากขึ้น ก็ยิ่งต้องทดสอบ side effect ด้วยมือทุกครั้ง ทำให้ความคืบหน้าลดลงในแต่ละรีลีส
  • วิธีนี้เป็นภาษาที่สื่อสารกับธุรกิจและผู้จัดการได้ง่าย
  • ท้ายที่สุด มาตรการ QA สามารถทำให้ชีวิตของทั้งนักพัฒนาและผู้จัดการดีขึ้นได้

เริ่มด้วยปริมาณที่มีผลขั้นต่ำ

  • หากออกแบบ QA ให้เป็นการลงทุนล่วงหน้าขนาดใหญ่เกินไป จะขัดขวางความคืบหน้าของโปรเจกต์และทำให้ได้รับความเห็นชอบจากผู้มีส่วนได้ส่วนเสียยาก
  • จุดเริ่มต้นที่เป็นจริงได้คือการหาส่วนที่สำคัญที่สุดของแอปพลิเคชัน
  • โดยทั่วไปจะมี use case, ฟีเจอร์ หรือพฤติกรรมหลักบางอย่างที่ทั้งแอปพลิเคชันพึ่งพาอยู่
  • ควรเริ่มทดสอบจาก ฟีเจอร์หลัก ที่ต้องทำงานอย่างถูกต้องเพื่อให้เกิดคุณค่าต่อลูกค้า
  • ปริมาณที่มีผลขั้นต่ำ (MED) หมายถึงปริมาณที่เล็กที่สุดที่ทำให้เกิดผลลัพธ์ที่ต้องการ
  • ใน QA นั้น MED อาจเป็นหนึ่งในสิ่งต่อไปนี้
    • แผนการทดสอบแบบ manual
    • automated test ใน pipeline
    • มาตรการอื่นที่รับประกันพฤติกรรมหลัก
  • หลังรับประกันฟีเจอร์หลักแล้ว จึงค่อยๆ ขยายความเสถียรออกไปได้
  • ควรเพิ่ม unit test ในทุกฟีเจอร์ใหม่ และต้องตรวจสอบข้อมูลที่ควบคุมไม่ได้ เช่น API ภายนอกหรือ input จากผู้ใช้ด้วย
  • QA ก็ควรปรับปรุงแบบวนซ้ำและค่อยเป็นค่อยไปเช่นกัน

คำถาม QA ที่ควรตรวจสอบในโปรเจกต์ใหม่

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

ควรเขียนเทสต์ควบคู่ไปกับการ implement

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

ผลที่ย้อนกลับมาสู่โปรเจกต์และตัวบุคคล

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

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

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

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

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

    • ผมเรียนเรื่องแบบนี้ในหลักสูตรปริญญาตรี CS ที่สวีเดน และการที่ในที่ทำงานแรกผมกลายเป็น เทคลีด โดยแทบจะภายใน 1 ปี ไม่ใช่เพราะความยิ่งใหญ่ติดตัวมาแต่กำเนิด แต่น่าจะเพราะผมได้เรียนวิศวกรรมซอฟต์แวร์มา
      ที่น่าขันคือสมัยเป็นนักศึกษา ผมเกลียดวิชาวิศวกรรมซอฟต์แวร์ที่สุด วิชา design patterns ที่ต้องยึด UML อย่างเคร่งครัดดูเชย ส่วนวิชา QA ที่เรียน TDD และเครื่องมือใน ecosystem ของ Java ก็น่าเบื่อ แต่ไม่กี่ปีต่อมา เมื่อผมเข้าร่วมทีมที่สร้าง workflow และเครื่องมือสำหรับทดสอบซอฟต์แวร์ที่มีข้อกำหนดด้านความปลอดภัยสูง เพื่อนร่วมงานก็แปลกใจที่ผมรู้อยู่แล้วว่าต้องทำอะไรบ้าง
    • การที่ CMU สอน กับการที่มหาวิทยาลัยส่วนใหญ่สอนนั้นต่างกันมาก
      ต่อให้สอน ก็มักจะล้าสมัย หรือเอนเอียงไปทางเนื้อหาที่ตีความตรงตัวมาก ๆ อย่างการเขียนเว็บแอปพลิเคชัน ถ้ามีวิชาที่โฟกัสเรื่องการลงมือ implement, การทำงานเป็นทีม และการสร้างระบบซับซ้อน ผมคงอยากลงเรียนมาก
    • 90% ของผู้จบ CS ไม่ได้ไปเป็นนักวิทยาการคอมพิวเตอร์ แต่ไปทำงานเป็น วิศวกรซอฟต์แวร์
      เนื้อหาแบบนี้ไม่ควรถูกวางไว้เป็นวิชาเลือกหรือหลักสูตรปริญญาโท แต่ควรมีโปรแกรมวิศวกรรมซอฟต์แวร์ระดับปริญญาตรี และนักศึกษา CS 90% ควรย้ายไปทางนั้น
    • เพื่อนคนหนึ่งพยายามอยู่หลายปีที่จะสร้างวิชาวิศวกรรมซอฟต์แวร์ในภาควิชาที่เขาทำงานเป็นผู้สอนอยู่ แผนการสอนพื้นฐานคือรับการส่งมอบและ codebase จากภาคการศึกษาก่อนหน้า, implement ฟีเจอร์ใหม่, deploy และ operate จากนั้นเขียนเอกสารส่งมอบสำหรับภาคการศึกษาถัดไป
      codebase เป็นบริการเรียบง่ายที่ให้การสแกนไวรัส/มัลแวร์ และถูกออกแบบให้มีงานเพิ่มได้เสมอ รวมถึง scanner และ signature เป็นไอเดียเมื่อกว่า 15 ปีก่อน แต่คงเป็นวิชาที่ยอดเยี่ยมที่ดำเนินต่อเนื่องได้ น่าเสียดายที่เขาโน้มน้าวภาควิชาไม่สำเร็จ
    • ถ้าเพื่อน ๆ ไม่ได้เล่าประสบการณ์แย่ ๆ เกี่ยวกับวิชา compiler แบบเห็นภาพชัดเกินไป ผมก็คงไม่ได้ไปลงวิชา distributed computing ซึ่งเป็นอีกตัวเลือกเพื่อเติมหมวดนั้น
      แม้จะยังไม่ถึงขั้นเป็นวิชาที่นิยามชีวิตปริญญาตรีของผม แต่ก็ใกล้เคียงมาก และความจริงที่ว่าคนส่วนใหญ่ที่ออกแบบระบบไม่รู้เรื่องนี้ ทำให้ทั้งโกรธและหวาดกลัวเชิงภววิทยาไปพร้อมกัน

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

    • เป็นมุมมองที่น่าสนใจ ผมเรียนปริญญาโท CS ไปประมาณ 95% แล้วออกมาทำสตาร์ทอัพ ผมรู้คุณค่าของ parser generator แต่ก็มีหลายกรณีที่การ เขียน parser เอง แบบง่าย ๆ เหมาะสม มีประโยชน์ และเร็วกว่า
      โปรโตคอลแบบ string ที่มีตัวคั่นชัดเจนมัก parse ได้ง่ายมาก และอาจจัดการเพียงบางส่วนตาม use case ก็ได้ แน่นอนว่าต้องพิจารณา test และข้อกำหนดด้านฟีเจอร์ด้วย หากเป็นกรณีสร้างภาษา คำแนะนำก็อาจต่างออกไป
    • เรื่อง crypto เห็นด้วย แต่กับ parser นั้นไม่แน่ใจว่าจริงไหม ตรงนี้ดูเหมือนมี เส้นโค้งรูปตัว U บางอย่าง
      มือใหม่จะเขียนเอง นักพัฒนาระดับกลางและโปรเจกต์ขนาดกลางจะใช้ parser generator ส่วนคนที่ดูแล parser ที่ซับซ้อนที่สุดก็มักชอบเขียนเอง GCC ก็เคยใช้ bison parser แต่เปลี่ยนมาเป็น recursive descent parser ที่เขียนด้วยมือเพื่อให้ข้อความ error ดีขึ้น และ Clang ก็ใช้ recursive descent เช่นกัน
    • สำหรับ parser มีข้อโต้แย้งอยู่ เพราะการให้ข้อความ diagnostic error ที่มีประโยชน์ด้วย yacc/bison นั้นยากมาก ภาษาโปรแกรมส่วนใหญ่จึงลงเอยด้วยการใช้ recursive descent parser ที่เขียนด้วยมือ
      ข้อยกเว้นที่ผมรู้จักเป็นการส่วนตัวมีแค่ jq และด้วยเหตุนี้ใน implementation ของ jq จึงทำข้อความ syntax error ที่มีประโยชน์ได้ยาก
    • ไม่ควรเอา crypto กับ parser มาใส่ไว้ในประโยคเดียวกัน ไม่มีช่วงเวลาไหนที่การเขียน crypto เองจะเหมาะสม แต่โปรเจกต์ compiler/interpreter ขนาดใหญ่จำนวนไม่น้อยใช้ parser ที่เขียนเอง และหลายครั้งก็เขียน lexer เองด้วย
      การเขียน parser อาจง่ายพอที่จะอยู่ในงานมอบหมายหนึ่งชิ้น และโค้ด parser ที่เขียนด้วยมือสุดท้ายก็จะคล้ายกับไวยากรณ์ LL การ parsing เป็นส่วนที่ง่ายที่สุดในการเขียน compiler หรือเครื่องมือภาษา ดังนั้นถ้า parser ที่เขียนเองเป็นมาตรฐานที่สูงเกินไปสำหรับทีม ก็น่าสงสัยทั้งโปรเจกต์ ไม่ได้หมายความว่าอย่าใช้ parser generator เด็ดขาด แต่ผมอยากทำงานกับโปรเจกต์ที่มี parser เขียนเองที่ทดสอบมาอย่างดี มากกว่าโปรเจกต์ที่ทำให้ build ซับซ้อนด้วยเครื่องมือเพิ่มเติม หรือใช้เครื่องมือเก่า ๆ อย่าง Bison/ANTLR
    • เป็นปัญหาเรื่องวัฒนธรรม ควรหลีกเลี่ยง องค์กรพัฒนาแบบคาวบอย
      ถึงอย่างนั้น มาตรฐานโดยรวมดูเหมือนจะสูงขึ้นกว่าเมื่อ 20 ปีก่อน เช่น source control, unit test และ CI/CD ไม่ใช่เรื่องที่ถกเถียงกันอีกต่อไป

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

    • ถ้าเคยเขียนซอฟต์แวร์ระดับ production ในบริษัทจริง ๆ คุณต้องยอมรับว่าในวินาทีที่สร้าง commit ใหม่ แม้เปลี่ยนแค่ 1 บรรทัด ก็อาจทำให้บางอย่างพังได้
      ต่อให้ทำ unit test, integration test, user acceptance test ครบหมด การเปลี่ยนโค้ดหนึ่งครั้งก็หมายถึงความเป็นไปได้ของบั๊กใหม่อยู่ดี ถ้านักพัฒนาบอกว่า “ผมไม่มีวัน deploy โค้ดที่มีบั๊ก” ก็ยิ่งทำให้อยากซักต่อว่าหมายความว่าอะไรกันแน่
    • น่าเสียดายที่เรื่องนี้จริง การ deploy ให้ตรงเวลากับการไม่มีบั๊กนั้นแปรผกผันกัน และในโลกที่การขอเวลาเพิ่มจาก PM เพื่อทำ testing ให้ดีขึ้นหรือชำระ technical debt เป็นเรื่องยาก นี่ก็คือความจริงล้วน ๆ
    • ภูมิปัญญาแบบนี้ดูเหมือนจะมาจากประสบการณ์หรือการคิดในระดับที่สูงขึ้น ตามที่บทความบอกไว้ testing/TDD/QA ส่วนใหญ่ถูกเอามาแปะเพิ่มทีหลัง หรือถูกรวมไปทำท้ายสุดเป็น “QA sprint”
      เมื่อก้าวเลยจาก “เขียนฟังก์ชันแล้ว”, “ทดสอบฟังก์ชันแล้ว”, “ทดสอบไปถึงฟังก์ชันที่ถูกเรียกผ่านเครือข่ายแล้ว” ก็จะตระหนักว่า ต่อให้จัดการ boundary condition ได้ดีแค่ไหนและทำ QA เข้มแค่ไหน ในการตั้งค่าบางแบบ ฮาร์ดแวร์บางรุ่น เคอร์เนลบางตัว ก็ยังมี undefined behavior แบบ 0-day เหลืออยู่เสมอ เราแค่พูดได้ว่ามันผ่าน test ผ่านสายตามนุษย์ ผ่าน review แล้ว จึงรับประกันได้ว่าแทบไม่มีบั๊ก และสุดท้ายก็ทำได้แค่ไขว้นิ้วภาวนา
    • เป็นมุมมองต่อวิศวกรรมที่ค่อนข้างเผ็ดร้อนทีเดียว ชวนสงสัยว่าทำไมเรื่องที่วิศวกรรมสาขาอื่นไม่ยอมรับ ถึงยอมรับกันได้ใน ซอฟต์แวร์
    • ถ้าต้นทุนการแก้บั๊กสูงกว่าต้นทุนที่บั๊กนั้นมีต่อประสบการณ์ผู้ใช้หรืองานที่ต้องทำ การปล่อยให้บั๊กเล็ดลอดไปถึง production ก็เป็นเรื่องที่ยอมรับได้โดยสมบูรณ์
      ถ้าเป็นบั๊กที่ต้องใช้เวลาแก้หนึ่งสัปดาห์ แต่มีผู้ใช้ส่วนน้อยเท่านั้นที่เจอในสถานการณ์ที่เกิดขึ้นน้อยมาก ก็อาจไม่ต้องแก้ก็ได้

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

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

  • เรื่องแบบนี้เรียนรู้ได้จาก องค์กรพัฒนาที่ดี เมื่อ 10–15 ปีก่อนก็ประมาณ FAANG และตอนนี้ที่เป็นตัวอย่างก็คือที่อย่าง TailScale
    เป็นไปได้ที่จะไม่เต็มไปด้วย microservice ที่ไร้ประโยชน์และ Docker ซ้อนกันเป็นชั้น ๆ, ชั้น serialization/deserialization ของ JSON, มีแต่ unit test เพื่อ coverage แล้วมองข้าม QuickCheck·Hypothesis·fuzzing ทั้งหมด การทำ stacked change sets, การหมุนเวียน on-call ของทีมที่เขียนโค้ดนั้น, การลด dynamic linking และ dependency error ที่ไม่ได้บังคับให้น้อยที่สุด, การออกแบบให้สอดคล้องกับ runtime ของ managed language ไปจนถึงการเรียกร้องให้ไวยากรณ์เชิงวาจาที่อ่านง่ายของภาษาถูกถือเป็น “readability” ล้วนทำได้ทั้งนั้น แม้จะถูกเมินซ้ำแล้วซ้ำเล่า แต่วิธี deploy ซอฟต์แวร์คุณภาพเป็นความรู้สาธารณะ

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

  • เป็นเรื่องยากที่จะไปถึง ตัวชี้วัด ที่มีความน่าเชื่อถือพอจะรองรับข้ออ้างแบบ “ถ้าไม่ทำตอนนี้ อีก 4 เดือนความพยายามและต้นทุนในการพัฒนาจะเพิ่มขึ้น 15%”
    เคยมีครั้งหนึ่งใน startup ที่ผู้ก่อตั้งสองคนบอกว่า “อย่าเขียน unit test” ผมไม่ได้เถียง และเข้าใจว่าความหมายจริง ๆ ของคำนั้นคือ เราช้าเกินไป จง deploy ให้เร็วที่สุด ผม deploy ได้เร็วและยังรักษาคุณภาพไว้ รวมถึงเขียน unit test ด้วย พวกเขาไม่จำเป็นต้องรู้ พวกเขาต้องการแค่ผลลัพธ์ แก่นที่ซ่อนอยู่ของการถกเถียงแบบนี้คือ องค์กรซอฟต์แวร์ส่วนใหญ่ไม่รู้วิธี deploy ให้ทั้งเร็วและมีคุณภาพ ไม่มีสูตรวิเศษ ต้องอาศัยฝีมือแบบช่างของแต่ละคน และขณะเดียวกันก็เป็นกีฬาทีมด้วย สถานการณ์ต่างกันไปในแต่ละที่ กระบวนการแบบเบา ๆ อาจใช้ได้บางส่วน แต่ผลลัพธ์จำกัด ท้ายที่สุดต้องมีทีมที่ดีซึ่งมีประสบการณ์ ค่านิยมที่ถูกต้อง และปัญญาที่มุ่งเน้นการส่งมอบคุณค่า

  • สมมติฐานที่ว่ามหาวิทยาลัยสอนวิธีสร้างซอฟต์แวร์ในอุตสาหกรรมเป็นคำกล่าวที่ค่อนข้างกล้าทีเดียว
    อีกอย่าง บทความนี้ดูเหมือนบทความจากยุค 90 ที่ยังแจกจ่ายซอฟต์แวร์ด้วย CD หรือ floppy disk ทุกวันนี้แนวคิดเรื่อง “release” มักพร่าเลือนลงเพราะ pipeline สำหรับ continuous deployment และสิ่งนี้ก็ถือเป็นแนวปฏิบัติที่ดี ในบริบทแบบนี้ การมีฝ่าย QA มารับประกันด้วยมือว่า release ไม่มีบั๊ก ดูค่อนข้างล้าสมัยมาก

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

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

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

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

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

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

    • อาจกล่าวได้ว่า แนวปฏิบัติทางอุตสาหกรรมทั้งหมดเป็นเช่นนั้น
      ในทางกลับกัน ชื่อเรื่องก็หมายความเพียงว่าโปรแกรมมิงไม่ใช่แนวปฏิบัติทางอุตสาหกรรม เรื่องนี้ควรชัดเจนสำหรับคนที่สังเกต แต่บางคนก็ไม่ยอมมองให้ถึงที่สุด
    • การศึกษาที่ดีส่วนใหญ่คือการสร้างสถานการณ์ให้ผู้เรียนสามารถฝึกได้อย่างมีประสิทธิภาพ
      แค่ดูการเขียนก็จะเห็นว่าหลายคนเรียนรู้วิธียกระดับคุณภาพได้ ด้วยการชี้แนะว่าจะลองเขียนอะไร และที่สำคัญกว่านั้นคือชี้แนะว่าจะย้อนดูและปรับปรุงคุณภาพของสิ่งที่เพิ่งเขียนอย่างไร
    • ศิลปะก็เข้าข่ายเช่นกัน ยิ่งการศึกษาลึกขึ้น ก็ยิ่งมุ่งเน้นความแตกต่างเล็ก ๆ และ คุณภาพ มากขึ้น
      การฝึกช่วยได้เสมอ แต่คุณภาพเองก็เป็นสิ่งที่คนจำนวนมากเรียนรู้และฝึกฝนได้
    • ด้วยปัญหาสุขภาพ จึงไม่สามารถบินอย่างมืออาชีพได้อีกแล้ว แต่ในวงการการบินได้เรียนรู้สิ่งเหล่านี้ และรู้สึกว่าวงการเทคโนโลยียังขาดอยู่
      ตอนเรียนบิน เราเรียนรู้มาตรฐาน แต่เมื่อเวลาผ่านไปก็ถูกสอนให้ลดช่วงความคลาดเคลื่อนที่ยอมรับได้ให้แคบลง เช่น หากเกณฑ์ความสูงในการเลี้ยวชันคือ ±100 ฟุต นั่นคือขั้นต่ำ และควรตั้งเป้าไปที่ 50 ฟุต, 20 ฟุต หรือยิ่งกว่านั้นคือให้เข็มแทบไม่ขยับเลย เป้าหมายคือ “ให้ดีกว่าเดิม ดีกว่าเดิมเสมอ มีอะไรที่ทำให้ดีขึ้นได้อีก?” และการบินจะผ่านได้ก็ต่อเมื่อทุกหัวข้อเป็นที่น่าพอใจ ไม่ใช่ดูค่าเฉลี่ยรวม ในเชิงวัฒนธรรม “น่าพอใจ” ไม่ใช่จุดสิ้นสุด แต่เป็นจุดเริ่มต้น
      รู้สึกว่าทัศนคตินี้สร้างโมเดลที่ร่วมมือกันมากกว่ามาก ในการบิน ทุกคนต้องการให้กันและกันประสบความสำเร็จอย่างจริงใจ และหากใครล้มเหลว ตัวเองก็มีส่วนรับผิดชอบอยู่บ้าง วัฒนธรรมคือเมื่อทำผิดพลาด ต้องหาวิธีลดโอกาสเกิดความผิดพลาดในอนาคต และในสายการบิน Flight Operations Quality Assurance (FOQA) ก็มีบทบาทมากเช่นกัน ในองค์กรปฏิบัติการขนาดเล็กในพื้นที่ห่างไกล สิ่งนี้เป็นทางการน้อยกว่า แต่ส่วนใหญ่ก็ใกล้เคียงกับวัฒนธรรม “ไม่กล่าวโทษ” และแก่นคือ “จะทำให้ดีขึ้นได้อย่างไร?”
      คุณภาพ การตัดสินใจ และ “การทำสิ่งที่ถูกต้อง” เป็นหัวใจของวัฒนธรรมการบิน สำหรับผู้ให้บริการที่มีชื่อเสียง หากตัดสินว่าสภาพอากาศเลวร้ายเกินกว่าจะทำได้อย่างปลอดภัย นั่นย่อมนำไปสู่การยกเลิกเที่ยวบิน และจะไม่ฝืนออกเดินทางเพียงเพื่อให้งานเสร็จ วงการเทคโนโลยีที่เพิ่งเข้ามาใหม่นั้นให้ความรู้สึกตรงกันข้าม แนวคิด ผลิตภัณฑ์ขั้นต่ำที่ใช้งานได้ เองก็แสดงให้เห็นปัญหา มันไม่ควรเป็น “ฟังก์ชันขั้นต่ำ” แต่ควรเป็น “ผลิตภัณฑ์คุณภาพขั้นต่ำที่ยอมรับได้ในฐานะจุดเริ่มต้น” ไม่ควรตั้งขั้นต่ำเป็นเป้าหมาย ขั้นต่ำเป็นเพียงจุดเริ่มต้นเท่านั้น
    • การฝึกมีความหมายก็ต่อเมื่อตั้งใจจะสร้างคุณภาพ
      หากเอาแต่ฝึกทำขยะ ก็จะเพียงแค่ชำนาญในการทำขยะเท่านั้น คนที่ไม่สนใจคุณภาพก็มีอยู่จริง ดังนั้นในกรณีนั้น สมมติฐานทั้งหมดก็พังทลาย