ปี 2024, วิธีที่ผมเขียนโปรแกรม

 (akkartik.name)
2 คะแนน โดย GN⁺ 2024-08-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะเคยพูดถึงวิธีเลือกโปรแกรมที่ใช้งานได้ยาวนานและวิธีสร้างโครงสร้างพื้นฐานที่เชื่อถือได้ แต่ก็ยอมรับว่ายังทำสิ่งนั้นได้ไม่ดีนัก
  • ช่วงเดือนที่ผ่านมาได้เขียนแกนหลักของโปรแกรมที่ใช้งานมา 2 ปีขึ้นใหม่ และจากนั้นก็ได้ย้อนมองการเปลี่ยนแปลงด้านการเขียนโปรแกรมตลอดชีวิตที่ผ่านมา

ปี 2015

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

ปี 2017

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

ปี 2022

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

ปี 2024

  • เมื่อเดือนก่อนลบการทดสอบทั้งหมดทิ้ง
  • ปรับโครงสร้างโปรแกรมแก้ไขข้อความใหม่แบบถอนราก โดยใช้วิธีที่เคยกังวลว่าจะทำให้เกิด merge conflict กับ Freewheeling Apps ตัวอื่น
  • เลิกกังวลเรื่องการจัดการเวอร์ชัน
  • เลิกยึดติดกับการทดสอบและเวอร์ชัน แล้วกลับสร้างโปรแกรมที่ดีกว่าเดิมได้มาก

มุมมองแบบบูรณาการในปัจจุบันต่อการเขียนโปรแกรมอย่างยั่งยืน

  1. การสร้างสิ่งที่ยั่งยืนสำหรับคนจำนวนมากนั้นยากเกินไป จึงไม่ควรแม้แต่จะพยายาม
  2. ซอฟต์แวร์ส่วนใหญ่ติดกับดักแรงจูงใจที่ต้องการให้บริการคนจำนวนมากในระยะสั้น ให้โฟกัสกับซอฟต์แวร์ที่มีโลโก้น้อย สร้างง่าย มี dependency น้อย และไม่อัปเดตอัตโนมัติ
  3. การเปลี่ยนแปลงเล็กน้อยของบริบทอาจเปลี่ยนไปอย่างสิ้นเชิงว่าตัวโปรแกรมเหมาะกับบริบทนั้นดีแค่ไหน
  4. โปรแกรมใหม่ย่อมมุ่งหน้าไปสู่โลกที่ยังไม่รู้จักไม่ทางใดก็ทางหนึ่ง หลายครั้งเราไม่รู้ชัดว่ากำลังทำอะไรอยู่ไม่ว่าจะไปในทิศทางไหน
  5. type, abstraction, การทดสอบ, เวอร์ชัน, state machine, immutability, formal analysis ฯลฯ คือเครื่องมือที่ใช้ได้เมื่ออยู่ในภูมิประเทศที่ยังไม่คุ้นเคย
  6. อย่างหลีกเลี่ยงไม่ได้ เราจะใช้เครื่องมือเหล่านี้บางอย่างมากเกินไป ปริมาณการใช้ที่เหมาะสมจริง ๆ น้อยกว่าที่เราคิดมาก การใช้เกินคือหนี้ทางเทคนิค
  7. เมื่อความเข้าใจในบริบทนิ่งพอแล้ว การทิ้งโปรแกรมไปเป็นส่วนใหญ่และเริ่มใหม่ตั้งแต่ต้นนั้นมีคุณค่า
  8. ก่อนจะเขียนใหม่ ต้องใส่ทุกอย่างที่ต้องการจากโปรแกรมและทุกสถานการณ์ที่โปรแกรมต้องรองรับไว้ในหัวพร้อมกันทั้งหมด
  9. สร้างทุกอย่างในคราวเดียว
  • การทดสอบและการจัดการเวอร์ชันเป็นอุปสรรคต่อการไปถึงปลายทางสุดท้ายของวิวัฒนาการนี้
  • การทดสอบทำให้เราลืมความกังวล ส่วนการจัดการเวอร์ชันทำให้เรายึดติดกับอดีต

ความเห็นของ GN⁺

  • ถ้าโปรแกรมซับซ้อนเกินไป การจำทุกอย่างไว้ในขั้นที่ 8 อาจเป็นไปไม่ได้ ซึ่งใช้ได้กับซอฟต์แวร์ส่วนใหญ่ โดยเฉพาะซอฟต์แวร์ที่มีคนเขียนมากกว่าหนึ่งคน
  • ซอฟต์แวร์ไม่ได้จำเป็นต้องไปถึงขั้นที่ 9 เสมอไป Freewheeling Apps จำนวนมากเรียบง่ายพอและวิวัฒนาการช้าพอที่จะคงตัวจนแทบไม่มีบั๊กได้ แม้จะมีผู้ใช้เพียงไม่กี่คน และไม่ว่าตัวเลือกการออกแบบตั้งต้นจะเป็นแบบใด
  • data-oriented design มีประโยชน์อย่างชัดเจนต่อการไปถึงขั้นที่ 9 มันไม่ใช่เครื่องมือที่ใช้แบบหลับหูหลับตาได้ แต่เป็นกรอบคิดที่มองภาพใหญ่ของวิธีที่โปรแกรมเข้าถึงข้อมูล โดยไปไกลกว่าการเลือก immediate data structure
  • ขั้นตอนเหล่านี้อาจไม่ได้ถูกต้องทั้งหมด อาจกำลังประเมินเครื่องมือที่ยังมีประสบการณ์น้อยต่ำเกินไป
  • สงสัยว่าหลังจากขั้นตอนเหล่านี้แล้วจะยังมีขั้นไหนต่อไปอีก

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

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

 
GN⁺ 2024-08-06
ความเห็นจาก Hacker News

  • ถ้าไม่มีเทสต์ ก็จะมองไม่เห็นปัญหา ทำให้ดูเหมือนว่าปัญหาหายไปแล้ว

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

  • เมื่อเลิกใช้เทสต์และเวอร์ชันแล้ว กลับได้โปรแกรมที่ดีกว่าเดิม

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

  • ตอนแรกคิดว่าผู้เขียนคิดผิด แต่ก็มีมุมมองที่น่าสนใจ

    • เวิร์กโฟลว์นี้เหมาะกับผู้เขียนมาก
    • น่าจะเคยมีประสบการณ์ที่ Git หรือ automated testing ทำให้ประสิทธิภาพลดลง
    • ยังมีทางเลือกที่ง่ายกว่านี้ด้วย (เช่น Dropbox, FTP)
    • ผู้เขียนชอบสร้างโปรแกรมขนาดเล็ก
    • automated testing มีประโยชน์ แต่ในกรณีของผู้เขียนอาจยังไม่คุ้มค่า

  • การจัดการเวอร์ชันและ automated testing แก้ปัญหาที่มีอยู่จริง

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

  • ตอนเขียน/รีแฟกเตอร์โปรแกรมขนาดใหญ่ การเขียนแล้วทิ้ง แล้วเขียนใหม่อีกครั้ง เป็นสิ่งสำคัญ

  • บทความนี้ทำให้งง

    • สงสัยว่าทำไมถึงได้อัปโหวตเป็นอันดับแรก

  • การเปลี่ยนแปลงเล็กน้อยอาจเปลี่ยนความเหมาะสมของโปรแกรมได้อย่างมาก

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

  • การสร้างซอฟต์แวร์คนเดียวกับการสร้างเป็นทีมต่างกันโดยสิ้นเชิง

    • เทสต์เป็นวิธีการ ไม่ใช่เป้าหมาย
    • เวลามั่นใจก็จะเขียนเทสต์น้อยลง
    • เพิ่ม integration test ในส่วนที่สำคัญ
    • unit test มีประโยชน์กับการออกแบบ API ใหม่

  • เริ่มทำงานกับ Freewheeling Apps ในปี 2022

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

  • ไม่เห็นด้วยกับแนวคิดที่ว่าการเปลี่ยนแปลงเล็กน้อยอาจเปลี่ยนความเหมาะสมของโปรแกรมได้มาก

    • การมองระยะสั้นคือการปรับตัวเข้ากับการเปลี่ยนแปลงเล็กน้อย

  • ชอบผู้เขียน และชอบโปรเจกต์ Mu

    • เป็น Lisp machine แบบสมัยใหม่

  • รู้สึกถูกความซับซ้อนของ software engineering ถาโถม

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