Screen Shot 2557-12-09 at 1.23.12 PM
บทความที่น่าสนใจเกี่ยวกับการพัฒนาระบบงานด้วยภาษา Java
เรื่อง Java Doesn’t Suck – You’re Just Using it Wrong
ซึ่งพูดในมุมมองของการนำมาใช้งาน ว่าคุณใช้งานในทางที่ถูกต้องหรือไม่
หรือพยายามใช้งานภายใต้ข้อจำกัดของอะไรกันแน่

จากการพัฒนาระบบงานด้วยภาษา Java ยิ่งในระบบที่เรียกว่า Enterprise Application แล้ว
developer มักจะประสบภัย หรือ ประสบการณ์ที่ไม่ค่อยดี
เนื่องจากขั้นตอน และ วิธีการทำงานที่ไร้ซึ่งประสิทธิภาพ

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

ปล. ยังต้องยอมรับว่า ระบบใหญ่ในตลาดยังคงพัฒนาด้วยภาษา Java

ในบทความนี้ได้อธิบายถึงการพัฒนาระบบงานด้วยภาษา Java ในแนวทางที่แย่ๆ
ซึ่งมันก่อให้เกิดผลลัพธ์ที่แย่ๆ ตามออกมา

ดังนั้น มาดูวิธีการแย่ๆ ในการพัฒนาระบบงานด้วยภาษา Java กัน ว่ามีอะไรบ้าง ?

1. ขั้นตอนการติดตั้งที่ยุ่งยาก เยอะเยอะ วุ่นวาย

ลองกลับไปดูว่าถ้าคุณจะติดตั้ง development environment ขึ้นมาต้องทำอะไรมากมายหรือไม่
เนื่องจากที่เคยสัมผัสมา มักจะมีขั้นตอนการติดตั้ง configuration ที่วุ่นวายมากๆ
กว่าจะได้เริ่มต้นพัฒนากัน

ดังนั้นขั้นตอนในการติดตั้งสำหรับการพัฒนาไม่ควรเกิน 3 ขั้นตอนนี้

  1. ทำการ Download และติดตั้ง JDK (Java Development Kit)
  2. ทำการ checkout/clone code มาจาก repository ของ SCM (Source Control Management)
  3. ทำการ 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 มันไม่ดีมันแย่เพียงเท่านั้นเองหรือ ?

ใช้เครื่องมือ ให้เหมาะกับงาน
และต้องเลือกคน ให้เหมาะกับงานด้วย เช่นกัน

Tags: