ทางบริษัท Thoughtworks จะสรุปเทคโนโลยีที่ใช้งาน และ แนวโน้มต่าง ๆ ในอนาคต
โดยในครั้งนี้จะเน้นใน 4 เรื่อง คือ
- Open Source
- Cloud และ Platform as a Service (PaaS)
- Docker ecosystem
- Over-Reactive ?
จาก 4 เรื่องหลักของ Technology Radar
สิ่งที่ developer น่าจะสนใจคือเรื่องของ Over-Reactive ? ในปัจจุบันเรื่องของ Reactive programming ได้รับความนิยมอย่างมากมาย ดังจะเห็นได้ว่าทุกภาษา program ล้วนมี Reactive extension/library/framework ให้ใช้งาน ทั้งฝั่ง frontend และ backend แต่การใช้ที่มากจนเกินไป หรือ หลากหลายรูปแบบจนเกินไป !! มันก่อให้เกิดความซับซ้อนของระบบ และยากต่อการทำความเข้าใจ ดังนั้น ทีมพัฒนาความใช้งานในรูปแบบเดียวกัน และใช้เท่าที่จำเป็น อีกเรื่องที่น่าสนใจคือ Web Scale Envy ว่าด้วยเรื่องของการขยายระบบ และ เรื่องของ performance พบว่าหลาย ๆ ทีมมักจะมีปัญหาเรื่องนี้เสมอ เนื่องจากเลือกใช้เครื่องมือที่มีความซับซ้อน รวมทั้ง framework และ architecture ของระบบ บ่อยครั้งที่ทีมพัฒนาจะไปอ้างถึง architecture และ เครื่องมือของ Twitter, Facebook และ Netflix ซึ่งมีปริมาณการใช้งานที่สูงมาก ถึง โครตสูง ดังนั้นจำเป็นต้องมีเครื่องมือ และ architecture ที่ซับซ้อนแบบนั้น รวมทั้งความสามารถของแต่ละคนในทีมต้องสูงด้วยเช่นกัน ถึงจะใช้งาน และ จัดการความซับซ้อนเหล่านี้ได้ แต่เมื่อย้อนกลับมาดูทีมพัฒนาของเราสิ ดูปริมาณผู้ใช้งานสิ ดูความสามารถของแต่ละคนในทีมสิ มันต้องการความซับซ้อนเหล่านั้นหรือไม่ ?ดังนั้น จึงแนะนำให้เริ่มต้นด้วยวิธีการที่เรียบง่ายก่อนนะ เพื่อให้ระบบงานที่เราพัฒนาอยู่นั้นมันทำงานได้อย่างถูกต้อง จากนั้นจึงค่อยคิดเรื่องการขยายระบบ และ performance ต่อไป
ตามธรรมเนียมของ Technology Radar จะแบ่งออกเป็น 4 กลุ่มคือ
- Techniques
- Tools
- Platforms
- Languages และ Framework
1. Techniques
เทคนิคใหม่ ๆ ที่เข้ามาอยู่ในกลุ่ม Assess จะเป็นเรื่องของ security ทั้ง Content security policy และ OWASP เนื่องจากทีมพัฒนาส่วนใหญ่ ไม่ค่อยนำเรื่อง security มาพูดคุยตั้งแต่เริ่มต้นการพัฒนา บางทีมอาจจะไม่สนใจเลยด้วยซ้ำ เนื่องจากคนส่วนใหญ่มีความรู้ด้านนี้น้อยมาก ๆ ซึ่งสิ่งเหล่านี้มันคือความเสี่ยงของระบบงานมาก ๆ แต่เรามักมองข้ามไปกันหมด ดังนั้นความเพิ่มเรื่อง security เข้าไปใน functional requirement ด้วยนะ ไม่ว่าจะเป็น- Authentication process
- Access control
- Error handling
- Logging
- เกิดข้อขัดแย้งในเรื่องของ configuration ที่หลากหลาย
- การเข้าคิวเพื่อที่จะ build หรือ ทำงาน
- การทำงานชนกัน
- ถ้าเครื่องนี้ล่มไป พังกันทุกทีมแน่นอน !!
- อื่น ๆ อีกมากมาย
คำแนะนำคือ แยก CI Server ตามทีมที่ทำงาน หรือ ระบบไปเลยนะครับเรื่องต่อมาคือ Big Data Envy !! ในปัจจุบันนั้นคำว่า Big Data มันเข้าไปอยู่ในทุกองค์กรแล้ว ซึ่งเข้าใจกันแล้วว่ามันคืออะไร มีคุณค่าอย่างไร แต่ปัญหาที่เกิดตามมาก็คือ การนำเครื่องมือที่ไม่เหมาะสมมาใช้งาน !! เช่นการนำเครื่องมือที่มีความซับซ้อนมาก ๆ มาจัดการกับข้อมูลที่ไม่ใช่ Big Data บ่อยครั้งพบว่า ข้อมูลที่มีอยู่นั้น สามารถสิเคราะห์ และ ประมวลผล เพียงเครื่องมือง่าย ๆ หรือใช้คอมพิวเตอร์เพียงเครื่องเดียว หรือใช้เพียง RDBMS ปกติก็ทำได้แล้ว หรือไม่เช่นนั้น ก่อนที่จะประมวลผลข้อมูล ช่วยเลือกเฉพาะข้อมูลที่ต้องการ และ จำเป็นมา จากนั้นจึงใช้เครื่องมือง่าย ๆ มาช่วยวิเคราะห์ และ ประมวลผล
ปล. อย่าทำอะไรที่มากเกินความจำเป็นนะครับ และให้เข้าใจด้วยว่ากำลังจะทำอะไร
2. Platforms
เป็นที่แน่นอนว่า Docker เข้ามาเป็น Platform หลักไปแล้ว ซึ่งตอบสนองความต้องการทั้งจาก ทีมพัฒนา, ทีม operation และ ทีม infrastructure และยังได้เกิด Docker ecosystem ขึ้นมาเยอะมาก ๆ ส่วนตัวอื่น ๆ ที่น่าสนใจ เช่น- Realm คือ database สำหรับ mobile application เน้นเรื่อง high performance เป็นหลัก แน่นอนว่ามันเข้ามาเพื่อแทนที่ SQLite และ Core Data
- TensorFlow เป็น open source เรื่อง Machine Learning จาก Google ซึ่งพลาดไม่ได้ด้วยประการทั้งปวง
ปล. อะไรที่มันเยอะ มันยาก มันซับซ้อนเกินไป นั่นแสดงว่า คุณกำลังเดินผิดทางนะ
3. Tools
เป็นกลุ่มเครื่องมือต่าง ๆ ซึ่งมีเครื่องมือใหม่ ๆ เข้ามาเยอะมาก เริ่มต้นด้วย capsul เป็น service discovery tool ถูกย้ายมาในส่วนของ Adopt นั่นคือ แนะนำให้นำไปใช้งานบน production ได้เลย มันแจ่มมาก ๆ (ผมก็ใช้อยู่) ทำให้เราสามารถดูได้ว่า ในระบบของเรานั้นมี service อะไรทำงานอยู่บ้าง แน่นอนว่า สามารถทำงานกับ Docker ได้อย่างสบาย ต่อมาคือ เรื่องของ security อีกแล้วนั่นคือ OWASP Dependency-Check เป็นเครื่องมือสำหรับช่วยตรวจสอบเรื่อง security แน่นอนว่า มันทำให้ชีวิตของ developer ดีขึ้นแน่นอน ถ้าไม่เชื่อก็ลองนำไปใช้กันดูสิ โดยใช้ได้ทั้ง Java, .Net, Ruby, Python และ Node.js ส่วนเรื่องที่ต้องระมัดระวังคือ Jenkins as a Deployment Pipeline ซึ่งจะพูดถึงกรณีที่ กระบวนการ build มันมีความซับซ้อนมาก ต้องการเครื่องมือสร้างมาเพื่อจัดการโดยเฉพาะ ถึงแม้ใน Jenkins จะมี plugin ชื่อว่า Deployment Pipeline ถึงแม้ใน Jenkins 2.0 จะมี plugin ชื่อว่า Pipeline as Code แต่ก็ยังเป็นเพียง plugin ไม่ได้ทำการเปลี่ยน core หรือ การทำงานหลักของ Jenkins เลย เพื่อให้จัดการเรื่อง deployment pipeline โดยเฉพาะปล. ผมยังไม่เคยเจอปัญหาเท่าไร เพราะว่า build pipeline ของผมยังไม่ซับซ้อนนั่นเองโดยในปัจจุบันมีเครื่องมือที่สร้างมาเพื่อ Deployment Pipeline เลย เช่น
4. Language และ Framework
ขอบอกได้เลยว่า มันเยอะมาก ๆ ไม่รู้จะเยอะไปไหน !! กลุ่มที่สามารถนำไปใช้กันได้เลย คือ- ES6
- React.js
- Spring Boot
- Swift
- Butterknife
- Dagger
- React Native
- Rebolectric
- Alamofire
- OkHttp
- Ember.js
- Redux
- AngularJS
- Cylon.js
- Aurelia
สุดท้ายลองถามตัวเราเองสิว่า มีเรื่องอะไรที่ไม่รู้บ้าง ?