นักพัฒนาเดี่ยวเลิกติดกับดัก Over-Engineering โครงการ
บทเรียนจากนักพัฒนาอิสระที่เสียเวลาตั้งค่า Kubernetes สามสัปดาห์ให้โปรเจกต์ที่ไม่มีผู้ใช้ พร้อมแนะวิธีเลือกเทคโนโลยีที่เรียบง่ายเพื่อส่งมอบงานให้ไวขึ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- นักพัฒนาเดี่ยวเสียเวลาไปกับโครงสร้างพื้นฐานมากกว่าการสร้างฟีเจอร์
- หนี้ทางเทคนิคไม่ใช่ปัญหาใหญ่เท่ากับการไม่มีฐานผู้ใช้งาน
- ควรเลือกใช้เทคโนโลยีที่เชี่ยวชาญแล้วเพื่อลดระยะเวลาพัฒนา
- เป้าหมายหลักคือการตรวจสอบความต้องการของตลาดด้วยการส่งมอบงานให้เร็ว
นักพัฒนาอิสระหลายคนมักตกหลุมพรางของการสร้างระบบที่ซับซ้อนเกินความจำเป็น เช่นเดียวกับประสบการณ์ของผู้พัฒนาที่เคยใช้เวลาถึงสามสัปดาห์ในการตั้งค่าคลัสเตอร์ Kubernetes และสถาปัตยกรรมแบบ event-driven ให้กับโปรเจกต์ที่มีผู้ใช้งานเป็นศูนย์ โดยให้เหตุผลกับตัวเองว่าเป็นการเตรียมความพร้อมเพื่อรองรับการเติบโตในอนาคต แต่ในความเป็นจริงแล้ว กลับเป็นการหลีกหนีงานที่ยากที่สุด นั่นคือการพัฒนาฟีเจอร์ที่ผู้คนต้องการใช้งานจริง
เมื่อคุณเป็นนักพัฒนาเดี่ยวหรือ solopreneur ศัตรูที่น่ากลัวที่สุดไม่ใช่หนี้ทางเทคนิค (technical debt) แต่เป็นการขาดแคลนฐานผู้ใช้งาน เพราะหนี้ทางเทคนิคจะมีความหมายก็ต่อเมื่อผลิตภัณฑ์ของคุณมีชีวิตรอดจนเติบโตพอที่จะถูกชะลอด้วยปัญหาดังกล่าว ซึ่งโปรเจกต์ส่วนใหญ่ล้มหายตายจากไปก่อนที่จะถึงจุดนั้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ความตื่นเต้นตามกระแสเทคโนโลยีใหม่ๆ มักทำให้ไขว้เขวได้ง่าย ไม่ว่าจะเป็นการเห็นกระทู้เกี่ยวกับเฟรมเวิร์กใหม่ที่เคลเรื่องความปลอดภัยของประเภทข้อมูลหรือความเร็วในการคอมไพล์ จนทำให้เสียเวลาวันหยุดไปกับการย้ายระบบจัดการสถานะเพียงเพราะไลบรารีใหม่ดูสะอาดตากว่า แต่ความจริงที่โหดร้ายคือผู้ใช้งานไม่สนใจว่าคุณจะใช้ Redux, Zustand หรือแค่วัตถุส่วนกลาง พวกเขาไม่สนว่าแบ็กเอนด์จะเขียนด้วย Go, Rust หรือสคริปต์ Node.js พื้นฐาน สิ่งที่ผู้ใช้งานสนใจมีเพียงแค่ปุ่มกดได้งานจริงและหน้าเว็บโหลดเสร็จหรือไม่
ทุกชั่วโมงที่คุณหมดไปกับการปรับแต่งท่อส่งข้อมูล CI/CD คือเวลาที่คุณไม่ได้พูดคุยกับผู้ใช้งานหรือแก้ไขข้อบกพร่องในระบบหัวใจสำคัญของแอปพลิเคชัน การเป็นนักพัฒนาเดี่ยวหมายความว่าคุณต้องสวมหมวกหลายใบ ทั้งประธานเจ้าหน้าที่บริหาร ผู้จัดการผลิตภัณฑ์ และพนักงานทำความสะอาด คุณจึงไม่มีงบเวลามากพอที่จะเป็นวิศวกรโครงสร้างพื้นฐานเต็มเวลาด้วยเช่นกัน
"Write the simplest code that solves the problem. If it becomes a mess later, that is a high class problem because it means you have enough users to justify the time it takes to refactor."
Dev.to
ในทางวิศวกรรมซอฟต์แเวอร์ระดับองค์กร การแยกส่วนประกอบ การสร้างชั้นนามธรรม (abstraction layers) และบริการแบบโมดูลาร์ถือเป็นสิ่งจำเป็นเพื่อป้องกันไม่ให้พนักงานหลายสิบคนทำงานทับซ้อนกัน แต่เมื่อทำงานคนเดียว การสร้างชั้นความซับซ้อนเหล่านี้มักกลายเป็นกำแพงที่กั้นระหว่างตัวคุณกับโค้ดของตัวเอง ทางออกที่ดีที่สุดคือการเลือกใช้สแต็กเทคโนโลยีที่คุ้นเคย เช่น หากถนัด Rails, Laravel หรือ Express กับ Postgres ก็ควรยึดติดกับสิ่งนั้น เพื่อให้สมองได้คิดถึงปัญหาทางธุรกิจแทนที่จะต้องมานั่งเปิดอ่านคู่มือ
เป้าหมายสำหรับโปรเจกต์อิสระคือการลดระยะทางระหว่างไอเดียกับฟีเจอร์ที่ถูกdeploy ให้สั้นที่สุด หลีกเลี่ยงการใช้โปรเจกต์ส่วนตัวเป็นสนามเด็กเล่นเพื่อเรียนรู้ภาษาใหม่ เว้นแต่เป้าหมายหลักคือการศึกษาหาความรู้ หากเป้าหมายคือการปล่อยผลิตภัณฑ์ออกสู่ตลาด ให้เลือกใช้สิ่งน่าเบื่อเพราะความน่าเบื่อคือความเสถียร เขียนได้รวดเร็ว และแก้ไขข้อบกพร่องได้ง่ายตอนตีสอง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น