It is not an easy path
- rails
- ruby
เมื่อเส้นทางไม่ได้โรยด้วยกลีบกุหลาบ ก็ต้องพยายามและฝ่าฝันกันไป
เชื่อว่าหลายๆ คนคงเคยมีประสบการณ์ที่จะต้องแก้ไขโค้ดของคนอื่น หรือต่อยอดโปรเจ็คเดิมซึ่งใครทำไว้ก็ไม่รู้ ซึ่งผมมักจะเรียกว่า Lagacy Project หรือโปรเจ็ค 💩 นั้นเอง 555+ โดยในบทความนี้จะมาเล่าถึงประสบการณ์ที่ได้รับจากการที่ทีมต้องมาช่วงต่อในการแก้ไขและปรับปรุงโปรเจ็คหนึ่งเข้า
- ก่อนอื่นก็ต้องขอเกริ่นถึงตัวงานของโปรเจ็คสักนิดหนึ่ง โดยโปรเจคนี้ถูกพัฒนาด้วยภาษา Java ในส่วนของ Backend และใช้ JavaScript บวกกับ jQuery ในส่วนของ Frontend ซึ่งถูกก็เรียกว่า ตึ๊ดตี๊ด เฟรมเวิร์ค (ขออนุญาตเซนเซอร์ชื่อไว้นิดหนึ่ง)
Architecture
-
ถ้าดูจากภาพรวมแล้ว ผมคิดว่าตัวโครงสร้างเองก็แบ่งได้ชัดเป็น 2 ส่วน (Frontend และ Backend) แบบนี้ผมก็สามารถแบ่งงานให้ทีมได้ไม่ยาก
-
ภาพรวมใช้ได้แหละ ก็ต้องไปไล่ศึกษาโค้ดกันหน่อยก่อนที่จะแก้ไขกันจริง เพื่อจะได้เป็นแนะนำทีมได้ และแล้วความสนุกก็บังเกิดไม่ว่าจะเป็นโค้ดในฝั่ง Frontent หรือ Backend ผมรู้สึกได้ว่าเป็นการเขียนโค้ดที่มีความเป็น ตี๊ดตี๊ด เฟรมเวิร์ค จนรู้สึกว่าการที่จะให้น้องๆ ในทีมเข้าไปแก้ไข หรือจะเพิ่มฟีเจอร์นั้นไม่ใช่เรื่องง่ายเลยทีเดียว จึงกลายมาเป็นคำถามย้อนกลับมาที่ตัวผมว่า “ตกลงเราจะแก้ไขโปรเจคเดิม หรือจะพัฒนาขึ้นใหม่ดี”
-
รีวิวร่วมกันอีกรอบ ที่แน่ๆ คราวนี้เราช่วยกันดูทั้งทีม และก็ถามความคิดเห็นทั้งทีมว่า “ตกลงเราจะแก้ไขโปรเจคเดิม หรือจะพัฒนาขึ้นใหม่ดี” ทั้งนี้เราก็ไม่ตัดสินใจจากการรีวิวโค้ดแต่เพียงอย่างเดียว ยังมีปัจจัยอื่นๆ ที่ต้องพิจารณาร่วมด้วยดังนี้
- เทคโนโลยีที่ใช้งาน ซึ่งของเดิมนั้นค่อนข้างจะเก่า ไลบราลีที่ใช้งานก็ไม่ได้มีการอัพเดต และมีบางตัวที่เลิกใช้ไปบางแล้ว
- ระยะเวลาที่จำกัด ถือเป็นความเสี่ยงหลักของเราเลยที่เกรงว่าจะพัฒนาตัวใหม่ขึ้นมาไม่ทันตามกรอบเวลาที่มี
- เอกสารรายละเอียดเกี่ยวกับ Requirements และ Flow ที่หายสาบสูญ นั้นกลายเป็นคำถามแล้วเราจะพัฒนาโปรแกรมให้มีฟีเจอร์ตามเดิมได้อย่างไร? เพราะเอกสาร Requirements ใหม่ก็จะอธิบายฟีเจอร์ที่เคยแต่ละฟีเจอร์ไว้เพียงสั้นๆ
สุดท้ายเราก็ได้คำตอบออกมาคือ พัฒนาขึ้นใหม่ ให้เทียบเท่าของเดิม และเพิ่มฟีเจอร์ตาม Requirements ใหม่ ซึ่งเป็นการตัดสินใจร่วมกันของทั้งทีม
-
จากปัจจัยต่างๆ ทำไมถึงยังตัดสินใจพัฒนาโปรแกรมขึ้นใหม่ แทนที่จะแก้ไขของเดิม? เวลาก็จำกัด ความเข้าใจใน Requirements และ Flow ก็ไม่มาก
- ภาษา และเทคโนโลยีที่ใช้งานไม่เหมือนกัน อันนี้เราก็ต้องเลือกใช้ภาษา และเทคโนโลยีที่เราถนัดไว้ก่อน เพื่อจะช่วยทำให้เราพัฒนาได้เร็วยิ่งขึ้น
- ถึงแม้เวลาจะดูจำกัด แต่อันนี้ผมใช้ประสบการณ์ความเร็วของทีมในการพัฒนาโปรเจคอื่นๆ มาตัดสินใจ และคิดว่าน่าจะทันตามเวลา
- เอกสารไม่มี ก็ต้องทำฟีเจอร์เก่าด้วยก็ถือว่ายากมาก แต่มีคนที่รู้ Flow อยู่ก็ค่อยประชุมเก็บรายละเอียดกันจากคนที่รู้กันใหม่แล้วกัน
ไม่ว่าจะเลิกทางใดก็มีความเสี่ยงทั้งหมด ดังนั้นเลือกทางที่คุ้มค่าจะเสี่ยงแล้วกัน
- Ruby + Rails + StimulusJS เป็นภาษา และเฟรมเวิร์คที่ใช้ในการพัฒนา
- Ruby เป็นภาษาที่สนุก และเรียนรู้ได้เร็ว
- ด้วยความที่ Rails เป็นเฟรมเวิร์คที่ครบครัน ทำให้เราหยิบจับ Gem หรือไลบราลีอื่นๆ มาใช้ร่วมกับโปรเจค ยิ่งทำให้เราพัฒนาโปรแกรมได้เร็วยิ่งขึ้น
- StimulusJS เป็นเฟรมเวิร์คของ JavaScript ที่เรียบง่าย และขนาดเล็กอันหนึ่งในการจัดการกับ Frontend ผมเชื่อว่าหลายๆ คนคงไม่รู้จัก แต่เชื่อเถอะว่าถ้าคุณได้รู้จัก และลองใช้แล้วคุณจะไม่ลืมมันอีกเลย
- Docker + Docker Compose เป็นเครื่องมือที่ใช้ในการติดตั้งโปรแกรมสำหรับ Development และ Production
- จากที่เคยใช้แบบงูๆ ปลาๆ พอได้ใช้งานแบบจริงจัง ตอนแรกก็รู้สึกยาก และ config ไม่ค่อยถูก พอได้เรียนรู้เพิ่มขึ้นก็รู้สึกมันก็สะดวกดีในการใช้สำหรับ Production
- Sentry เป็นอีกหนึ่งเครื่องมือที่ได้นำมาใช้ในการติดตามปัญหาที่เกิดขึ้นกับโปรแกรมของเราไม่ว่าจะเป็น Development หรือ Production
- ต้องยอมรับเลยว่าเป็นเครื่องมือที่ดีจริงๆ ทำให้ทางทีมสามารถรู้ถึงรายละเอียดของปัญหา และเข้าไปแก้ไขได้ถูกต้อง
!!! D-DAY วันที่ 1 ตุลาคม 2563 เป็นวันที่จะต้องปล่อยโปรแกรมให้ใช้งาน หลังจากที่ตรากตรำพัฒนาร่วม 3 เดือนเต็มๆ ซึ่งในทีมของผมจะประกอบไปด้วย
- ผู้พัฒนาหลัก 3 คน
- ผู้ทดสอบโปรแกรม 1 คน
- ผู้ดูแลเกี่ยวกับฐานข้อมูล และรายงาน 1 คน
ภาพตัวอย่างหน้า Login
ภาพตัวอย่างหน้า Dashboard
ทั้งนี้ก็ต้องขอบคุณน้องๆ ในทีมทุกคน ที่ร่วมมือช่วยกันทำให้การพัฒนาโปรเจคนี้สำเร็จได้ตามที่ตั้งใจไว้ แม้ว่าแต่ละคนอาจจะมีบทบาทที่แตกต่างๆ กันแต่ถ้าขาดคนใดคนหนึ่งไปก็คงไม่สามารถสร้างชิ้นงานชิ้นนี้ขึ้นมาได้
ถึงแม้ว่าทีมจะประสบความสำเร็จในการพัฒนาโปรแกรมไปได้ระดับหนึ่ง และนำไปใช้งานได้ตามเวลาที่กำหนด แต่ก็ยังมีอีกหลายจุดที่ทีมยังขาด และบางจุดก็สามารถพัฒนาเพิ่มเติมให้ดียิ่งขึ้นไปได้ ซึ่งผมก็มองว่าทีมของผมจะพัฒนาต่อๆ ไป