It is not an easy path

• rails
• ruby

เมื่อเส้นทางไม่ได้โรยด้วยกลีบกุหลาบ ก็ต้องพยายามและฝ่าฝันกันไป

เชื่อว่าหลายๆ คนคงเคยมีประสบการณ์ที่จะต้องแก้ไขโค้ดของคนอื่น หรือต่อยอดโปรเจ็คเดิมซึ่งใครทำไว้ก็ไม่รู้ ซึ่งผมมักจะเรียกว่า Lagacy Project หรือโปรเจ็ค 💩 นั้นเอง 555+ โดยในบทความนี้จะมาเล่าถึงประสบการณ์ที่ได้รับจากการที่ทีมต้องมาช่วงต่อในการแก้ไขและปรับปรุงโปรเจ็คหนึ่งเข้า

• ก่อนอื่นก็ต้องขอเกริ่นถึงตัวงานของโปรเจ็คสักนิดหนึ่ง โดยโปรเจคนี้ถูกพัฒนาด้วยภาษา Java ในส่วนของ Backend และใช้ JavaScript บวกกับ jQuery ในส่วนของ Frontend ซึ่งถูกก็เรียกว่า ตึ๊ดตี๊ด เฟรมเวิร์ค (ขออนุญาตเซนเซอร์ชื่อไว้นิดหนึ่ง)

Architecture

• ถ้าดูจากภาพรวมแล้ว ผมคิดว่าตัวโครงสร้างเองก็แบ่งได้ชัดเป็น 2 ส่วน (Frontend และ Backend) แบบนี้ผมก็สามารถแบ่งงานให้ทีมได้ไม่ยาก

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

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

  1. เทคโนโลยีที่ใช้งาน ซึ่งของเดิมนั้นค่อนข้างจะเก่า ไลบราลีที่ใช้งานก็ไม่ได้มีการอัพเดต และมีบางตัวที่เลิกใช้ไปบางแล้ว
  2. ระยะเวลาที่จำกัด ถือเป็นความเสี่ยงหลักของเราเลยที่เกรงว่าจะพัฒนาตัวใหม่ขึ้นมาไม่ทันตามกรอบเวลาที่มี
  3. เอกสารรายละเอียดเกี่ยวกับ Requirements และ Flow ที่หายสาบสูญ นั้นกลายเป็นคำถามแล้วเราจะพัฒนาโปรแกรมให้มีฟีเจอร์ตามเดิมได้อย่างไร? เพราะเอกสาร Requirements ใหม่ก็จะอธิบายฟีเจอร์ที่เคยแต่ละฟีเจอร์ไว้เพียงสั้นๆ

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

• จากปัจจัยต่างๆ ทำไมถึงยังตัดสินใจพัฒนาโปรแกรมขึ้นใหม่ แทนที่จะแก้ไขของเดิม? เวลาก็จำกัด ความเข้าใจใน Requirements และ Flow ก็ไม่มาก

  1. ภาษา และเทคโนโลยีที่ใช้งานไม่เหมือนกัน อันนี้เราก็ต้องเลือกใช้ภาษา และเทคโนโลยีที่เราถนัดไว้ก่อน เพื่อจะช่วยทำให้เราพัฒนาได้เร็วยิ่งขึ้น
  2. ถึงแม้เวลาจะดูจำกัด แต่อันนี้ผมใช้ประสบการณ์ความเร็วของทีมในการพัฒนาโปรเจคอื่นๆ มาตัดสินใจ และคิดว่าน่าจะทันตามเวลา
  3. เอกสารไม่มี ก็ต้องทำฟีเจอร์เก่าด้วยก็ถือว่ายากมาก แต่มีคนที่รู้ 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 เดือนเต็มๆ ซึ่งในทีมของผมจะประกอบไปด้วย

1. ผู้พัฒนาหลัก 3 คน
2. ผู้ทดสอบโปรแกรม 1 คน
3. ผู้ดูแลเกี่ยวกับฐานข้อมูล และรายงาน 1 คน

THIP.HA.OR.TH

ภาพตัวอย่างหน้า Login

ภาพตัวอย่างหน้า Dashboard

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

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

References

• thip