จากการแบ่งปันเรื่องการพัฒนา 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 อย่างไว้ให้จึงทำการสรุปการอ่านไว้นิดหน่อย
อ่านเจอ tweet ที่น่าสนใจของคุณ Jez Humble ใน twitter.com เป็นผู้ร่วมเขียนหนังสือ Continuous Deliveryอธิบายเกี่ยวกับ Continuous Delivery/Deployment (CD) ว่ามันไม่ใช่การทำอะไรก็ได้เพื่อ build ระบบงานจาก code/config ที่อยู่ใน Version Control Systemจากนั้นก็ทำการ deploy ไปยัง production server ให้เร็วที่สุดจากนั้นก็ไปทดสอบบน production server อีกที
จากบทความของ Slack เรื่อง How we design out APIs at Slackทำการสรุปแนวทางในการออกแบบ API ของระบบออกมาว่าเป็นอย่างไรบ้างเพื่อช่วยทำให้ผู้ใช้งานหรือ developer ใช้งานง่ายขึ้นอีกทั้งช่วยให้การดูแลรักษา API ง่ายขึ้นด้วยซึ่งควรต้องคิดตั้งแต่การออกแบบกันเลยทีเดียวมิเช่นนั้นแทนที่จะได้ API ที่ดีมีประโยชน์ กลับได้ของที่แย่ ๆ ออกมาโดยมีแนวทางของการออกแบบดังนี้
สัปดาห์ที่ผ่านมา ทำการออกแบบ review และ พัฒนา API ของระบบงานพบว่าสิ่งที่ทำออกมานั้นมีปัญหาหลายอย่างไม่ว่าจะเป็นการพัฒนาที่ยากไม่ว่าจะเป็นการใช้งานที่ยากอีกดังนั้นจึงสรุปต้นเหตุที่ก่อให้เกิดปัญหาขึ้นมา