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

โดยที่เราสามารถสรุปขั้นตอนการพัฒนาและเขียน test

ได้ดังนี้

• เขียน code ที่ error หรือ compile หรือ parse ไม่ผ่าน เพราะว่า library ต่าง ๆ อาจจะยังไม่ครบ ดังนั้นทำให้ผ่าน แล้วไปขั้นตอนต่อไป
• เขียน test แล้วดูว่า error ไหม ซึ่งจะเน้นไปที่การ setup ของ test หรือ initial stage เพื่อทดสอบต่อไป
• ดู failure ของ test ว่าเป็นอย่างไร เพื่อทำความเข้าใจ ว่าทำงานตามที่เราคาดหวังไหม ถ้าไม่เป็นไปตามที่คาดหวังอาจจะเกิดจากขั้นตอนก่อนหน้าก็ได้ ดังนั้นต้องมีความรอบคอบ
• เขียน code เพื่อให้ test ผ่าน ทีละ test ไม่ต้องรีบร้อน
• จากนั้นก็ทำการตรวจสอบว่า code ที่เขียน กับ test ที่สร้างมันครอบคลุม หรือ ทำให้เรามีความเชื่อมั่นไหม ถ้ายังก็แสดงว่ายังไม่สิ่งที่ทำอยู่
• สิ่งที่เราสร้างมีตรงไหนบ้างที่ไม่ดี หรือ อยากปรับปรุง จงทำซะ
• เมื่อทุกอย่าง ok แล้ว มั่นใจแล้ว ก็พัฒนาส่วนอื่น ๆ ต่อไป
• วนอย่างนี้ไปเรื่อย ๆ ทำทีละขั้นตอนไปเรื่อย ๆ

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

Field ต่าง ๆ ใน Struct ของภาษา Go นั้น
มักจะมีปัญหาเรื่องของลำดับ ซึ่งมีผลต่อการใช้งาน memory
ซึ่งเคยเขียนอธิบายไว้ที่ blog เรื่อง
การจัดเรียง property ใน Struct เพื่อลดจำนวน memory ที่ใช้งาน
แต่ก็เป็นเรื่องที่ไม่สะดวกเท่าไรต่อการพัฒนา
ที่จะต้องมาจัดการอะไรแบบนี้
ดังนั้นมาดูกันว่า มีเครื่องมืออะไรช่วยเหลือบ้าง ?

พบว่ามี project ใน Go Vet ทำไว้คือ FieldAlignment นั่นเอง
เพียงแค่ติดตั้งและใช้งาน ก็จะทำการตรวจสอบ struct
และทำการจัดเรียงลำดับของ field ใน struct ให้แบบอัตโนมัติเลย
น่าจะช่วยอำนวยความสะดวกมากยิ่งขึ้น

ตัวอย่างการใช้งาน

ลองใช้งานจาก code ใน blog ก่อนนี้
ได้ดังนี้

มีเครื่องมือให้ใช้ ก็สบายขึ้นเยอะ

เห็นทาง Google ทำการแนะนำภาษา Carbon
ซึ่งเป็นอีกภาษาที่มีเป้าหมายเพื่อมาแทนที่ C++
หรือเป็นอีกทางเลือกหนึ่งของ C++
หรือปรับปรุงมาจากปัญหาของ C++
อีกทั้งยังทำงานร่วมกับ C++ ได้
แต่ยังอยู่ในช่วงของการทดลองเท่านั้น

ยกตัวอย่างง่าย ๆ คือ

• JavaScript -> TypeScript
• Objective-C -> Swift
• Java -> Kotlin
• C -> C++
• C++ -> Carbon

โดยเป้าหมายของ Carbon หลัก ๆ ยังเหมือน C++ รวมทั้งปรับปรุง ดังนี้

• High performance
• ทำงานบน platform ต่าง ๆ ได้
• สนับสนุน hardware และ OS ต่าง ๆ ได้
• รูปแบบของภาษาที่เข้าใจง่ายขึ้น
• ง่ายต่อการ scale
• สามารถทำงานร่วมกับ C++ ได้ (Bi-directional interoperability)
• สามารถ migrate จาก C++ ได้
• Open source เต็มตัว

มาทำการติดตั้งกันหน่อย

ทำการติดตั้งบน Mac OS ประกอบไปด้วย

• Homebrew
• Bazel เป็นเครื่องมือสำหรับการ build และ test ซึ่งสนับสนุนหลายภาษาโปรแกรมและ platform
• LLVM (Low Level Virtual Machine) ใช้สำหรับการ compile และ link Carbon แต่ละส่วนเพื่อทำงานด้วยกันขณะการ build
• Carbon explorer เป็นเครื่องมือในการ run ของ Carbon นั่นเอง

การติดตั้งก็ตามเอกสาร ซึ่งแนะนำให้ติดตั้งหรือ update Homebrew ก่อน !!
จากนั้นทำตามเอกสารได้เลย Installation

ขั้นตอนที่ช้าช้าสำหรับครั้งแรงคือ การ run ตัว Carbon explorer นั่นเอง

Syntax ของภาษา Carbon ที่น่าสนใจ

• ชื่อ method/function จะใช้ keyword ชื่อว่า fn
• ในการประกาศ return type ของ method/function จะใช้ผ่าน ->
• ตัวแปรประกาศด้วย keyword ชื่อว่า var
• ค่าคงที่ประกาศด้วย keyword ชื่อว่า let
• ระบุ data type ของตัวแปรอยู่หลัง : ยกตัวอย่างเช่น var name: auto เป็นต้น
• ในแต่ละ file ต้องประกาศ package เสมอ
• ส่วนการ comment ใช้ // my comment

ไว้ต้องลองใช้งานภาษา Carbon เล่นดูหน่อยแล้ว
น่าจะสนุกดี

หลายวันที่ผ่านมา มีโอกาสเข้าไปดูและแก้ไขปัญหา
ของ API ในระบบหนึ่ง ซึ่งมีปัญหาต่าง ๆ มากมาย
หนึ่งในนั้นคือ ผลการทำงานที่แย่ หรือ performance ไม่ดี
ทั้งช้า ใช้งาน CPU และ Memory เยอะ

การแก้ไขปัญหาเฉพาะหน้าคืออะไร ?

• Restart
• ขยายเครื่อง หรือ เพิ่มเครื่อง ให้ใหญ่หรือมากขึ้น

แต่ถ้าสำหรับ long term solution มาดูปัญหาที่เป็นอยู่กันหน่อย

เพื่อจะได้แก้ไขที่ต้นเหตุกัน ประกอบไปด้วย

• การดึงข้อมูลจาก Database ช้ามาก ๆ มาจาก data ที่เยอะ ควมสัมพันธ์ของ data ที่สูง แถม index ก็ไม่ทำ หนักกว่าคือ index ที่ทำไม่มีประสิทธิภาพ
• Business logic มีความซับซ้อนสูงมาก ๆ ทำงานแบบ sequential และ transaction นาน ๆ หนักสุด ๆ คือ เกิด locked database/table ขึ้นมาอีก
• Code ไม่ดี หรือ logic/algorithm ไม่ดี ทำงานเยอะไป ใช้งาน CPU/Memory เยอะไป หรือมี code ที่ไม่จำเป็นเยอะ
• พวก Resource ต่าง ๆ ไปเพียงพอ ถ้าแก้ไขปัญหาข้างต้นหมดแล้ว ยังไม่พอ แสดงว่าต้องเพิ่ม หรือ ขยายแล้วนะ

การแก้ไขปัญหาต่าง ๆ แบบง่าย ๆ หรือเปล่านะ แต่น่าจะเป็นแนวทางที่ดีขึ้น

ยกตัวอย่างเช่น

ปัญหา business logic ที่ทำงานแบบ sequential และ ซับซ้อน

พบเจอเยอะมาก ๆ สำหรับปัญหานี้
เพราะว่า การทำงานแบบ sequential มันทำได้ง่าย เข้าใจง่าย
แต่บ่อยครั้งพบว่า ขั้นตอนการทำงานต่าง ๆ อาจจะทำงานพร้อม ๆ กันได้
ไม่จำเป็นต้องรอกัน
ดังนั้นเรื่องของ parallel process จึงเข้ามามีบทบาท
หรือบางงานอาจจะแยกไปทำงานใน process อื่น ๆ ได้
หรืออาจจะทำงานแบบ asynchronous ได้
หรือแยกไปอีกระบบตามแนวคิด event-based architecture ก็ได้

ปัญหาต่อมาคือ ความซับซ้อน อาจจะทำให้ transaction นานเกินไป

ทำให้ database/table เกิด lock ได้
หรือ database ทำงานหนักมาก ๆ
ดังนั้น ควรแยกการทำงานย่อย ๆ หรือเป็นกลุ่มออกมา
เพื่อลดปัญหาการ lock หรือ long transaction ลงไป
แต่ความถูกต้องยังต้องถูกต้องเช่นเดิม ทั้ง success และ fail
หัวใจคือ ในแต่ละ transaction ต้องจบงานเร็วที่สุด
หรือพยายามใช้ caching data เพื่อลดการ access database ลงไป ก็ช่วยได้

ปัญหา API ทำการ return ข้อมูลเยอะเกินไป

ปัญหานี้เกิดจากการ reuse
หรือเหลือดีกว่าขาด
ดังนั้น return ไปเยอะ ๆ เลย
จะใช้อะไรก็เลือกใช้เอง
แบบนี้ดีไหมนะ

ลองตรวจสอบและแก้ไขปัญหากันดูครับ

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

• ลด หรือ ประหยัดเวลาในการทำงาน
• ลดจำนวนคนทำงานลงไป
• ลดปัญหาต่าง ๆ ที่เกิดซ้ำ ๆ

แต่เมื่อองค์กรนำมาใช้ กลับเกิดปัญหาต่าง ๆ ดังนี้

• ปัญหาในการใช้เครื่องมือ automation ให้เข้ากับระบบปัจจุบัน ที่ซับซ้อนสุด ๆ ... ทำไมไม่ปรับระบบเดิมก่อนนะ
• ปัญหาจากการ configuration เครื่องมือไม่ถูกต้อง ทำให้ทำงานถูกบ้าง ไม่ถูกบ้าง ตรวจสอบเจอบ้าง ไม่เจอบ้าง แล้วก็บอกว่าเครื่องมือไม่ดี ทั้ง ๆ ที่ยังไม่รู็หรือเข้าใจมันอย่างดี
• ปัญหาเรื่องของ dependency ของระบบที่เยอะมาก ๆ หนักกว่านั้น มีหลายทีมต้องดูแลแต่ละขั้นตอนในระบบ Automation ส่งผลให้เกิดปัญหาเรื่อง ใครเป้นเจ้าของ ใครดูแลรับผิดชอบ หนั่งกว่านั้นขาดความรู้ความเข้าใจ บ่อยครั้งคนในองค์กรก็ไม่อยากเรียนรู้ ดังนั้น ก็จ้าง หรือ เปิดรับตำแหน่งใหม่มาดูแลเลย
• ปัญหาจากขั้นตอนการทำงานมีทั้ง Automation และ Manual ร่วมกันอยู่ ทำให้เป็น Automation แบบครึ่ง ๆ กลาง ๆ ผลที่ได้ก็ไม่ดีตามที่คาดหวัง
• ปัญหาของการนำ Automation ไปปรับปรุงกระบวนการทำงานที่แย่ ๆ แล้วคิดว่า จะทำให้ดีขึ้น แต่ผลจริง ๆ คือ ถ้ากระบวนการเดิมมันยังแย่แล้ว เอา Automation มาใช้งานก็ไม่ได้ทำให้ดีขึ้นมากหรอกนะ ควรปรับปรุงก่อนนะ

มันดูแปลก ๆ ไหมนะ ?

ดังนั้นสิ่งที่สำคัญคือการตั้งคำถามก่อนเริ่ม เพื่อให้ได้คำตอบที่ชัดเจน

ประกอบไปด้วย

• จะ Automate อะไร เพื่ออะไร ทำไปทำไม ปัจจุบันเป็นอย่างไร
• ในสิ่งที่จะทำ Automate มีใครที่เกี่ยวข้องบ้าง
• ใครเป็นเจ้าของระบบ
• skill ต่อเครื่องมือที่จะใช้ เป็นอย่างไร

ลองดูว่า การนำ Automation เป็นอย่างไรบ้าง ?

ใน GitLab 15 ที่ออกมาตั้งแต่เดือนพฤษภาคมที่ผ่านมา
และยังมีการ update มาเรื่อย ๆ มาจนถึงปัจจุบันใน version 15.2
โดยมีความสามารถที่น่าสนใจ น่าใช้ดังนี้

สามารถเขียน Diagram ในรูปแบบของ Markdown ได้แล้ว

สนับสนุน diagram ต่าง ๆ เช่น Mermaid, PlantUML และ Kroki

เพิ่ม Value Stream Analytic เพื่อแสดงข้อมูล 4 ตัวของ DORA metric

ยกตัวอย่างเช่น การ restore service และ ผลกระทบจากการเปลี่ยนแปลงต่าง ๆ
ซึ่งช่วยให้ทีมเห็น performance โดยตรง และเข้าใจง่ายขึ้น

มี Internal Note เพื่อให้ทีมสามารถพูดคุยกันภายใน

โดยไม่จำเป็นต้องเปิดเป็น public
ช่วยให้จัดการเรื่องความลับ หรือ ข้อมูลส่วนตัวมากยิ่งขึ้น

สามารถใช้งาน Container Scan ในทุก ๆ tier ของ user แล้ว

ทั้ง container และ dependency ต่าง ๆ
สามารถ integrate กับ Trivy และ Grype ได้

ลองใช้งานกันดูครับ

เพิ่งเห็นว่าทาง Android Developer นั้น
ได้ปล่อยเอกสารเรื่อง Guide to Android app modularization ออกมา
เป็นการพัฒนาโดยแบ่งเป็น module ย่อย ๆ
เพื่อช่วยจัดการความซับซ้อนของระบบงาน
โดยเนื้อหาประกอบไปด้วย

• Modularization คืออะไร
• ปัญหา และ ประโยชน์ที่ได้รับมีอะไรบ้าง
• สิ่งที่ควร และ ไม่ควรทำ
• วิธีการนี้เหมาะสมกับระบบที่เราทำกันอยู่หรือไม่ เพราะว่าไม่ได้เหมาะกับทุก app นะ
• ตัวอย่างระบบงาน (Modern Android Architecture) ซึ่งว่าด้วยเรื่องของ low coupling และ high cohesion ซึ่งตรงนี้สำคัญมาก ๆ เพื่อลดปัญหาของ cyclic modular และ ความซับซ้อนที่มากเกินไป
• ชนิดต่าง ๆ ของ module และหน้าที่รับผิดชอบ เช่น data, feature, app/main, common module
• การส่งข้อมูลระหว่าง module ซึ่งไม่แนะนำให้เป็นแบบ two-way communication

เป็นเนื้อหาที่น่าสนใจสำหรับการพัฒนาระบบงานมาก ๆ
ลองศึกษากันดูนะ

IntelliJ IDEA 2022.2 นั้นปล่อยออกมาให้ใช้งานกันแล้ว
ซึ่ง Runtime จะใช้ Java 17 แล้ว
โดยที่ทำการ fork มาจาก OpenJDK 17
ช่วยให้ปรับปรุง performance ของ IDE ให้ดีขึ้นเยอะ
ทั้งการ render และ suggestion ต่าง ๆ

เป็นการเปลี่ยนแปลงเพื่อรองรับ Spring 6 และ Spring Boot 3
ที่จะปล่อยออกมาในเดือนพฤศจิกายนที่จะถึงนี้

ยังมีplugin เพิ่มเติมในการ debug GraalVM อีกด้วย
รวมทั้งปรับปรุงเรื่อง connection ของ Remote development ขึ้นมา
เพราะว่าของเดิมไม่ค่อย stable เท่าไรนัก

Download มาใช้งานกันได้แล้ว

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

ก่อนแก้ไขหรือปรับปรุง ก็มาดูก่อนว่าขั้นตอนการทำงานเป็นอย่างไร

ขั้นตอนการทำงานประกอบไปด้วย

• Download dependency ต่าง ๆ
• Compile code
• ทำการตรวจสอบ code ด้วย Static code analyzer + Lint + Type checker + Formatter code
• Run unit test
• Run End-to-end test
• Deploy ใน environment ต่าง ๆ

มาดูปัญหาที่เกิดขึ้นบ้างว่ามีอะไร และแก้ไขอย่างไร

• อย่างแรกคนจริง ไม่ใช้ cached อะไรเลย ทั้ง dependency และผลจากการ compile ก่อนหน้า คนจริงต้อง compile แบบ clean ๆ ทั้ง ๆ ที่บ่อยครั้งจะเปลี่ยนแปลงเพียงเล็กน้อยเท่านั้น ผลที่ได้คือ เปลี่ยนนิดเดียวแต่รอนานมาก และนานขึ้นเรื่อย ๆ ตาม code และ dependecy ที่เยอะขึ้น ดังนั้น ความต้องการคือ แก้ไขนิดเดียวก็น่าจะใช้เวลาทำงานไม่นานสิ จึงนำเรื่องของ cached ผลการทำงานก่อนหน้ามาใช้ด้วย ในส่วนนี้ลดเวลาจากหลักนาที เหลือไม่ถึง 5 วินาที
• ต่อมาเรื่องของการ download dependency ที่เยอะ รวมทั้งต้องออก internet อีก ดังนั้นตรงนี้ง่าย ๆ คือ ทำ cached dependecy server ไว้ใช้ภายในซะเลย
• ขั้นตอนการทำงานใน CI/CD จะเป็นแบบ sequencial ทั้งหมด ดังนั้นจึงมานั่งคุยกันใหม่ว่า จะจัดการอย่างไร ขั้นตอนไหน สามารถทำงานแบบพร้อม ๆ กันได้ หรือ แยกกันได้ หรือ งานไหนไม่เกี่ยวข้องกันก็ไม่ต้องรอผล ในส่วนนี้คือการปรับปรุงขั้นตอนการทำงานให้ตรงกับความต้องการปัจจุบันและประโยชน์ให้มากที่สุด แน่นอนว่าใช้เวลาในการคุยนาน แต่เป็นสิ่งที่ควรทำมาก ๆ และบ่อย ๆ
• ขั้นตอนอะไรที่ไม่จำเป็นก็ลบทิ้งไป
• ในส่วนของ End-to-End test จะช้าขึ้นเรื่อย ๆ ดังนั้นจึงเริ่มแยกออกมาอีก server และทำการทดสอบทั้งแบบ parallel และ distributed เพื่อให้รู้ผลได้รวดเร็วและเสถียรที่สุด เนื่องจากการทดสอบในส่วนนี้มักจะเจอ test case ที่ไม่เสถียรเยอะมาก ๆ ซึ่งมันส่งผลต่อความน่าเชื่อถือของ CI/CD อย่างมาก
• ทุกคนจะรอดูผลที่ CI/CD server เป็นหลัก ซึ่งไม่ถูกต้องเลย เพราะว่า มันทั้งช้า และ รอนาน เปลืองเวลาอีก ดังนั้นจึงต้องทำให้ทุกคนสามารถ run บางอย่างบนเครื่องตัวเองให้ได้และผ่านก่อน ก่อนที่จะทำการ commit->push และ PR มายัง source repository ช่วยให้ไม่ต้องมารอดูอะไรมากนัก ในส่วนนี้จะใช้งานพวก Docker มาช่วย

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

และสิ่งที่สำคัญมาก ๆ คือ CI/CD ต้องทำงานได้อย่างรวดเร็วและมีคุณภาพที่สูง

ไม่ได้ upgrade Git นาน พบว่าตอนนี้ออก version 2.37.2 มาแล้ว
เลยไปดูหน่อยว่ามันอะไรที่น่าสนใจบ้าง

เริ่มที่เรื่องของการปรับปรุง performance ของ Git
feature ที่พัฒนาด้วยภาษา perl
ก็จะเปลี่ยนมาเป็นภาษา C รวมทั้งของใหม่ ๆ
เพราะว่าตอนนี้มีทั้งสองภาษาเลย
ยกตัวอย่างเช่น git add -i เป็นต้น

เรื่องต่อมาคือ มี monitoring file มาให้เลย
มันคือ watchman นั่นเอง
แต่ถูกยัดมาใน Git เลย ไม่ต้องทำอะไรมาก
แต่ถ้าต้องการใช้งานก็ต้อง config เพื่อเปิดใช้งาน ดังนี้

ยังมีอีกหลายเรื่องทั้ง

• ปรับปรุงการ diff
• การทำงานของ Git remote
• ทำการ reimplement ตัว vimdiff ใหม่
• การ prune object ที่เข้าไม่ถึงหรือหาไม่เจอ

สุดท้าย น่าสนใจสุด ๆ คือ
$git -v
$git -h
ได้แล้ว จะดีใจไหม !!

อย่าลืม upgrade กันนะครับ

สามารถอ่าน Release notes เพิ่มเติมได้

กำลัง review เรื่อง Data architecture ของระบบงาน
พบว่าโครงสร้าง data , process การใช้งานและจัดการ data
มีรูปแบบดังรูป

จากรูปจะเห็นได้ว่า

• Dev team ทำหน้าที่ดูแลระบบงาน และทำการจัดเก็บข้อมูลใน database ของระบบไป
• Centralize data team อยากได้ข้อมูลมาจัดเก็บใน Data warehouse/data lake หรือ transform data มาจัดเก็บ เพื่อใช้พวก BI tool มาดึงไปเพื่อแสดงใน dashboard ต่าง ๆ ตรงนี้ข้อมูลที่ได้จาก database ฝั่ง Dev team อาจจะอยู่ในรูปแบบของ file หรือ share file หรือ ต่อตรงไหม หรือ messaging ก็ว่ากันไป แต่ทาง Dev team ก็ต้องทำตามความต้องการไป
• ฝั่งคนใช้งานข้อมูล ก็มาดึงข้อมูล หรือ ผลจาก Centralize data team ไป เพื่อนำไปวิเคราะห์ตาม product ต่าง ๆ ต่อไป

จากรูป ถ้ามีคนใช้งาน data จาก Centralize data team เยอะ ๆ
ก็ต้องไปดึงข้อมูลมากจากหลาย ๆ Data source
ต้องมี knowledge ใน business domain ต่าง ๆ เพียบเลยไหม
งาน overload ไหมนะ ไม่น่าหรือเปล่านะ !!
มันเกิดจากการทำงานแบบ centralize หรือไม่
ต่างฝ่ายต่างมีความเป็น owner data ในแต่ละส่วน
คำถามคือ ใครเป็น owner ที่แท้จริง
จะเปลี่ยนแปลง เพิ่มเติม ต้องทำอย่างไรบ้าง เยอะไหม ใช้เวลามากไหม
ตรงนี้น่าคิด !!

ลองมาดูอีกรูปที่พูดคุยกันคือ decentralize data transformation

จากภาพอธิบายได้ดังนี้

• Dev team นั้นเป็นเจ้าของ data อยู่แล้ว ดังนั้น ถ้ามีความต้องการนำ data ไปใช้งาน ทาง dev team ก็สามารถ port data ออกมาในรูปแบบที่ตกลงกัน หรือ ใช้เทคโนโลยีต่าง ๆ ที่เหมาะสม โดยได้รับการสนับสนุนและแนะนำจาก Central Data Engineer หรือเรียกเท่ ๆ ว่า Data platform as a service เพื่อช่วยให้ Dev team สามารถ port data ออกมาได้ง่ายและรวดเร็ว
• ฝั่งคนใช้งานข้อมูล ก็มาดึงข้อมูลจาก data port ได้เลย ซึ่งเป็นการทำงานร่วมกันระหว่าง เจ้าของ data (data producer) และ ผู้ใช้งาน data (data consumer) แบบตรง ๆ ซึ่งสิ่งที่ต้องคิดต่อมาคือ เรื่องรูปแบบการเชื่อมต่อผ่านระบบ network ต่อไป

จะเห็นได้ว่าทั้งสองภาพ กำลังมองเรื่องของหน้าที่รับผิดชอบต่อข้อมูล
หรือรวมไปถึงความเป็นเจ้าของข้อมูล
รวมถึง operation cost ต่าง ๆ ที่เกิดขึ้นด้วย

ดังนั้นสิ่งที่สำคัญมาก ๆ คือ ให้เน้นไปที่เรื่องของ people, process และ organization
ก่อนที่จะลงไปถึงเครื่องมือที่จะนำมาใช้งาน

น่าสนใจมาก ๆ เป็นเนื้อหาในหนังสือ Data Mesh in Action
ยังไม่ต้อง Data mesh เพียงแต่ดูแนวทางในการจัดการ data ก็พอ

จากการพูดคุยกับทีมพัฒนาหลาย ๆ ที่ ที่ทำงานแบบ Remote เป็นหลัก
ต้องประชุมและคุยงานผ่าน Zoom, Microsoft Teams และ Google Meet เป็นต้น
มักจะพูดเป็นสียงเดียวกันว่า
ประชุมหนักกว่าการประชุมในห้องประชุมแบบ physical อีก
ทั้งประชุมซ้อน
ทั้งเน้นเข้าประชุม แต่ไม่เน้นการมีส่วนร่วม
ทั้งประชุมไม่เป็นเวลา เช้าบ้าง เที่ยงบ้าง ค่ำ ๆ ดึก ๆ บ้าง

ปล. ไม่น่าจะเป็นเรื่องจริง ๆ น่าจะเป็นเรื่องตลกขำขันมากกว่า

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

นักพัฒนาบางคนถึงกับบอกว่า
การประชุมไม่ได้ทำให้เกิด code
ดังนั้นฃขอไม่เข้าประชุมนะ

เวลาการพัฒนาน้อยลง แต่แผนหรือ dealine ยังคงเดิม
มันยังไงกันนะ ?

พอประชุมเสร็จปั๊บ
มีมาถามอีกว่า งานเสร็จยัง
พี่ต้องการอะไรกันแน่ ?

ดังนั้นสิ่งแวดล้อมแบบนี้ มันเหมาะสมหรือไม่นะ ?
หรือดีต่อบางคนกันนะ !!

ไปดูข้อมูลจาก Clockwise พบว่า

นักพัฒนาประชุมไปกว่า 1 ใน 3 ของเวลาทำงาน
มีเวลาในการ focus กับการเขียน code จริง ๆ แค่ 50% เท่านั้นเอง

และยิ่งบริษัทมีขนาดใหญ่ขึ้น จำนวนชั่วโมงของการประชุมก็มากยิ่งขึ้น !!

ไม่ได้บอกว่า การประชุมไม่ดี

แต่การประชุมที่ดีควรชัดเจน
ไม่ใช่ประชุมเพื่อประชุมครั้งต่อไป
คนเข้าประชุมต้องรู้ agenda และ ทำการบ้านมา
เวลาการประชุมต้องมีขอบเขต
การประชุมต้องมีเป้าหมาย ผลสรุป บันทึกผล

รวมทั้งพวก Async tools มาใช้งาน
จะได้ไม่ต้องพูดคุยกันทันที เดี๋ยวค่อยตอบทีหลังก็ได้

หลาย ๆ บริษัทเริ่มมีการกำหนด วันที่ไม่มีประชุม (No meeting day)

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

จะเห็นได้ว่า technology นั้นเข้ามาช่วยเยอะมาก ๆ

แต่สิ่งที่ขาดไม่ได้เลยก็คือ
การเปลี่ยนแปลงพฤติกรรม หรือ culture ขององค์กรด้วยเช่นกัน

เพิ่งสังเกตเห็นว่า Postman นั้นสนับสนุน gRPC แล้ว
ซึ่งก่อนหน้านี้ก็สนับสนุน Web Socket
แต่ยังอยู่ในสถานะ beta เท่านั้น
โดยเราสามารถ upload proto file เข้ามายัง request ได้เลย
จากนั้น Postman จะตรวจสอบให้เองว่ามี service และ method อะไรบ้าง

ความสามารถประกอบไปด้วย

• สนับสนุนการทำงานของ gRPC ทั้ง 4 แบบ คือ request/response, client stream, server stream และ bi-direction stream
• ทำการตรวจสอบ data type ของฝั่ง client ว่าเป็นไปตามที่กำหนดใน proto file หรือไม่
• ทำการสร้าง example message ให้
• สามารถ cancel method ต่าง ๆ ของ gRPC ได้ตลอดเวลา
• ใช้งาน environment ได้ปกติ
• ทำงานร่วมกับ git provider ต่าง ๆ ได้

สิ่งที่ขาดไม่ได้เลย คือ สามารถเขียน Test Script ใน request ได้เช่นกัน

แสดงดังรูป

ลองใช้งานกันดูครับ

Reference Websites

• Postman Now Supports gRPC

วิธีการสำหรับการ scale database
ให้รองรับข้อมูล และ traffic ที่มากขึ้นนั้น มีหลายวิธี
ยกตัวอย่างเช่น

• การขยายเครื่องให้ใหญ่ขึ้น
• การเพิ่มเรื่องให้มากขึ้น
• การจัดทำ index แต่ถ้ามีข้อมูลในแต่ละ table มากขึ้น ก็ใหญ่ ดังนั้นต้องทำ partition เพื่อให้ table เล็กลง และ index มีขนาดเล็กลง
• การทำ replication เช่น master-slave, multi-master เป็นต้น เพื่อแยกระหว่างการ read กับ write data ออกจากกัน
• การทำ house keeping ของข้อมูล ให้มีใช้และเก็บเท่าที่จำเป็น

แต่ก็ยังมีวิธีการอื่น ๆ เช่น การทำ Database Sharding

เพื่อทำการกระจายข้อมูลไปยัง database server ที่อยู่ต่างที่กัน
นั่นคือการกระจายข้อมูลไปจัดเก็บในแต่ละที่
จะช่วย share เรื่องของ data และ load ที่เข้ามาได้
แต่ความยากคือ จะแยกข้อมูลด้วยอะไร ?
เพื่อให้เกิดประโยชน์สูงสุด
โดยตรงนี้ต้องดูตาม use case ไป ว่าเป็นอย่างไรด้วย

ยกตัวอย่างเช่น

• Hash-based
• Range-based
• Location-based
• Key/Directory-based

แน่นอนว่า แนวทางนี้มีทั้งข้อดีและข้อเสียเช่นกัน

ถ้าแบ่งข้อมูลผิด อาจจะทำให้ข้อมูลกระจุกอยู่ในบาง shard มากจนเกินไป
หรือในการดึงข้อมูลนั้น อาจจะต้องไปดึงจากหลาย ๆ shard ก็จะส่งผลเสียมาก ๆ
ยิ่งถ้ามีการ re-shard ก็ยิ่งใช้เวลามาก หรือ หนักกว่านั้นต้องปิดระบบเพื่อจัดการอีก
รวมไปถึงเรื่องของการ monitoring และ backup

ดังนั้นจึงมีเครื่องมือเข้ามาช่วยบ้าง
ยกตัวอย่างเช่น Vitess สำหรับ RDBMS
หรือจะเป็นพวก MonogDB และ Redis ก็มีเช่นกัน

กลับมาดูก่อนว่า ปัญหาของเราคืออะไร
แล้วจะมาดูว่า มีวิธีการอะไรช่วยแก้ไขหรือบรรเทาได้บ้าง

Reference Websites

• Understanding Database Sharding
• Database Sharding
• Lessons learned from sharding Postgres at Notion

บันทึกการอ่านบทความเรื่อง
Under the hood: How we built API versioning for LinkedIn Marketing APIs
ทำการอธิบายแนวทางในการจัดการ version ของ maketing api ว่าเป็นอย่างไร
ซึ่งเป็นอีกแนวทางท่ีน่าสนใจ
มาดูกันว่าเป็นอย่างไรบ้าง ?

เริ่มต้นจากไม่มีการจัดการ version ของ API เลย

ช่วงแรก ๆ ก็ใช้งานได้ปกติดี
แต่เมื่อมี partner หรือ ผู้ใช้งานมากขึ้นแล้ว
ทาง business ต้องการให้ทาง delivery team ส่งมอบงานรวดเร็ว
พร้อมกับการเปลี่ยนต่าง ๆ ที่ตามมา
แต่ยิ่งทำก็ยิ่งช้า ทดสอบก็ยาก ยิ่งเกิดความผิดพลาดสูง
ส่งผลให้ไม่สามารถวางแผน หรือ วาง roadmap ของระบบได้เลย

ปัญหาหลัก ๆ ของ API คือ ไม่มีการจัดการ version ใด ๆ
คนจริงต้องใช้ version ล่าสุดเท่านั้น
ก็ให้เกิด breaking change ต่อ partner ที่ใช้งานอย่างมาก

แสดงโครงสร้างดังรูป

ดังนั้นจากปัญหาดังกล่าว เลยเริ่มมองเรื่องการจัดการ verision กัน !!

โดยได้ทำการสร้างรูปแบบการทำงาน และ platform ในการจัดการขึ้นมา
เป้าหมายหลัก ๆ เพื่อแก้ไขปัญหาจากข้างต้น
รวมทั้งยังต้องปรับปรุงเรื่อง Developer experience อีกด้วย

ซึ่งมี principle ในการจัดการ version ของ API ไว้ดังนี้

• Slow is smooth, and smooth is fast
• Future-first architecture
• API first
• Don’t disrupt customers
• Decoupling

จากแนวคิดเหล่านี้ทำให้เกิดโครงสร้างของระบบมาใหม่

ทำการเพิ่ม API gateway เพื่อเป็นทางเข้าเดียวจากผู้ใช้งาน
ทำให้สามารถจัดการเรื่อง authentication, authorization และ request mapping ต่าง ๆ ได้ง่ายขึ้น
จากนั้นทำการสร้าง Mid tier สำหรับส่วนการจัดการ API ของทางฝั่ง marketing เข้ามา

แสดงดังรูป

ในส่วนของ Mid tier นั้น จะจัดการ version ตาม request ที่ส่งเข้ามา
โดยในแต่ละ version จะถูก route ไปยัง service ที่ mapping ไว้
แต่ไม่ควรทำการดูแล version ที่มากจนเกินไปด้วยเช่นกัน

แสดงดังรูป

ผลจากการจัดการ version แบบนี้ของ API
ส่งผลให้ Developer experience ดีขึ้น
รวมทั้งการเปลี่ยนแปลง version ไม่กระทบต่อของเก่าหรือปัจจุบัน
และลดปัญหาจาก schema จาก API ที่เปลี่ยนไป

ในการพูดคุยเรื่อง การจัดการ Technical Debt หรือหนี้เชิงเทคนิค
ว่าเราควรจัดการอย่างไรดี
มีแนวทางอะไรที่น่าสนใจ
เพื่อช่วยลดให้น้อยลง
มาดูกันหน่อย

เริ่มด้วยคำถามดีกว่า เพื่อให้เราเองตอบว่ามีปัญหาหรือไม่ ?

ถ้าไม่มีปัญหาจะแก้ไขอะไรละ !!
มาตอบคำถามกัน

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

คำถามต่าง ๆ เหล่านี้ จะเกี่ยวข้องกับ

• Software Architecture รวมทั้งการเปลี่ยนแปลงไปตามความต้องการที่เปลี่ยนไป
• การ design ระบบงาน
• Technical risk
• Coding
• Quality assurance

แนวทางในการจัดการ Technical Debt นั้นมีทั้ง process และ tool มาช่วย

ยกตัวอย่างเช่น

• มีการ review ทั้ง pair programming, ทั้ง code review เป็นทีม การเปิด PR ต่าง ๆ รวมทั้งการ refactoring ที่จำเป็นต้องมีชุดการทดสอบอีก ซึ่งต้องทำให้บ่อย เพื่อลดจำนวนของสิ่งที่ต้องคุยหรือ review กัน
• มีชุดของเครื่องมือมาช่วยเหลือนักพัฒนา ทั้งเรื่องของ format code, coding standard, structure, bug และ security เช่นพวก SonarQube, Dependabot, Snyk, Mend เป็นต้น
• เพื่อลดปัญหาที่อาจจะเกิดขึ้น สามารถวางโครงสร้างที่ชัดเจน เหมาะสมต่อคนและระบบ ไม่มากหรือน้อยจนเกินไป
• กำหนด guideline ต่าง ๆ ของทีมพัฒนาขึ้นมา เช่น coding standard, naming convention, การทดสอบ, รูปแบบของ commit message, code quality, pair programming และ review process เป็นต้น

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

Reference Websites

• Software Architecture Notes
• Tips To Reduce Technical Debt

จากที่ได้แบ่งปันเรื่องเกี่ยวกับ Microservices มานั้น
มีคำถามที่น่าสนใจเกี่ยวกับการ tracing ข้อมูลของ message
ที่ส่งเข้าไปยัง Apache Kafka ว่าส่งไปไหม ผลการทำงานเป็นอย่างไร
รวมทั้งดูแบบ end-to-end ด้วยว่าเกิดอะไรขึ้นบ้าง
เนื่องจาก message นั้น ๆ อาจจะก่อให้เกิดการทำงาน หรือ event อื่น ๆ มากมาย
ตามแนวคิดของ Event-based Architecture

คำตอบหนึ่งที่คิดว่าน่าจะมีประโยชน์คือ การใช้งาน Distributed Tracing
ซึ่งเป็นหนึ่งในเรื่องของ observability นั่นเอง

ยกตัวอย่างของการจัดการปัญหานี้

เครื่องมือที่ใช้งานประกอบไปด้วย

• Spring Boot
• Spring Cloud Sleuth
• Zipkin
• Spring Kafka

Spring Cloud Sleuth นั้นจะสนับสนุน OpenTelemetry แล้ว
อีกอย่างสามารถทำงานร่วมกับ Spring Kafka
และ REST API ต่าง ๆ ที่พัฒนาด้วย Spring Web ได้เลยโดยไม่ต้อง config อะไร

ซึ่งเป็นอีกแนวทางในการ tracing message ได้
ในแต่ละ message จะมี tracing id ไปใน message เสมอ
ทำให้เราสามารถใช้งานได้อย่างสะดวกสบาย

ปัญหาที่มักจะตามมาจากระบบที่พัฒนาตามแนวคิด Event-based driven
หรือ Event-Driven Architecture นั่นคือ
เรื่อง Data consistency หรือความถูกต้องของข้อมูล
เราจะจัดการปัญหานี้ได้อย่างไรบ้าง ?

ในการออกแบบระบบตามแนวคิดนี้
ช่วยให้ส่วนการทำงานต่าง ๆ แยกออกจากกัน
หรือไม่ผูกมัดกันมากนัก (loose/less couple)
แต่ละส่วนการทำงานทดสอบได้ง่ายขึ้น
ลดปัญหาเรื่อง single point of failure
สามารถ scale ได้ง่ายขึ้น จะได้ไม่เป็นคอขวดของระบบ

ยกตัวอย่างของระบบงานแบบง่าย ๆ

• Producer คือฝั่ง subscription service จากผู้ใช้งาน
• Consumer คือฝั่ง newsletter service เพื่อส่ง email ไปยัง user ที่ subscribe ไว้

จากรูปถ้าทำงานแบบปกติ คือ success case จะไม่มีปัญหาอะไร
แต่สิ่งที่ต้องคิดและออกแบบไว้เสมอคือ ปัญหาที่อาจจะเกิดขึ้นได้
เราจะแก้ไข หรือ หาวิธีการรองรับไว้อย่างไร

ตัวอย่างของปัญหาที่อาจจะเกิดขึ้นได้

• ข้อมูลบันทึกที่ database ของ subscription service เรียบร้อย แต่ไม่สามารถส่งไปยัง message broker ได้ ทำให้ไม่มีข้อมูลใน newsletter service นี่คือข้อมูลหาย
• ข้อมูลไม่สามารถบันทึกใน database ของ subscription service ได้ แต่ดันส่งไปที่ newsletter service ได้ซะงั้น แบบนี้ก็ไม่น่าจะถูกต้อง
• อาจจะเกิดการส่ง event ซ้ำมายัง message broker ได้ ส่งผลให้ข้อมูลที่ newsletter service ซ้ำอีก

สิ่งที่ต้องคิดต่อคือ ถ้าเกิดปัญหาเหล่านี้ขึ้นมาจะแก้ไขอย่างไร

ก่อนอื่นต้องมีระบบ monitoring หรือ observability ก่อนว่า
มีปัญหาเกิดขึ้นหรือไม่ ทั้ง Application metric, Distributed tracing และ Centralized logging
รวมไปถึงพวก alert system จากปัญหาที่เกิดขึ้น
เพื่อทำให้เราเข้าไปยังจุดเกิดปัญหาได้รวดเร็ว

ต่อมาคือ การออกแบบเพื่อป้องกันปัญหา ไม่ให้เกิดขึ้น หรือ เกิดน้อยสุด ๆ

• ถ้าส่งไปยัง message broker ไม่ได้ ก็ต้องพยายามส่งให้สำเร็จ หรือ ต้องมีการบันทึกสถานนะของการส่งไว้ว่า ส่งไม่ได้
• ถ้าฝั่ง consumer ได้รับ event/message แล้วแต่ process ไม่สำเร็จ จำเป็นต้องจัดการ ไม่ว่าจะเป็นการ retry หรือ dead letter message หรือ แจ้งกลับไปยัง producer ว่าไม่สามารถ processได้นะ
• ถ้าฝั่ง producer ไม่สามารถบันทึกได้ ต้องไม่ส่งไปยัง message broker
• ถ้ามีการส่ง event/message เดิมเข้ามายัง message broker แล้ว ทาง consumer นั้นก็การันตีว่า จะไม่ทำการ process ซ้ำ หรือ ทำซ้ำก็ได้แต่ผลการทำงานก็จะเหมือนทำงานครั้งเดียว นั่นคือ เรื่องของ Idempotent นั่นเอง

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

Reference Websites

• Ensuring Data Consistency between Event-Driven Microservices

บันทึกปัญหาที่เจอเกี่ยวการ build ระบบงานที่พัฒนาด้วย Java กับ Apache Maven
เพิ่มเติมความยากคือ เอาไป run ใน Docker อีก
ปัญหาที่เจอคือ เรื่องการ download dependency/library ใหม่
ในขั้นตอนการ build Docker image จาก Dockerfile
ซึ่งใช้เวลาในการ download นานมาก ๆ
ดังนั้นจึงมาหาวิธีการแก้ไขหน่อย

วิธีการที่ง่ายสุด ๆ คือ ทำการ download นอก Docker

จากนั้นทำการ copy JAR file เข้าไปใน Docker ดังนี้

แต่วิธีไม่สามารถควบคุม JDK ที่ทำการ build JAR file ได้
จึงใช้งาน Docker multi-stage build เข้ามาช่วย

สามารถเขียน Dockerfile ใหม่ได้ดังนี้

• ขั้นตอนที่ 1 ทำการ build JAR file
• ขั้นตอนที่ 2 ทำการ copy JAR file มา เพื่อสร้าง image ที่มี JRE

ผลที่ตามมาคือ ช้ามาก ๆ เพราะว่า ต้องทำการ download ใหม่ทุกครั้ง
ยิงเป็น Spring Boot projectด้วยยิ่งช้าไปกันใหญ่
จึงต้องแก้ไขความช้านี้ก็หน่อย

มีวิธีการที่ทำได้ดังนี้

• ทำการ copy folder .m2 เข้าไปเลย ง่ายแต่ดูแปลก ๆ นะ
• ทำการเปลี่ยนไปใช้งาน Reverse proxy หรือ Local Package Server สำหรับ Apache Maven Dependency เลย
• ใช้ Docker buildkit
• Spring Boot Layer JAR
• Apache Maven Daemon
• Mount volume ของ Docker

แต่วิธีการที่ชอบ และ เหมาะกับที่ต้องการคือ การ Mount volume ของ Docker
และวิธีการที่ดีอีกคือ Spring Boot Layer JAR แต่ทำเยอะไปหน่อย

ตัวอย่างการใช้งาน Mount volume ของ Docker

ผลที่ได้คือ ถ้าทำการ build ใหม่ด้วยการเพิ่ม dependency/library ไป
จะไม่ download ของเดิมอีกต่อไป จะ download ที่ของใหม่เท่านั้น
ถ้าใช้ร่วมกับ Local Package Server ก็จะรวดเร็วยิ่งขึ้น

Reference Websites

• Faster Maven builds in Docker
• Optimize Spring Boot application Docker images to improve CI/CD efficiency

ในโลกของ JavaScript นั้นมีเครื่องมือใช้งานเยอะเหลือเกิน
เพื่อแก้ไขปัญหาต่าง ๆ
หนึ่งในนั้นคือการจัดการ version ของ NodeJS
เพื่อให้ใช้งาน version ต่าง ๆ ตามแต่ละ project ให้ง่ายขึ้น
ปกติก็จะมี nvm และ snm เป็นต้น

แต่ก็มี Volta อีกตัวที่บอกกันว่า ดีกว่า
ถูกพัฒนาด้วยภาษา Rust
ดังนั้นมาลองใช้งานกันหน่อย

โดยติดตั้งตามเอกสารได้เลย
ส่วนการใช้งานเป็นดังนี้

• ติดตั้ง NodeJS ใน version ที่ต้องการผ่าน $volta install
• กำหนด version ของ NodeJS แต่ละ project ในไฟล์ package.json ผ่าน $volta pin

รวมทั้งสามารถกำหนด version ของ NPM ได้ด้วยเช่นกัน

ลองใช้งานกันดูครับ