ดาวเหนือด้านซอฟต์แวร์ของฉัน

ลำดับความสำคัญในการพัฒนาซอฟต์แวร์

1. ซอฟต์แวร์ต้อง มีประโยชน์ต่อผู้ใช้ปลายทาง และมุ่งหวังที่จะเป็น "ซอฟต์แวร์ที่คุณรักได้"
2. ซอฟต์แวร์ต้อง ถูกต้อง (correct) ซอฟต์แวร์ที่ทำงานผิดพลาดย่อมลดทอนประโยชน์ที่ผู้ใช้จะได้รับ
3. ซอฟต์แวร์ต้อง ดูแลรักษาได้และมีประสิทธิภาพ นี่คือเกณฑ์เพื่อหลีกเลี่ยงการสิ้นเปลืองทรัพยากรของมนุษย์และการประมวลผล เมื่อต้องการดึงประโยชน์จากซอฟต์แวร์ให้ได้มากขึ้น

ความไร้ความหมายเมื่อสลับลำดับความสำคัญ

• ต่อให้บล็อกเชนไม่มีบั๊ก ก็ไม่มีความหมายถ้ามันเป็น rugpull
• ต่อให้ภาษาที่ใช้จะ memory-safe ก็ไม่มีความหมาย หากไม่มี การออกแบบเพื่อความถูกต้อง และไม่มีกระบวนการ ค่อย ๆ แก้บั๊กทั้งหมดในท้ายที่สุด
• ต่อให้ซอฟต์แวร์มี ชั้นนามธรรมที่งดงาม (canopy of abstractions) ก็ไม่มีความหมาย หากมันทำงานได้แย่ และไม่มีใครดูแลรักษาหรือเพิ่มฟีเจอร์ใหม่ได้

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

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

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ชอบแนวทางที่คล้ายกัน
  แม้จะเป็นเครื่องมือที่ไม่ได้ “น่ารักน่าชัง” แบบไขควง แต่ก็อาจมี ความน่าเชื่อถือ สูงได้เป็นเวลานานมาก ไขควงแฉกก็เป็นหัวแฉกเสมอ ไม่มีโอกาส 1% ที่พอหยิบออกจากกล่องเครื่องมือแล้วมันจะกลายเป็นไขควงปากแบนจนต้องเก็บกลับแล้วหยิบใหม่ อีกทั้งดีไซน์ด้ามจับก็ไม่ได้เปลี่ยนไปเรื่อย ๆ ไม่รู้จบ และเครื่องมือที่ซื้อมาแล้วก็ใช้ไปได้เรื่อย ๆ จนกว่าจะพัง
  อยากให้มี ซอฟต์แวร์ ที่เป็นแบบนั้นมากขึ้น

  • สงสัยว่าคำว่า “เครื่องมือที่ไม่ได้น่ารักน่าชังแบบไขควง” หมายถึงอะไร

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

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

• เพิ่งรู้จากโพสต์นี้ว่า Tiger Style มีเว็บไซต์แล้ว

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

• คำพูดที่ว่า “ต่อให้บล็อกเชนไม่มีบั๊ก ถ้าเป็น rug pull ก็ไม่มีความหมาย” นี่ใส่สามประเด็นไว้ในประโยคเดียวได้เลย
  การเพิ่มประสิทธิภาพของบางสิ่งไม่มีความหมายถ้ามันสร้างบั๊กใหม่ขึ้นมา และทั้งหมดนั้นก็มีความหมายก็ต่อเมื่อมันไม่ใช่ rug pull ด้วย

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

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