มีโอกาสได้แบ่งปันเรื่องเกี่ยวกับ feedback loop ในการพัฒนา softwareโดยหนึ่งในเรื่องที่น่าสนใจคือการให้ได้มาซึ่ง feedback ที่รวดเร็วเพื่อให้เรารู้และเข้าใจในสิ่งที่สร้างขึ้นมาว่า เป็นอย่างไรทั้งคุณภาพภายใน คือ code และโครงสร้าง รวมถึงการทำงานทั้งคุณภาพภายนอก คือ มุมมองจากผู้ใช้งาน เน้นว่าผู้ใช้งานจริง ๆ
เห็นบทความเรื่อง Things You Should Know About Databasesจากทาง Architecture Notesว่าด้วยเรื่องที่ควรต้องรู้เกี่ยวกับ database ที่ใช้งานกัน โดยเฉพาะ RDBMS (Relational DataBase Management System)ที่ถูกใช้งานกันอย่างมากในระบบต่าง ๆ
เป็นคำถามที่น่าสนใจว่า การ Refactor code ควรหรือไม่ ที่จะอยู่ใน backlogบ่อยครั้งเราจะพบว่า ทำ ๆ ให้มันเสร็จไปก่อน เดี๋ยวไม่ทันส่ง เดี๋ยวเราค่อยกลับมาแก้ไขให้มันดีขึ้นกัน
จากการแบ่งปันเรื่องการพัฒนา software นั้นมีเทคนิคหนึ่งที่ใช้งานบ่อย ๆ และแนะนำไป คือการแก้ไขปัญหาใหญ่ ๆ ด้วยการแบ่งเป็นปัญหาเล็ก ๆ ออกมาเพื่อแก้ไขทีละปัญหา และเมื่อแก้ไขจนครบจะช่วยให้เราแก้ไขปัญหาใหญ่ ๆ ได้หรืออาจจะเรียกว่าการทำ work break down นั่นเอง
ในการพัฒนา software นั้น เรามักจะพบเจอปัญหาต่าง ๆ มากมายทั้งสิ่งที่ควบคุมได้และไม่ได้แต่มีปัญหาที่เรามักจะพบเจอประจำในการพัฒนาดังนี้ซึ่งทำให้เกิดปัญหามากมายตามมา
จากบทความเรื่อง New data: What makes developers happy at workจาก Stackoverflow นั้น ทำการสรุปผลสำรวจเรื่องความสุขในการทำงานของนักพัฒนาว่าเป็นอย่างไรมีอะไรที่ทำงานมีความสุขในการทำงานบ้าง ?น่าจะเป็นอีกชุดข้อมูลที่น่าสนใจสำหรับบริษัทต่าง ๆ ด้วยเช่นกัน
ปัญหาหนึ่งที่มักเจอมาก ๆ ในการพัฒนาระบบงานคือการเปลี่ยนแปลง schema หรือ โครงสร้างของข้อมูลที่ใช้แลกเปลี่ยนกันทำให้เกิดปัญหาเรื่อง compatibility ของข้อมูลบ่อยครั้งจะเกิด breaking change จากที่ตั้งใจหรือไม่ตั้งใจก็ตามโดยเครื่องมือที่ได้รับความนิยมในการจัดการเรื่องนี้คือ Apache Avroปล. ใครที่ใช้งาน Apache Kafka น่าจะรู้จักเป็นอย่างดี
จาก Refcard เรื่อง Getting Started With Observability for Distributed Systemsทำการอธิบายเรื่องต่าง ๆ เกี่ยวกับ Distributed System หรือ ระบบแบบกระจายว่า มันคืออะไร มีข้อดีและข้อเสียอย่างไร จะดูแลรักษา และดูเรื่อง observability อย่างไร เช่น log, tracing และ metric เป็นต้น แต่สิ่งหนึ่งที่น่าสนใจคือ Distributed System มีประโยชน์อย่างไรในเชิง businessโดยทำการสรุปด้วยภาพนี้
การทำ code review ในขั้นตอนการพัฒนา software นั้น เป็นสิ่งที่จำเป็น และ ควรเป็นสิ่งที่เกิดขึ้นอยู๋ตลอดเวลาหรือบ่อยที่สุดโดยไม่รู้เหมือนกันว่าจะทำตอนไหนอย่างไร ?เพราะว่า มันขึ้นอยู่กับสถานการณ์ หรือ ข้อจำกัดอะไรบางอย่างแต่ควรทำให้บ่อย ๆ และงด drama ให้มากที่สุด
จากหนังสือ Good code, Bad code นั้นจะเน้นในเรื่องของความรู้และความสามารถพื้นฐานของการพัฒนาเพื่อช่วยให้พัฒนาระบบให้เป็นไปตามเป้าหมายที่ตั้งไว้โดยในเรื่องของ Code Quality นั้นมีคำแนะนำที่สำคัญ 6 อย่างไว้ให้จึงทำการสรุปการอ่านไว้นิดหน่อย
