เคยได้ยินคำนี้ไหม ? เดี๋ยวเราจะกลับมาแก้ไข !! เดี๋ยวค่อยทำ ทำอันนี้ก่อน เรามักจะเดี๋ยว … สิ่งที่มักจะเกิดขึ้นคือ สิ่งที่บอกว่าเดี๋ยวจะกลับมาทำ จะไม่เคยถูกหยิบมาทำเลย เพราะว่า งานในมือมีแต่เร่งด่วนและด่วนมาก ทำไมนะ
development Archive
สรุปเรื่อง The Seven Wastes ในการพัฒนา Software
เพิ่งคุยเรื่องของการพัฒนา software กันไปว่า มันมี waste อะไรบ้างที่มักจะเกิดขึ้นมา แถมส่งผลมากมายต่อการพัฒนา หนึ่งในนั้นคือ speed หรือความเร็วของการพัฒนา เลยหยิบรายละเอียดมาจาก Lean for Software Development มาสรุปไว้กันลืมในบางข้อ มาเริ่มกันเลย
ทำการสรุปจากบทความเรื่อง Test Desiderata (desired things)
อ่านบทความเรื่อง Test Desiderata ของคุณ Kent Beck ซึ่งบทความนี้แปลง่าย ๆ คือ คุณสมบัติที่จำเป็นของ test นั่นเอง โดยทำการสรุปไว้ 12 เรื่อง จึงทำการแปลและสรุปตามความเข้าใจไว้นิดหน่อย
ว่าด้วยเรื่อง Engineer’s Guide to a Good Night’s Sleep
วันนี้ว่าง ๆ เลยมานั่งอ่าน The InfoQ eMag – Taming Complex Systems in Production เป็น miniBook จากทาง InfoQ แนะนำสำหรับจัดการหรือควบคุมระบบงานที่ยิ่งนานวันยิ่งมีความซับซ้อนมากขึ้นเรื่อย ๆ ยิ่งเมื่อเกิดปัญหาขึ้นมา บ่อยครั้งต้องมีค่าใช้จ่ายสูงมากในการแก้ไขเพื่อให้ระบบกลับมาทำงานได้อย่างปกติ ดังนี้เราควรต้องทำการแก้ไขและปรับปรุงแล้วนะก่อนอื่นเราต้องทำการปรับปรุงในแง่ขององค์กร คน และระบบการทำงาน ให้มีความยืดหยุ่น และสามารถกลับคืนมาสู่สภาวะการทำงานปกติได้ง่าย
มาดูแนวทางการทำงานทีมพัฒนาของ Unsplash ว่าเขาทำกันอย่างไร
อ่านบทความเรื่อง Scaling Unsplash with a small team อธิบายว่าทีมพัฒนาระบบ Unsplash นั้นเป็นอย่างไร ทำงานและคิดกันอย่างไร ซึ่งเป็นอีกมุมมองที่น่าสนใจดีจึงทำการสรุปไว้
รูปสวย ๆ เกี่ยวกับการพัฒนา Software จาก MonkeyUser
เห็นใน page ของ InfoQ ใน facebook ทำการ post รูป Possible Code Content จาก MonkeyUser.com เป็นรูปอธิบายรูปแบบต่าง ๆ ของการพัฒนา software ยกตัวอย่างเช่น TODO Bug Missing feature Hidden feature Duplication code Complexity Code from stackoverflow Do not touch code
เราต้องการรูปแบบการพัฒนา software ที่ดีที่สุด หรืออย่างไร ?
ในการพัฒนา software นั้นเราน่าจะชอบขั้นตอนการทำงานที่ ทำซ้ำได้ง่าย (Repeatable) มีความน่าเชื่อถือสูง (Reliable) มีความยืดหยุ่น (Flixible) เมื่อมีปัญหาสามารถคืนสภาพกลับมาปกติได้เร็ว (Resilient)
ไม่มากก็น้อยไป สำหรับการพัฒนา
นั่งอ่านหนังสือ Real World Software Development ไปนิดหน่อย พบรูปแบบของ code ที่น่าสนใจ นั่นก็คือ ไม่มากก็น้อยไป จึงทำการสรุปไว้
ว่าด้วยเรื่องของ Technical Excellence
วันนี้มีโอกาสมาแบ่งปันเรื่องของ Technical Excellence ซึ่งเป็นเรื่องหนึ่งที่สำคัญมาก ๆ ของการพัฒนา software จึงทำการสรุปไว้อีกนิดหน่อย ว่ามีอะไร เป็นอย่างไรบ้าง
ว่าด้วยเรื่องของ Project ที่ล้มเหลว
นั่งอ่านหนังสือเกี่ยวกับการพัฒนา software มีเรื่องที่น่าสนใจคือ สาเหตุที่ทำให้ project มันล้มเหลวหรือ fail มาจากหลายสาเหตุมาก ๆ เลยสรุปไว้นิดหน่อย บางครั้งมีงานออกมาดีมาก แต่ทีมแตกกระจาย บางครั้งไม่มีงานออกมา แต่ทีมดีมาก บางครั้งทีมแย่และงานก็แย่ คำถามคือ คำว่าล้มเหลววัดจากอะไร ? ปล. ปกติเราน่าจะทำ product มากกว่า project กันอยู่แล้ว ดังนั้นไม่น่าจะ fail กันมากหรอก ใช่ไหมนะ