บทความเรียงความซอฟต์แวร์ที่หล่อหลอมฉัน

 (refactoringenglish.com)
74 คะแนน โดย GN⁺ 2025-10-02 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะอ่านบทความบล็อกเกี่ยวกับซอฟต์แวร์มาหลายพันชิ้นตลอด 20 ปีที่ผ่านมา แต่มี บทความเรียงความเพียงไม่กี่ชิ้นที่เปลี่ยนวิธีคิดอย่างถึงราก และนี่คือ 10 บทความสำคัญ ตั้งแต่ "Joel Test" ของ Joel Spolsky ไปจนถึงบทความสนับสนุน JavaScript ล้วนๆ ของ Julia Evans
  • "Joel Test" ของ Joel Spolsky เสนอคำถาม 12 ข้อเพื่อประเมินว่านายจ้างให้ความเคารพนักพัฒนาหรือไม่ โดยตรวจสอบว่าพวกเขาให้ความสำคัญกับเวลาและสมาธิของนักพัฒนาผ่านเรื่องอย่าง การจัดการซอร์สโค้ด, การบิลด์รายวัน, การแก้บั๊กก่อน หรือไม่
  • "Parse, don't validate" ของ Alexis King แนะนำเทคนิคการแปลงข้อมูลเป็นชนิดใหม่ระหว่างการตรวจสอบข้อมูล แสดงให้เห็นว่า ระบบชนิดข้อมูลสามารถช่วยยกระดับความปลอดภัยและความน่าเชื่อถือของแอปพลิเคชัน ได้
  • "No Silver Bullet" ของ Fred Brooks แยกงานซอฟต์แวร์ออกเป็นความซับซ้อนโดยเนื้อแท้และความซับซ้อนโดยบังเอิญ พร้อมโต้แย้งว่า การพัฒนาเครื่องมือและฮาร์ดแวร์ไม่อาจเพิ่มผลิตภาพได้ถึง 10 เท่า แต่ AI ได้เข้ามาเป็นตัวแปรใหม่ของทฤษฎีนี้
  • บทความ JavaScript ล้วนๆ ของ Julia Evans ทำให้ตระหนักว่า JavaScript ระดับ ES2018 เพียงอย่างเดียวก็เพียงพอ แม้ไม่มีเฟรมเวิร์ก และตั้งแต่ปี 2020 เป็นต้นมา ก็ไม่ได้นำเฟรมเวิร์ก JavaScript หรือขั้นตอน build ใดๆ มาใช้กับโปรเจ็กต์อีก

"Joel Test" ของ Joel Spolsky (2000)

  • Joel Spolsky คือ บล็อกเกอร์สายซอฟต์แวร์ที่ยอดเยี่ยมที่สุดตลอดกาล และบทความเรียงความของเขาส่งอิทธิพลอย่างมากต่อแนวทางด้านซอฟต์แวร์ของผู้เขียน
  • "Joel Test" คือชุดคำถาม 12 ข้อสำหรับประเมินว่านายจ้างลงทุนกับทีมซอฟต์แวร์ได้ดีเพียงใด

  • รายการคำถาม 12 ข้อ

    • ใช้การจัดการซอร์สโค้ดหรือไม่
    • บิลด์ได้ในขั้นตอนเดียวหรือไม่
    • มีการบิลด์รายวันหรือไม่
    • มีฐานข้อมูลบั๊กหรือไม่
    • แก้บั๊กก่อนเขียนโค้ดใหม่หรือไม่
    • มีตารางเวลาที่อัปเดตล่าสุดหรือไม่
    • มีสเปกหรือไม่
    • โปรแกรมเมอร์มีสภาพแวดล้อมการทำงานที่เงียบสงบหรือไม่
    • ใช้ เครื่องมือที่ดีที่สุดที่เงินซื้อได้ หรือไม่
    • มีผู้ทดสอบหรือไม่
    • ให้ผู้สมัครใหม่เขียนโค้ดระหว่างสัมภาษณ์หรือไม่
    • มีการทดสอบการใช้งานแบบ hallway usability test หรือไม่

  • ข้อความสำคัญ

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

"Parse, don't validate" ของ Alexis King (2019)

  • แม้จะเป็นบทความเกี่ยวกับการใช้ระบบชนิดข้อมูลของ Haskell แต่ก็เปลี่ยนวิธีคิดเรื่องซอฟต์แวร์อย่างถึงรากได้ แม้คุณจะไม่ได้สนใจระบบชนิดข้อมูลหรือ Haskell เลยก็ตาม
  • เทคนิคของ Alexis ใช้ได้กับทุกภาษาแบบ static type เช่น Go, C++, Rust เป็นต้น

  • แนวคิดหลัก

    • ทุกครั้งที่ตรวจสอบข้อมูล ควร แปลงข้อมูลนั้นให้เป็นชนิดใหม่
    • ตัวอย่าง: หากมีกฎว่าชื่อผู้ใช้ต้องเป็นตัวอักษรและตัวเลขไม่เกิน 20 ตัว วิธีแบบตรงไปตรงมาคือฟังก์ชัน validateUsername(username string) error

  • ปัญหา

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

  • วิธีแก้ของ Alexis

    • ใช้ฟังก์ชัน parseUsername(raw string) (Username, error)
    • ในส่วนที่เหลือของโค้ดเบส ให้ใช้ชนิดข้อมูลกำหนดเอง Username แทน string ที่เรียกว่า "username"
    • ฟังก์ชันเดียวที่สามารถสร้าง Username ได้คือ parseUsername และมันจะใช้กฎการตรวจสอบก่อนคืนค่าอินสแตนซ์ Username
    • เมื่อคุณมีอินสแตนซ์ Username แล้ว ก็หมายความว่า มันต้องมีชื่อผู้ใช้ที่ถูกต้องอยู่ภายใน
    • อินพุตที่ไม่น่าเชื่อถือจะเป็น string เสมอ ดังนั้นจึงไม่สามารถส่ง string ให้ฟังก์ชันที่คาดหวัง Username ได้

  • ผลกระทบ

    • ก่อนอ่านบทความนี้ ผู้เขียนเคยคิดว่าระบบชนิดข้อมูลเป็นเพียงของเล่นน่าสนุกที่ทำให้พวกเนิร์ดภาษาคอมพิวเตอร์เพลิดเพลิน
    • "Parse, don't validate" ทำให้ตระหนักว่า ความสามารถของคอมไพเลอร์มีคุณค่าเพียงใดในการเพิ่มความปลอดภัยและความน่าเชื่อถือของแอปพลิเคชัน

"No Silver Bullet" ของ Fred Brooks (1986)

  • ผู้เขียนได้อ่าน The Mythical Man-Month ของ Fred Brooks ตอนเรียนมหาวิทยาลัย
  • เป็นรวมบทความเรียงความด้านวิศวกรรมซอฟต์แวร์จากประสบการณ์การกำกับโปรเจ็กต์ OS/360 ของ IBM

  • ความซับซ้อนโดยเนื้อแท้และความซับซ้อนโดยบังเอิญ

    • ความซับซ้อนโดยเนื้อแท้: งานที่จำเป็นต้องทำ ไม่ว่าเครื่องมือหรือฮาร์ดแวร์จะเป็นอย่างไร
      • ตัวอย่าง: ในซอฟต์แวร์คำนวณโบนัสพนักงานขาย ต้องกำหนดสูตรโบนัสและครอบคลุมทุก edge case
      • ไม่ว่าจะเป็นซูเปอร์คอมพิวเตอร์มูลค่า $5B หรือไมโครคอนโทรลเลอร์ราคา $1 ก็เป็นงานเดียวกัน
    • ความซับซ้อนโดยบังเอิญ: ทุกสิ่งนอกเหนือจากนั้น
      • การจัดการ memory leak, การรอให้โค้ดคอมไพล์, การหาวิธีใช้ไลบรารีของบุคคลที่สาม
      • ยิ่งเครื่องมือและทรัพยากรฮาร์ดแวร์ดีเท่าไร เวลาที่ใช้กับความซับซ้อนโดยบังเอิญก็ยิ่งลดลง

  • ข้อสรุปของ Brooks

    • ความก้าวหน้าของเครื่องมือหรือฮาร์ดแวร์ ไม่อาจสร้างการเพิ่มผลิตภาพของนักพัฒนาได้ถึง 10 เท่า
    • แม้จะลดเวลาของกิจกรรมโดยบังเอิญทั้งหมดให้เหลือศูนย์ ก็ยังขยายขนาดไม่ได้ เว้นแต่มันจะกินสัดส่วนมากกว่า 9/10 ของความพยายามทั้งหมด

  • การประยุกต์ใช้

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

  • ผลกระทบของ AI

    • AI ยุคใหม่ได้โยนประแจเข้าใส่ทฤษฎีของ Brooks
    • AI ลดความซับซ้อนโดยเนื้อแท้ได้จริง
    • หากคุณส่งสเปกที่ไม่สมบูรณ์หรือขัดแย้งกันให้ AI มันสามารถยืมจากสเปกที่คล้ายกันเพื่อเติมช่องว่างได้
    • แม้ AI จะทำให้การเขียนโปรแกรมแบบที่เรารู้จักหายไป บทความของ Brooks ก็ยังมอบความหวังว่า สุดท้ายแล้วไม่ว่าจะอยู่ที่ระดับนามธรรมใด ก็ยัง ต้องมีคนคอยจัดการความซับซ้อนโดยเนื้อแท้ อยู่ดี

"Choices" ของ Joel Spolsky (2000)

  • เลือกบทความ Joel Spolsky ที่ชอบเพียงชิ้นเดียวได้ยาก จึงเลือกมาสองชิ้น
  • "Choices" ว่าด้วยการสร้างส่วนติดต่อผู้ใช้และต้นทุนอันละเอียดอ่อนของการมอบอำนาจให้ผู้ใช้

  • ข้อความสำคัญ

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

  • ตัวอย่าง Windows 98

    • Joel ยกตัวอย่างกล่องโต้ตอบสุดเหลือเชื่อที่โผล่มาเมื่อค้นหาเอกสารช่วยเหลือใน Windows 98
    • เหตุผลที่กล่องโต้ตอบนี้ทำให้ Joel โมโห:
      • มันขัดจังหวะผู้ใช้ตอนที่กำลังพยายามขอความช่วยเหลือ
      • มันขอให้ผู้ใช้ตัดสินใจแบบ ไม่มีข้อมูลรองรับ เกี่ยวกับการปรับฐานข้อมูลให้เหมาะสม
      • Windows หลบเลี่ยงการตัดสินใจและผลักภาระให้ผู้ใช้

  • ขอบเขตการนำไปใช้

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

Raymond Chen "Application compatibility layers are there for the customer, not for the program" (2010)

  • Raymond Chen เป็นหนึ่งในนักพัฒนาที่ทำงานกับทีม Microsoft Windows มายาวนานที่สุด
  • ในบล็อกของเขามีเรื่องเล่าที่ทั้งมีประโยชน์และสนุกเกี่ยวกับประวัติศาสตร์การเขียนโปรแกรมบน Windows หลายพันเรื่อง

  • กรณีคำขอจากลูกค้า

    • คำขอจากลูกค้าเกี่ยวกับโหมดความเข้ากันได้ของ Windows Vista:
      • โปรแกรมที่ออกแบบมาสำหรับ Windows XP และ Windows Server 2003 ประสบปัญหาบน Windows Vista
      • เมื่อตั้งค่าเป็นโหมดความเข้ากันได้ของ Windows XP ก็ทำงานได้ดีบน Vista
      • จึงถามว่าต้องแก้ไขตัวติดตั้งอย่างไร เพื่อให้รันในโหมดความเข้ากันได้ของ XP โดยอัตโนมัติเมื่อทำงานบน Vista

  • อุปมาของ Raymond

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

  • บทเรียน

    • อุปมานี้สนุกมากจนเพิ่งมาสังเกตตอนนี้ว่า Raymond ก็ผิดเหมือนกัน
    • เยาะเย้ยความผิดของนักพัฒนาที่ คาดหวังว่า Windows จะไม่ทำให้แอปพังหลังจากออกเพียงรีลีสเดียว
    • แม้จะไม่เห็นด้วยกับรายละเอียดทั้งหมด แต่ข้อเขียนของ Raymond ก็ทั้งสนุกและเฉียบคมจนมองข้ามข้อบกพร่องเหล่านั้นได้
    • เป็นบทเรียนที่ยอดเยี่ยมเรื่อง การมีอิทธิพลต่อพฤติกรรมผู้ใช้:
      • หากต้องการให้ผู้ใช้ทำบางอย่างที่ช่วยคุณ คุณต้องคิดอย่างรอบคอบจากมุมมองของผู้ใช้ว่าเส้นทางใดคือ เส้นทางที่ต้านทานน้อยที่สุด
      • ถ้าคุณแสดงให้เห็นว่าการทิ้งขยะไว้บนทางเท้าช่วยแก้ปัญหาได้อย่างสมบูรณ์ พวกเขาก็จะทำแบบนั้นต่อไป

Erik Kuefler "Don’t Put Logic in Tests" (2014)

  • ผู้เขียนชอบ unit test มาโดยตลอด และภูมิใจกับโค้ดทดสอบของตัวเองมาก
  • บทความนี้โผล่มาตอนนั่งห้องน้ำและทำให้ตกใจ เพราะมันเปิดโปงว่าเขา เขียนเทสต์ที่แย่มาตลอดทั้งอาชีพ

  • ตัวอย่างเทสต์ที่มีปัญหา

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • ปัญหาที่ค้นพบ

    • ตอนอ่านบทความครั้งแรกก็คิดว่า “นี่มันเหมือนวิธีที่ฉันเขียน unit test เป๊ะเลย!”
    • ทำไมต้องทำให้สตริง http://plus.google.com/ ซ้ำอยู่สองที่ด้วย? สร้าง single source of truth แบบเดียวกับโค้ด production สิ
    • ผู้เขียนทำแบบนั้นมาตลอด คือเพิ่ม helper function, ตัวแปร, และลูป เพื่อลดความซ้ำซ้อนในเทสต์
    • ปัญหาคือแนวทางนี้ซ่อนบั๊กที่ละเอียดอ่อนไว้: ที่จริงแล้วกำลัง assert http://plus.google.com//u/0/photos อยู่ (มี slash สองตัว)

  • สิ่งที่ตระหนักได้

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

Julia Evans “A little bit of plain Javascript can do a lot” (2020)

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

  • ความเข้าใจผิดเกี่ยวกับเฟรมเวิร์ก

    • ตอนเริ่มเรียนรู้การพัฒนา frontend อย่างจริงจัง เขามีภาพว่า JavaScript เป็นภาษายุ่งเหยิงที่ถูกสร้างขึ้นใน 10 วัน และทำงานต่างกันมากในแต่ละเบราว์เซอร์
    • ถ้าจะเขียนเว็บแอป ก็ต้องมีอะไรบางอย่างที่ ทันสมัยและสวยงาม มาคอยปกป้องจากพิษและข้อบกพร่องทั้งหมดของ JavaScript
    • เขาลองใช้เว็บเฟรมเวิร์กยอดนิยมอย่าง Angular, React และ Vue
    • แม้จะเรียนรู้ Vue มากพอแล้ว ก็ยังเสียเวลาอย่างมหาศาลกับปัญหา dependency และกับดักของเฟรมเวิร์ก
    • แม้เฟรมเวิร์ก frontend เหล่านี้จะทำทุกอย่างเพื่อแก้ JavaScript แล้ว แต่ การเขียนโปรแกรมเว็บก็ยังแย่อยู่ดี

  • สิ่งที่ได้ตระหนักจากบทความของ Julia

    • เขาตระหนักว่าตัวเองมั่นใจเกินไปว่า JavaScript ต้องถูกแก้ไข จนไม่เคยให้โอกาสมันเลย
    • ตอนนั้นกำลังทำต้นแบบ TinyPilot และวางแผนจะทำเว็บอินเทอร์เฟซด้วย Vue
    • บทความของ Julia เป็นแรงบันดาลใจให้ลองดูว่า plain JavaScript ไปได้ไกลแค่ไหน
    • โดย ไม่ใช้เฟรมเวิร์ก, ไลบรารี wrapper, build step หรือ Node.js ใช้แค่ JavaScript ธรรมดา (ES2018)
    • เขาคาดอยู่ตลอดว่าจะต้องเจอปัญหาที่บังคับให้เปลี่ยนไปใช้เฟรมเวิร์กหรือ builder แต่ มันไม่เคยเกิดขึ้นเลย
    • แม้จะมีหลุมพรางบางอย่างเกี่ยวกับ WebComponents แต่ก็เทียบไม่ได้เลยกับความเจ็บปวดที่เคยเจอจาก Vue และ Angular

  • อิสรภาพจากการไร้เฟรมเวิร์ก

    • เขาชอบความรู้สึกที่หลุดพ้นจากเฟรมเวิร์ก
    • เวลาเกิด runtime error, stack trace ก็ไม่ใช่ฝันร้ายของโค้ดที่ถูกย่อ แปลงสภาพ และ tree-shake จนเละเทะ
    • เป็นการ debug โค้ดของตัวเอง ในแบบที่เขาเขียนมันไว้
    • อคติของเขาที่มีต่อ JavaScript นั้นผิด
    • JavaScript สมัยใหม่ค่อนข้างดี และได้ซึมซับแนวคิดมากมายจากไลบรารี wrapper จนตอนนี้ไม่ต้องมี wrapper แล้ว
    • เบราว์เซอร์ต่าง ๆ ก็ปรับตัวจนรับประกันพฤติกรรมที่สอดคล้องกันข้ามแพลตฟอร์มและอุปกรณ์ได้
    • ตั้งแต่ปี 2020 เขาไม่ได้ใส่ JavaScript framework หรือ build step เข้าไปในโปรเจกต์ใหม่ใด ๆ อีกเลย และ ไม่เคยหันกลับไปมอง
    • plain JavaScript ให้ประโยชน์ของเฟรมเวิร์กได้ 90% ด้วยความปวดหัวเพียง 5%

Dan McKinley “Choose Boring Technology” (2015)

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

  • แนวคิดหลัก

    • ตอนเริ่มโปรเจกต์ใหม่ มักมี แรงยั่วยวนให้อยากใช้เทคโนโลยีล้ำสมัยที่กำลังเป็นกระแส
    • Google ประกาศฐานข้อมูลใหม่ที่สเกลได้ถึงระดับ exabyte เร็วกว่า Postgres 40% และต้นทุนแค่ 20%
    • ถ้ายังใช้ Postgres ทั้งที่มีทางเลือกใหม่สุดเซ็กซี่อยู่ตรงหน้า ก็ดูเหมือนโง่
    • แต่ในความเป็นจริง เทคโนโลยีใหม่มีบั๊กและจุดอ่อน เพียงแต่ยังไม่ปรากฏชัด
    • พอชนเข้ากับมันก็ไปต่อไม่ถูก
    • Postgres ก็มีปัญหาเหมือนกัน แต่ผ่านประสบการณ์ภาคสนามมา 30 ปีแล้ว จึงมี ทางแก้ที่พิสูจน์แล้วสำหรับแทบทุกปัญหาที่คุณน่าจะเจอ

  • แนวคิดเรื่องโทเค็นนวัตกรรม

    • Dan ยอมรับว่าบางครั้งก็ควรใช้เทคโนโลยีใหม่ แต่ต้องใช้อย่างมีกลยุทธ์และในปริมาณจำกัด
    • ทุกธุรกิจจะได้รับ “โทเค็นนวัตกรรม” ให้ใช้จ่ายอยู่สามอัน
    • ถ้าคุณอยากใช้ฐานข้อมูลใหม่สุดหวือหวา ก็ต้องใช้โทเค็นไปหนึ่งอัน
    • บทความของ Dan เชื่อมเข้ากับบทความของ Julia ได้อย่างเป็นธรรมชาติ
    • ถ้าได้อ่านอย่างใดอย่างหนึ่งในสองบทความนี้ก่อนจะเสียเวลาไปกับ frontend framework ทั้งหมดนั้นก็คงดี

Terence Eden “I’ve locked myself out of my digital life” (2022)

  • Terence Eden เป็นบล็อกเกอร์สายเทคที่สนุกและมีมุมมองหลากหลาย
  • เขาเขียนบทความใหม่หลายชิ้นทุกสัปดาห์ แต่ชิ้นที่ส่งผลกับผมมากที่สุดคือ "ผมขังตัวเองออกจากชีวิตดิจิทัลของตัวเอง"

  • สถานการณ์ภัยพิบัติ

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

  • ข้อคิดที่ได้

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

  • ปัญหาของบริการออนไลน์

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

  • ผลกระทบ

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

โบนัส: "parsing user input" ของ Brad Fitzpatrick (2009)

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

  • คำคมของ Brad Fitzpatrick

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

  • การนำไปใช้

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

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

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

 
shakespeares 2025-10-07

เพราะมีประวัติศาสตร์ จึงมีปัจจุบัน
 
GN⁺ 2025-10-02
ความคิดเห็นจาก Hacker News

  • หลังจากอ่านบทความ "I've locked myself out of my digital life" ก็รู้สึกว่ามันถ่ายทอดความกังวลที่ฉันมีอยู่แล้วแต่ไม่รู้จะอธิบายยังไงได้ดีมาก
    ในโลกแอนะล็อก ฉันอาจพิสูจน์ตัวตนกับมนุษย์ได้ด้วยการโน้มน้าวว่าเป็นใคร แล้วเข้าถึงบัญชีของตัวเองได้ แต่ต่อหน้าอัลกอริทึมอันไร้ปรานีของโลกดิจิทัล ถ้าไม่มีข้อมูลยืนยันตัวตน จะอ้อนวอนแค่ไหนก็ไม่มีประโยชน์
    เพราะแม้แต่บริษัทผู้ให้บริการตัวจัดการรหัสผ่านของฉันเองก็ไม่มีสิทธิ์เข้าถึงรหัสผ่านของฉัน
    ไม่มีแม้แต่คนให้ไปอธิบาย มีเพียงโค้ดเท่านั้นที่เป็นกฎหมาย
    ฉันคิดว่าทุกคนควรเข้าใจปัญหานี้ก่อนจะเรียกร้องให้ตัดขั้นตอนแบบพบหน้ากันออกจากทุกกระบวนการ
    ในบทความมันอาจฟังดูเหมือนเป็นสถานการณ์ที่เกิดขึ้นได้ยาก แต่จริง ๆ แล้วมันเกิดขึ้นได้มากพอในกรณีภัยพิบัติทางธรรมชาติหรือการโจรกรรม
    บทความที่เกี่ยวข้อง: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • ฉันคิดว่าจริง ๆ แล้วมีคนไม่มากนักที่สนับสนุนระบบอัตโนมัติสุดโต่งหรือการลดการพบหน้ากันแบบนี้
      และปัญหานี้ก็ไม่ใช่ปัญหาเฉพาะของ AI เพราะซอฟต์แวร์แบบอิงกฎก็ต่างกันไม่มาก
      ในสหภาพยุโรป (EU) มีกฎหมายรับรองสิทธิที่จะยื่นคัดค้านต่อมนุษย์ได้กับการตัดสินใจใด ๆ ก็ตาม

  • Grug Brained Developer เป็นบทความที่ติดอยู่ในหัวฉันเสมอ แต่กลับไม่มีอยู่ในลิสต์
    ที่จริงอาจเป็นเพราะฉันเห็นด้วยกับมันอยู่แล้ว จึงไม่ได้เปลี่ยนวิธีคิดของฉันมากเท่ากับแค่ทำให้จำได้ขึ้นใจ
    อ้างอิง: https://grugbrain.dev/

    • ในบรรดาส่วนต่าง ๆ ฉันชอบช่วงที่ว่า 'ความรู้สึกดีที่สุดคือการขังปีศาจแห่งความซับซ้อนไว้ในผลึกที่ถูกแก้ไขจนสมบูรณ์ในที่สุด'

    • ฉันเป็นคนสองภาษาที่ใช้ภาษาอังกฤษเป็นภาษาที่สอง ดังนั้นงานเขียนสไตล์ grug brain จึงค่อนข้างอ่านยากและเข้าใจยากสำหรับฉัน
      ฉันเองก็ไม่รู้ด้วยซ้ำว่าคำว่า 'grug' หมายถึงอะไร
      ถึงอย่างนั้นฉันก็ยังสนุกกับการอ่านบล็อกนั้นอยู่ดี

  • ฉันไม่เห็นด้วยกับข้อสรุปเกี่ยวกับ "No Silver Bullet" ของ Fred Brooks
    ฉันไม่เห็นด้วยกับคำกล่าวอ้างช่วงหลัง ๆ ที่ว่า AI ได้ลดความซับซ้อนเชิงแก่นแท้ลงมากพอจะล้มทฤษฎีของ Brooks ได้
    AI อาจเติมส่วนที่ขาดไปโดยอัตโนมัติจากกรณีคล้ายกันได้ แม้สเปกจะไม่สมบูรณ์หรือขัดแย้งกัน แต่ความซับซ้อนเชิงแก่นแท้ก็ยังไม่ถูกคลี่คลายด้วย AI มากพอ และฉันคิดว่าในอนาคตก็คงเป็นไปไม่ได้เช่นกัน
    การวิเคราะห์โดยละเอียดของฉันเกี่ยวกับเรื่องนี้อยู่ที่นี่: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • ขอบคุณที่อ่านและแชร์บทความของฉัน
      อย่างที่คุณพูดไว้ในคำอธิบาย ฉันเห็นด้วยว่า LLM ไม่สามารถกำจัดความซับซ้อนเชิงแก่นแท้ได้ทั้งหมด
      แต่ฉันคิดว่า LLM สามารถลดความซับซ้อนเชิงแก่นแท้ได้ในระดับหนึ่ง
      ยกตัวอย่างจริง ฉันเคยขอให้ Claude 4.1 Opus ช่วยนิยาม domain-specific language สำหรับภาพที่สร้างด้วยคอมพิวเตอร์
      ฉันแค่บอกความต้องการ แล้วปล่อยให้รายละเอียดบางส่วนคลุมเครือไว้ แต่ LLM ก็ยังสามารถเขียนสเปกออกมาได้
      ในกรณีแบบนี้ ฉันมั่นใจได้ว่า LLM ลดความซับซ้อนเชิงแก่นแท้ลงจริง
      ฉันเองก็สามารถนิยามมันใหม่ให้มีคุณภาพสูงได้ด้วยตัวเอง แต่ถ้าผลลัพธ์ที่ LLM ให้มาดีพอ ก็ยิ่งมีเหตุผลน้อยลงที่จะทุ่มแรงเพิ่มเพื่อยกระดับคุณภาพ
      เดิมทีฉันรู้สึกว่าไม่ค่อยจำเป็นต้องใช้ LLM เพราะปกติฉันเขียนโค้ดได้ดีกว่าและก็สนุกกับมันมากกว่า แต่พอได้ลองใช้จริงก็พบว่า LLM รับภาระความซับซ้อนเชิงแก่นแท้ไปได้มากในส่วนที่ฉันไม่จำเป็นต้องเสียเวลาและพลังงานเอง
      ตัวอย่าง: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • ความซับซ้อนที่ AI ลดให้ได้ สุดท้ายแล้วมีแค่ภาระทางการรับรู้ของคนที่เขียนโค้ดเท่านั้น
      'ความซับซ้อนที่ไม่ใช่สาระสำคัญ (nonessential complexity)' ที่ Brooks พูดถึงยังคงอยู่ในตัวโค้ดแทบทั้งหมด
      ผลลัพธ์คือภาระนั้นถูกผลักไปให้คนที่ต้องมาอ่านโค้ดแทน
      มันเหมือนกับใส่ชุด exoskeleton แล้วยกของหนักขึ้นไปวางบนชั้น ก่อนจะบอกเพื่อนร่วมงานให้มาทาสีมันให้สวย

  • สำหรับฉันแล้ว บทความ "Parse, don't validate" คือคลาสสิกชิ้นเอก
    และฉันรู้สึกว่าเห็นด้วยได้ยากกับประโยค "Don't put logic in tests"
    ปัญหาในตัวอย่างเกิดจากการที่ควรใช้ชนิด URI แทนสตริง แต่ฉันคิดว่าโค้ดทดสอบก็ควรถูกมองเป็น production code เช่นกัน เพราะมันมีผลต่อความสำเร็จหรือความล้มเหลวของการปล่อยระบบ
    อย่างไรก็ดี การถกเถียงแบบนี้ก็คุ้มค่ามากที่จะอ่านด้วยตัวเองและคิดดูว่านำไปใช้กับตัวเองได้หรือไม่

    • ฉันเองก็แปลกใจเหมือนกันที่ "Parse, don't validate" ไม่ค่อยเป็นที่รู้จัก
      รอบตัวฉันส่วนใหญ่เป็นคนทำ Go, Python, C++ ก็เลยอาจเป็นแบบนั้น และดูเหมือนจะดังเฉพาะฝั่งภาษาเชิงฟังก์ชัน
      ฉันคิดว่ามุมมองเชิงวิจารณ์ต่อกรณีตัวอย่างของ "Don't put logic in tests" ก็มีเหตุผลดี
      ตัวอย่างอาจปรับให้ดีขึ้นได้อีกหน่อย แต่แก่นสำคัญคือแม้แต่การต่อสตริงง่าย ๆ ก็สามารถเพิ่มความซับซ้อนให้กับการทดสอบและทำให้พลาดบั๊กได้

    • ส่วนตัวแล้วฉันชอบแนวคิดที่ว่าไม่ควรใส่ลอจิกเข้าไปในเทสต์มากเกินไป
      ฉันเคยเจอ false positive จากบั๊กในโค้ดทดสอบมาหลายครั้ง จนเริ่มไม่ไว้ใจเรื่องแบบนี้
      ฉันคิดว่าเราไม่ควรรู้สึกว่าจำเป็นต้องเขียน 'เทสต์ของเทสต์'
      ในทางปฏิบัติกรณีแบบนี้อาจพบไม่บ่อย แต่ช่วงนี้ปัญหากลับหนักขึ้นเพราะโค้ดทดสอบห่วย ๆ ที่ LLM เขียนกำลังกลายเป็นกระแสหลัก โดยไม่เกี่ยวว่าจะยึดแนวคิดนี้หรือไม่ก็ตาม

  • ขอแนะนำงานสืบสวนและบทความทบทวนอุบัติเหตุ Therac-25 ของ Nancy Leveson

  • สำหรับฉัน บทความที่ชอบที่สุดในสายนี้คือ "The Parable of the Two Programmers" ของ Neil W. Rickert
    มันเป็นเรื่องเล่าที่สรุปชีวิตและความท้าทายของโปรแกรมเมอร์ได้อย่างกระชับ
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • ฉันรู้จัก Neil ค่อนข้างดี เพราะตลอดหลายปีที่ผ่านมาเราโต้ตอบกันบ่อยใน Usenet newsgroup ชื่อ comp.ai.philosophy
      น้ำเสียงและเนื้อหาของบทความนี้เป็นสไตล์ของเขามากจริง ๆ

    • บทความนี้ยอดเยี่ยมจริง ๆ

  • สำหรับฉัน บทความนี้คือจุดเปลี่ยน
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell ไม่ได้มีชื่อเสียงมากนักในที่นี่

    • ขอบคุณที่แชร์!
      ฉันเพิ่งได้อ่านบทความนี้เป็นครั้งแรก แต่ช่วงต้นอาชีพฉันเคยอ่าน Code Complete แล้วประทับใจมาก
      ฉันเก็บมันไว้บนชั้นหนังสือตลอด และทุกครั้งที่หยิบกลับมาอ่านไม่กี่หน้าก็จะคิดว่า 'นี่มันยอดเยี่ยมจริง ๆ! ต้องกลับมาอ่านใหม่อีกครั้งแล้ว'
      ฉันไม่ได้ยินข่าวของ McConnell มาพักใหญ่ เลยสงสัยว่าในขณะที่นักเขียนร่วมยุคอย่าง Kent Beck, Martin Fowler, Ward Cunningham และคนอื่น ๆ แม้ความนิยมจะลดลงหลังยุค 2000 แต่ก็ยังเขียนงานต่อไป ทำไม McConnell ถึงเงียบไป
      แล้วก็พบว่าเขาเลิกทำซอฟต์แวร์และผันตัวไปเป็นที่ปรึกษาการเงิน ซึ่งทำให้ฉันตกใจแบบเงียบ ๆ เหมือนกัน
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • แม้จะไม่ใช่บทความซอฟต์แวร์แบบดั้งเดิมนัก แต่บล็อกโพสต์ "Ban on Imports" ของ Gilad Bracha ทำให้มุมมองของฉันต่อระบบโมดูลเปลี่ยนไปอย่างสิ้นเชิง
    เขาเน้นว่า import/export นั้นเทียบได้กับ global state และด้วยเหตุนี้มันจึงพกพาปัญหาทั้งหมดของ global state มาด้วย
    หลังจากนั้นฉันก็เห็นคุณค่าของแนวคิด dependency injection มากขึ้นมาก
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • อาจจะแยกเป็นบทความซอฟต์แวร์โดยเคร่งครัดได้ไม่ชัดนัก แต่ "Don't Call Yourself A Programmer, And Other Career Advice" ของ Patrick McKenzie เป็นขุมทรัพย์อย่างแท้จริง
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • ในฐานะคนที่สนใจภาษาโปรแกรมมาก ฉันจำบทความ "slumming with basic programmers" ได้ติดหัวมาก
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

เห็นด้วยกับเรื่องการพาร์สอินพุตของผู้ใช้มากจริงๆ
โปรแกรมเมอร์จำนวนไม่น้อยที่พัฒนาฟังก์ชันกรอกหมายเลขโทรศัพท์สำรอง เขาทำงานกันอยู่ในสภาพแวดล้อมแบบไหนถึงได้กลัวการเรียก replace() กับสตริงแค่สองครั้งกันนักนะ?