บทความที่น่าสนใจเกี่ยวกับการพัฒนาระบบงานด้วยภาษา Java
เรื่อง Java Doesn’t Suck – You’re Just Using it Wrong
ซึ่งพูดในมุมมองของการนำมาใช้งาน ว่าคุณใช้งานในทางที่ถูกต้องหรือไม่
หรือพยายามใช้งานภายใต้ข้อจำกัดของอะไรกันแน่
จากการพัฒนาระบบงานด้วยภาษา Java ยิ่งในระบบที่เรียกว่า Enterprise Application แล้ว
developer มักจะประสบภัย หรือ ประสบการณ์ที่ไม่ค่อยดี
เนื่องจากขั้นตอน และ วิธีการทำงานที่ไร้ซึ่งประสิทธิภาพ
แต่เชื่อไหมว่า ทุกๆ คนมักจะบอกไปว่า Java มันห่วย !!
โดยที่ไม่ได้ย้อนกลับมาดูในสิ่งที่ตนเองทำลงไป ว่าเป็นอย่างไร ถูกต้องหรือไม่ ?
ปล. ยังต้องยอมรับว่า ระบบใหญ่ในตลาดยังคงพัฒนาด้วยภาษา Java
ในบทความนี้ได้อธิบายถึงการพัฒนาระบบงานด้วยภาษา Java ในแนวทางที่แย่ๆ
ซึ่งมันก่อให้เกิดผลลัพธ์ที่แย่ๆ ตามออกมา
ดังนั้น มาดูวิธีการแย่ๆ ในการพัฒนาระบบงานด้วยภาษา Java กัน ว่ามีอะไรบ้าง ?
1. ขั้นตอนการติดตั้งที่ยุ่งยาก เยอะเยอะ วุ่นวาย
ลองกลับไปดูว่าถ้าคุณจะติดตั้ง development environment ขึ้นมาต้องทำอะไรมากมายหรือไม่
เนื่องจากที่เคยสัมผัสมา มักจะมีขั้นตอนการติดตั้ง configuration ที่วุ่นวายมากๆ
กว่าจะได้เริ่มต้นพัฒนากัน
ดังนั้นขั้นตอนในการติดตั้งสำหรับการพัฒนาไม่ควรเกิน 3 ขั้นตอนนี้
- ทำการ Download และติดตั้ง JDK (Java Development Kit)
- ทำการ checkout/clone code มาจาก repository ของ SCM (Source Control Management)
- ทำการ build, test, package, deploy และ run ระบบงานได้ทันที
เรื่องนี้มันสำคัญมากๆ นะครับ ไม่เช่นนั้นคุณจะวุ่นวายมากๆ
ปัจจุบันนักพัฒนา Java ชอบติดกับดักของ IDE ซึ่งเป็นเรื่องที่ไร้สาระมากๆ
ระบบงานทุกๆ ระบบงาน ควรที่จะมีการใช้ build tool และ dependency management ซะ
เพื่อช่วยทำให้งานต่างๆ มันง่ายขึ้น เช่น
- Apache Maven
- Gradle
ยิ่งในปัจจุบันการสร้าง environment ต่างๆ มันง่ายขึ้นมากเช่น Docker เป็นต้น
ปัจจุบันคุณทำกันอย่างไร ?
2. Environment ในการ deploy ที่แตกต่างกันมากเหลือเกิน
ปัญหาที่มักเจอ และ กลายเป็นความเสี่ยงอย่างมากก็คือ การ deploy ระบบงานในแต่ละ environment
รวมทั้งเรื่องการ configuration ต่างๆ ของแต่ละ environment
การแก้ไขที่ควรจะต้องทำ คือ
ควรมีสิ่งที่จะ deploy ในแต่ละ environment เพียงตัวเดียว [ห้ามเปลี่ยนหรือ build ใหม่นะ]
เมื่อทำการ deploy ไปแต่ละ environment แล้วระบบงานจะต้องสามารถรู้ได้เองว่า
ตอนนี้ deploy ที่ environment ไหนได้อย่างอัตโนมัติ นั่นคือ การใช้ตัวแปรของระบบมาช่วย
มันจะทำให้เราสามารถ deploy ระบบงานได้ง่ายขึ้น
ยิ่งในปัจจุบันถ้าเรานำระบบ Continuous Integration เข้ามาใช้งานด้วยแล้ว
ก็จะทำให้เรารู็อยู่ตลอดเวลาว่า สิ่งที่เราสร้างขึ้นมา
มันสามารถทำงานได้ในแต่ละ environment หรือไม่
มันช่วยลดความเสี่ยงลงไปอย่างมาก
ปัจจุบันคุณทำกันแบบไหนหรอ ?
3. ในการ restart web/application server ใช้เวลามากกว่า 30 วินาที
คุณจะทำงานได้ดี หรือ มี productivity ที่ดีได้อย่างไร
ถ้า server ที่คุณใช้ในการพัฒนามันเริ่มทำงานได้ช้า … บางคนต้องจิบชา กาแฟ รอกันเลยทีเดียว !!
ดังนั้น ถ้าคุณรอเกิน 30 วินาที แสดงว่าช้าแล้วนะ ผมว่า 5 วินาทีก็ช้าแล้วนะ
ดังนั้น วิธีการที่คุณสามารถทำให้ คุณทำงานได้รวดเร้วขึ้น
นั่นคือการแบ่งระบบของคุณออกเป็นส่วนเล็กๆ ไงล่ะ
เพราะว่า สิ่งที่คุณทำอยู่มันรวมทุกอย่างไว้ที่เดียวกัน
จะทำอะไรสักครั้งหนึ่ง ต้อง load โน่นนี่นั่น เยอะไปหมด
ส่งผลให้ช้าไงล่ะ !!!
ปัจจุบัน ระบบงานที่คุณพัฒนามันช้าไหมนะ !! หรือช้าจนชินไปเสียแล้ว ?
4. ทำการจัดการ dependency library แบบ manual
คุณจัดการ library ต่างๆ ในระบบงานของคุณ อย่างไร ?
ทำการ copy file มาจาก project อื่นๆ ใช่ไหม ?
ทำการ download มาจาก internet แล้ว copy มาใส่ project ใช่ไหม ?
คุณรู้ไหมว่า library ที่ใช้อยู่มันคือ version ไหน ?
แล้ว library แต่ละตัวมันสัมพันธ์กันอย่างไร ?
ระบบมักจะเจอ error ClassNotFoundException บ่อยๆ ใช่ไหม ?
ถ้าคุณเจอปัญหาจากคำถามเหล่านี้ แสดงคุณกำลังมาผิดทาง
เนื่องจาก คุณจำเป็นต้องมีตัวจัดการ libraary หรือ dependency ต่างๆ แล้วนะ
ตัวอย่างเช่น Apache Maven หรือ Gradle จะทำการ
ดึง library ที่เกี่ยวข้องจาก Maven Central repository หรือ Local repository เช่น Artifactory/Nexus server
ซึ่งมันทำให้คุณไม่ต้องมานั่งจัดการ library ต่างๆ เหล่านี้เอง
ปัจจุบันคุณจัดการกันอย่างไร ?
5. เวลาในการพัฒนา ทดสอบ ยาวนานเหลือเกิน
มันส่งผลมาจากข้อต่างๆ ที่ผ่านมา ยิ่งเวลาการ start server ช้า
ก็ยิ่งทำให้เวลาในการพัฒนาช้าลงไป
ก็ยิ่งส่งผลให้การทดสอบว่าถูกหรือไม่ช้าลงไปอีก
ขั้นตอนที่คุณมักทำกันก็คือ
- แก้ไข code
- build/package => EAR, EAR
- Start server
- deploy
- ทดสอบ
มันช้าไปไหม ?
ดังนั้นควรต้องเปลี่ยนวิธีการพัฒนาแล้วนะ
เช่น การเขียน Test-First เพื่อทดสอบในส่วนต่างๆ ที่จะพัฒนา
ทำให้การทำงานแต่ละส่วนแยกกัน
เมื่อทำแต่ละส่วนเรียบร้อย จึงทำการทดสอบผ่าน web browser
ซึ่งถ้าไม่อยากให้ทำการ restart application server ก็ลองใช้พวก JRebel สิ แล้วคุณจะเร็วขึ้น
หรือ ลองเปลี่ยนไปใช้ Servlet container ที่เร็วกว่าเดิมสิ
ปัจจุบันคุณคุ้นชินกับความช้าแล้วหรือยัง ?
6. การ release แบบ Big Bang
เหตุผลว่าทำไมเวลารอบของการ release มันยาวนานนะ ?
เพราะว่าต้องการลดความเสี่ยงไงล่ะ
ถึงคุณจะพยายามเปลี่ยนวิธีการพัฒนาไปอย่างไรก็ตาม
แต่รอบการ release ยังคงเป็นเช่นเดิม
ผลที่ได้ก็ยังเหมือนเดิม นั่นคือ
เมื่อทำการ deploy บน production server ก็จะเกิดปัญหาใหญ่ๆ ขึ้นมาเสมอ
ทั้งเรื่องที่พอคาดเดาได้ และ ไม่ได้
ทำให้เราต้องทำการ deploy ระบบงานในช่วงดึกๆ ในช่วงวันหยุด …
คุณชอบวิธีการแบบนี้ คุณรักการทำงานแบบนี้ ใช่ไหม ?
ทำไมคุณถึงไม่แบ่งการ release ออกเป็นช่วงเล็กๆ สั้นๆ ล่ะ ?
หรือช่วงการ deploy เล็กๆ บน production server ไปเรื่อยๆ
เพื่อให้เห็นว่าสิ่งที่สร้างขึ้นมามันทำงานได้จริงหรือไม่
ในปัจจุบันมักจะพูดถึง Continuous Delivery(CD) กันมากขึ้น
อย่าลืมว่า Deploy ไม่เท่ากับการ Release นะครับ
แต่หลายๆ คนมักจะบอกว่า Deploy เท่ากับการ Release
ปัจจุบันคุณทำแบบไหนอยู่หรอ ?
7. เก็บ session หรือสถานะต่างๆ ไว้ที่ server … บ้าไปแล้ว
คุณทำการเก็บข้อมูลต่างๆ หรือ session ไว้ที่ server หลักหรือเปล่านะ ?
ถ้าไม่รู้แสดงว่า ใช่คุณเก็บไว้ที่ server …
ซึ่งมันเส้นทางที่ดีมากๆ สำหรับการฆ่า server
รวมทั้งมันจะทำให้คุณขยายระบบได้ยากมากๆ หรือ คิดไม่ออกก็ขยาย server มันเลย ขอเครื่องใหญ่ๆ
ดังนั้น ถ้าต้องการเก็บข้อมูลไว้ใน session จริงๆ
ให้ทำการแยก server สำหรับการเก็บ session ออกมาจาก application server ซะ เช่น
- Memcached
- ehcache
แต่ทางที่ดี Stateless คือ หัวใจครับ ..
ระบบที่คุณพัฒนาเป็น Stateless หรือ Stateful ครับ ?
ลองกลับไปดูได้ว่า
ทุกๆ ทีมที่พัฒนาระบบงานด้วยภาษา Java ทั้งทีมเล็กๆ ไปจนถึงระดับ Enterprise
ทำเรื่องต่างๆ ข้างบนมาน่าจะเกือบครับ และก็อยู่กับมันจนชินไปแล้ว
บางคนเข้าไปเจออาจจะตกใจ แต่เชื่อเถอะว่าเป็นเรื่องที่ปกติ ….. ที่ไม่ปกติ
ซึ่งเป็นเรื่องที่น่ากลัวมากๆ เพราะว่า ผลที่มันแย่ๆ มันจะมาลงที่ Java นะสิ
แปลกดีไหม ?
ทั้งๆ ที่คนในทีมเรานำมาใช้เองนะ ?
แต่ไม่ได้ดูว่า เรามีปัญหาอะไร และจะปรับปรุงอะไร อย่างไร ?
ทำได้เพียงแค่บอกว่า Java มันไม่ดีมันแย่เพียงเท่านั้นเองหรือ ?
ใช้เครื่องมือ ให้เหมาะกับงาน
และต้องเลือกคน ให้เหมาะกับงานด้วย เช่นกัน