June 10, 2021
ผมพบว่ามีหลายวิธีที่จะ manage source code และ manage pull request (หรือ merge request) แต่ผมยังไม่เจอว่ามีใครเขียนรวบรวมไว้
ผมจะ focus ในเรื่องที่เกี่ยวกับ การ Approve code การ Run CI และการ Merge code
การ Approve code
การ review สามารถทำได้ทั้ง offline และ online เช่น
review offline แบบ pair programming
review offline แบบ mob programming
review online ผ่านระบบ เช่น GitHub, GitLab กฎเกณฑ์ในการ approve code มีหลายแบบที่สามารถเลือกใช้ได้ ไม่ว่าจะ review แบบ offline หรือ online เท่าที่ผมรู้จักมีประมาณนี้
Read more...
April 21, 2021
เคยลองเปิด log message ที่ตัวเองเขียนไหมครับ? รู้สึกอย่างไรกับ log เหล่านั้น? มีประโยชน์ตามที่ต้องการหรือเปล่า? และเมื่อระบบมีปัญหาลองเปิด log message อ่านดูอีกครั้ง คิดว่า log เหล่านั้นให้ประโยชน์กับเราขนาดไหน?
ผมลองใช้เทคนิคเหล่านี้ในการเขียน log มันทำให้ log มีประโยชน์มากขึ้น
1. Use structured log
ส่วนตัวผมแนะนำ log เป็น JSON format เนื่องจากสามารถใส่ข้อมูลชนิดต่างๆ ได้หลากหลาย มีโครงสร้างชัดเจน หากจะใช้ structure แบบอื่นก็ทำได้ ขอให้ parse ข้อมูลใน log ได้ง่าย แต่สิ่งที่ไม่ควรทำคือ log แบบไม่มีโครงสร้างที่ชัดเจน
ตัวอย่าง:
{"timestamp":"2021-04-21T10.30.15.412Z","level":"INFO","message":"Order created","orderId":"ORD1","userId":"U1","subsystem":"SvcName.Package.Class.Method"}
Read more...
March 16, 2021
Java start-up time มี overhead หลายจุด จากความพยายามที่ผมพยายาม optimize ให้ระบบของบริษัท start ได้เร็ว เพื่อทำให้ productivity ของ engineer ดีขึ้น (ปัจจุบัน start up time ~30-40sec) แต่ก็ยังไม่สำเร็จ แต่ก็มีหลายเรื่องได้เรียนรู้ระหว่างที่ทำ
จากที่ลองทำ Profiler ออกมา เจอว่าตอนที่ java app ใช้ CPU ไปกับสิ่งเหล่านี้ในตอน start (เรียงจากมากไปน้อย)
Read more...
March 6, 2021
ที่บริษัทใช้ ELK (Elasticsearch, Logstash, Kibana) ทำระบบ centralize log และผมกำลังสนใจว่าอยากจะใช้ Elasticsearch ในการทำ time-series สำหรับ monitor ระบบไปด้วย เลยขอลงมาดูรายละเอียดงานด้วยตัวเองบ้าง
อันดับแรกคือทำอย่างไรให้ระบบ centralize log มีความเร็วเพียงพอต่อการ ingest log เข้าไป และจากนั้นค่อยดูว่าทำอย่างไรให้ query log/aggregate log data ได้รวดเร็ว
ตัวเลข stats ปัจจุบันที่ ELK แสดงมีดังนี้
1,000,000 log lines in each minute (from Kibana)
100,000 average ingest rate per minute (from AWS)
9,200,000,000 searchable document (from AWS) Read more...
February 21, 2021
หลังจากได้ฟัง Clubhouse ของต่างชาติเกี่ยวกับการทำงานของ Product & Engineer ก็มีประเด็นที่เค้าพูดกันถึง Retrospective มักจะ focus ผิดจุด เลยอยากเขียนเอาไว้เตือนความจำ
Retrospective ควรจะ focus ว่าเราจะ deliver value ให้ customer ได้เร็วขึ้นอย่างไร มี process ตรงไหนที่ทำให้ deliver value ช้า เช่น build นาน, ต้องรอ manual test, รอ review code นาน, แก้ code หลายรอบ, product spec ไม่เคยนิ่ง, ติด breaking change deploy ไม่ได้ ฯลฯ
ทำไมต้อง focus แค่ deliver value?
High-performance team กับ normal team ต่างกันตรง speed ในการ deliver value ทีมที่ deliver ได้เร็วกว่าจะมีเวลามากกว่าในทุกๆ เรื่อง เช่น เมื่อส่ง feature ได้เร็ว ทีมก็จะมีเวลาในการแก้ไขปัญหาได้เร็วด้วยเช่นกัน สามารถทดลอง idea ได้มากกว่า iterate ได้เร็วกว่า
ปัญหาของการทำ Retrospective แบบทั่วๆ ไป
Retrospective ส่วนใหญ่ focus แค่ feeling ของคนในทีม ไม่ได้ focus เรื่องการ improve process ให้ deliver value ได้เร็ว
มีแต่ปัญหา list ออกมา แต่ไม่มี solution/action ออกมา
มี solution/action แต่ไม่มี ownership ที่ชัด
มี ownership แต่ไม่มีการ follow up progress และ action ไม่เกิด
มี action และ ownership แต่ปัญหาต้องการ buy-in จากคนอื่นๆ ซึ่ง owner ไม่มี power มากพอ
มี action มี power แต่ปัญหาถูกแก้ช้าเกินไป ไม่ถูกทำให้มีความสำคัญ ถ้าทำ retrospective ที่ focus on improve deliver process และมีการแก้ไขปัญหาได้เร็ว ทีมจะทำงานได้เร็วขึ้น สนุกขึ้น มีความสุขมากขึ้น และด้วย speed นี้จะทำให้ team ทิ้งห่างจากทีมอื่นๆ ได้เร็วยิ่งขึ้น
# agile # team