สิ่งที่ควรทำระหว่างการเตรียมโปรเจคใหม่

พอดีว่าที่ทำงานกำลังจะเริ่มโปรเจคใหม่ที่เป็นโปรดักท์ใหม่เลย แต่ผมไม่ได้ทำด้วย มารู้เอาตอนเขาเซ็ตคนเสร็จเรียบร้อยละ อิจฉานิด ๆ (ฮา) โอกาสแบบนี้หายากครับ เพราะว่าส่วนใหญ่มีโปรดักท์ใหม่ตัวนึงก็ใช้กันยาว ๆ เป็นทศวรรษ กว่าจะมีโปรเจคใหม่สักตัว

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

1. Version Control System หรือ VCS

พูดหลายรอบแล้ว แต่อีกสักรอบก็ดี ปัจจุบันนี้เราอยู่ในศตวรรษที่ 21 การขึ้นโปรเจคใหม่โดยไม่มี VCS เลยถือว่าเป็นการย้อนยุคกลับไปสมัยที่ Bill Gates ยังเป็นเด็กประถมที่ขโมยรร.ใช้คอมจนโดนสั่งห้ามนั่นแหละครับ

VCS ที่ใช้อาจจะเป็นรวมศูนย์ หรือแบบกระจายก็ได้ อันนี้ขึ้นอยู่กับองค์กรณ์ เพราะว่าบางที่เองก็ค่อนข้างอนุรักษ์นิยม (จริง ๆ คือคนทำงานขี้เกียจเรียนอะไรใหม่ ๆ มากกว่า) แต่ทั้งนี้ถ้าจำเป็นต้องใช้แบบรวมศูนย์ (Centralized) จริง ๆ ละก็ … หาวิธีพ่วงแบบกระจายเข้าไปอีกดีกว่าครับ เช่นการใช้ git-svn ที่เป็นการใช้ git คู่กับ subversion เป็นต้น

2. Build Script, Deployment Script และ Dependency Manager

ผมจัดสามตัวนี้อยู่ในกลุ่มเดียวกัน กล่าวคือ มันเป็นส่วนที่ทำให้ Build Server ถูกใช้อย่างเกิดประโยชน์สูงสุด นึกดูนะครับสมมติว่าคุณมี Server ที่สามารถ check-out โค๊ดออกมา Build แล้ว Deploy ทั้งตัวโปรแกรมและ Dependency ทั้งหลายขึ้นไปให้คนใช้งานได้ด้วยคำสั่งเดียวมันจะสะดวกแค่ไหน นี่ไม่ใช่ความฝันครับ เป็นเรื่องที่ทำได้จริง และผมทำมาแล้ว (แต่ยังไม่ได้ใช้จริงจัง เดี๋ยวจะเล่าให้ฟังว่าเกิดอะไรขึ้น)

สำหรับคนใช้ Java ผมเคยพูดถึง Gradle ไปแล้ว Gradle นั้นเป็นระบบ Build ที่มีความสามารถในการเป็นทั้ง Dependency Manager และ Deployment Script ได้ด้วยตัวมันเอง (นอกเหนือจากความสามารถในการบิลด์โปรแกรมแล้ว) เทพไหมครับ นี่ล่ะสาเหตุว่าทำไมผมถึงยุบมันเหลือหมวดเดียวกัน 🙂

ส่วนสาเหตุว่าทำไมสามตัวนี้ควรถูกเขียนตั้งแต่เริ่มโปรเจค คืองี้ครับ จากประสพการส่วนตัวที่ทำแอพประเภท 2-tier แยกเป็น frontend กับ backend ที่ใช้เทคโนโลยีต่างกัน ผมจะเจอว่าคนที่ทำแต่ละฝั่งจะไม่ยอมศึกษาอีกฝั่งหนึ่งครับ (ข้ออ้างที่ผมเจอบ่อยสุดคือเขาว่า C++ มันยาก แหม ถ้ามันยากจริงทำไมไม่เพิ่มเงินเดือนผมอีกหน่อยล่ะ 😉 คิดไปเองทั้งนั้นแหละ ขนาดจะสอนให้เขายังไม่เอาเลยครับ) ผมอยู่ฝั่ง frontend ก็จะค่อนข้างลำบากนิดหน่อยเพราะว่าเราเข้าถึง data ตรง ๆ ไม่ได้ ก็เลยต้องศึกษาฝั่ง backend ที่เป็นฐานข้อมูลด้วย (และขอสารภาพตรง ๆ นะ ผมเกลียดฐานข้อมูลยังกับอะไรดี ถึงสมัยเรียนจะได้ A ก็เหอะ) (ส่วนอีกเหตุผลนึงคือเป็นคำสั่งจากเบื้องบนครับ ขัดขืนไม่ได้ 555) ในทางกลับกันคนที่เขียน backend นั้นมักจะทำงานส่วนของตัวเองได้สะดวกกว่า จะต้องพึ่งฝั่ง frontend แค่เฉพาะตอนปิดงานเท่านั้น ดังนั้นเขาก็จะขลุกอยู่กับ query (ที่อ่านไม่ค่อยออก) ของเขานั่นแหละ พอจำเป็นต้องใช้ frontend มาร่วมทดสอบทีก็จะมาเบียดเบียนคนทำ frontend ที งานพวกเราก็เยอะอยู่แล้วยังต้องไปซัพพอร์ตคนอื่นอีก รู้สึกน่าน้อยใจ (ทำไมไม่ขึ้นเงินเดือนให้อีกหน่อยล่ะ ?? :P)

เพื่อที่จะลดภาระของเราตรงนี้ผมก็ใช้เวลาวันหยุดเกือบ ๆ 3 เดือน ศึกษาเรื่องระบบ Build เรื่อง Deployment Script และ Dependency Manager (ก็เลยได้ Blog เพิ่มอีกหลายหน้า) หลังจากที่พับบลิชไป 3-4 เวอร์ชั่น ผมก็เผลอไปได้ยินคนที่ทำ backend คนหนึ่ง (ที่ค่อนข้างมีอิทธิพลพอสมควร) พูดกับปากเลยว่า “จะทำเองทำไม ให้เจ้า W ทำให้ก็ได้” ครับ สุดท้ายที่พยายามมาหลายเดือน ก็กลายเป็นแค่การขว้างงูไม่พ้นคอนั่นแหละ

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

3. Build Server

ข้างบนพูดถึงตัวสคริปท์ ข้างล่างนี้จะเป็นตัวเครื่อง Server เอาไว้บิลด์ คือที่ควรมีเพราะว่าไอ้คนที่ไม่ได้เขียนโค๊ดจะได้ไม่ต้องลงโปรแกรมไว้ในเครื่อง (ซึ่งเป็นอีกข้ออ้างนึงที่เขาไม่ยอมเรียนเรื่องราวของอีกฝั่ง) เขาสามารถที่จะดึงโปรแกรมลงมาใช้ได้เลยทันทีที่อยากใช้ (ก็ไม่ทันทีหรอกครับ แอพหลายตัวบิลด์นาน โปรแกรมผมตอนนี้ล่อไปเกือบชม.แล้ว)

ทั้งนี้ ที่ตัว Repository กลาง (ของ VCS ที่เราเลือกใช้) ควรมีระบบที่สามารถไปสั่งให้ Build Server ทำงานหลังจากมีคน Commit โค๊ดใหม่เข้าไป เป็นการตรวจสอบว่าโปรแกรมนั้นคอมไพล์ผ่านถูกต้องหรือเปล่า ถ้าไม่มีก็ส่งบิลล์ค่าปรับไปที่คน Commit ได้เลยครับ (บ.ผมใช้วิธีนี้จริง ๆ ใครเอาโค๊ดที่คอมไพล์ไม่ผ่านเข้าไปจะถูกปรับ $25) นอกจากนี้หลังจาก Build เสร็จแล้วก็ควรรัน Unit Test และ Automated Test ต่าง ๆ ทั้งหมดอีกรอบด้วย เป็นการสร้างความเชื่อมั่นว่าโปรแกรมจะทำงานถูกต้อง เมื่อผ่านหมดทุกอย่างก็ Deploy ให้ QA เทสต์ต่อได้เลย ไม่ต้องรอรอบ

การมี Build Server ไว้สักตัวจะทำให้โฟลว์งานลื่นไหลขึ้นมากครับ เพราะว่าเป็นการลด Manual Work มหาศาล แต่สุดท้ายก็ขึ้นอยู่กับว่า Build Script/Dependency Script/Deployment Script เขียนมาดีขนาดไหนด้วย ถ้าต้องมีคนเข้ามาเกี่ยวข้องก็ถือว่าความพยายามนั้นไร้ค่าไป

4. Unit Testing

Unit Test ที่ว่านี้เป็นโปรแกรมที่เราเขียนขึ้นเพื่อทดสอบโค๊ดของเราว่าทำงานถูกต้องหรือไม่ (อย่างที่เคยเขียนถึง) การไม่มี Unit Test ในรูปของโปรแกรมเลย (คืออธิบายนิดว่าหลาย ๆ ที่ยังใช้แบบกระดาษอยู่ครับ) เนี่ยทำให้ค่าใช้จ่ายในการทดสอบโปรแกรมในระยะยาวนั้นมหาศาล เพราะโปรแกรมเมอร์จะต้องทดสอบโปรแกรมเอง ซึ่งประสิทธิภาพนั้นทาบแบบ automated ไม่ติดครับ ที่สำคัญคือมันทำซ้ำได้ อย่างถ้าเกิดโปรแกรมเรามีเทสเคสกว่าพันสองร้อยเคส คิดจริง ๆ เหรอครับว่าจะมีคนทดสอบมันหมดทั้งพันสองร้อยเคส ไม่มีทาง ผ่านไปสองเคสผมก็เลิกแล้วล่ะ

การมี Unit Test ตั้งแต่เริ่มโปรเจคนั้นก็เป็นการสร้างวินัยของโปรแกรมเมอร์เองนั่นล่ะครับ ถ้าเกิดว่า Unit Test นั้นไม่ครอบคลุมหรือไม่มีเลยตั้งแต่เริ่มโปรเจคแล้วเนี่ย นานไปก็ไม่มีใครมาดูแลมาทำให้มันสมบูรณ์ได้หรอก (ยิ่งเวลาเริ่ง ๆ จะปิดโปรเจคนะ อย่าให้พูดเลย UT นี่ล่ะจะถูกลืมตั้งแต่แรก)

5. Issue Tracking System

Issue Tracking System น่าจะเป็นเรื่องเดียวในนี้ที่ผมไม่เคยพูดถึงนะครับ โดยหลัก ๆ แล้วก็คือระบบที่จะเก็บว่าซอฟท์แวร์นั้นมีฟีเจอร์ไหนที่ต้องพัฒนา มีบั๊กอะไรบ้าง และใครเป็นคนดูแล เป็นระบบที่คอยแทร็คถึงความก้าวหน้าของโครงการ และปริมาณปัญหาในปัจจุบันนั่นล่ะครับ

ถ้าไม่มี แล้วใช้วิธีจดใส่กระดาษเอาล่ะก็ … เอ่อ ขอให้โชคดีละกันนะครับ ผมมั่นใจว่ามันจะมีปัญหาแน่นอน ไม่ลืมก็หายนี่ล่ะ

6. Content Management System

CMS ก็คือระบบจัดการเนื้อหา (แปลทำไม?) โดยในโปรเจคเราจะมีเอกสารอยู่จำนวนหนึ่ง (ซึ่งยิ่งน้อยยิ่งดี ถ้าเอกสารมีเยอะมากแปลว่าระบบโดยภาพรวมกำลังมีปัญหา เพราะเอกสารคือสิ่งสุดท้ายที่คนจะสนใจครับ) การเก็บเป็นไฟล์สะเปะสะปะจะทำให้เราไม่สามารถค้นหาเนื้อหาที่จะต้องใช้ได้สะดวก คือพูดง่าย ๆ มันเป็นการทำงานน่าเบื่อให้เป็นเรื่องยุ่งยากเข้าไปอีก

CMS ที่ผมเคยเห็นก็แบ่งเป็นสองพวกหลัก ๆ แบบนึงจะเป็นแบบ Web Site เลย เนื้อหาที่สร้างขึ้นก็จะเป็นหน้าเวปหน้าหนึ่ง กับอีกแบบหนึ่งจะคล้าย ๆ VCS แต่เก็บพวกไฟล์เอกสาร (ที่ดัง ๆ ก็ Sharepoint, Alfresco) จริง ๆ แบบหลังเขาเรียกอีกอย่างว่า DMS (Document Management System) แต่ผมว่ามันก็เหมือนกันแหละ

สำหรับทีมที่โปรแกรมเมอร์ค่อนข้างจะเก่งหน่อย ผมว่าการบันทึกในรูปแบบ WIKI หรือใช้ Syntax แบบ Markdown นั้นจะดีกว่าการใช้พวก WYSIWYG Editor ครับ แต่ถ้าในทีมไม่ค่อยมีคนที่ใช้อะไรลักษณะนี้คล่อง ๆ ก็คงต้องทำใจใช้ Word Processor ไปนะ

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *

This site uses Akismet to reduce spam. Learn how your comment data is processed.