บ่อยครั้งมากๆ ที่ผมจะเจอปัญหาแบบนี้ ทั้งในโค้ดตัวเองและโค้ดของคนอื่น แล้วผมพบว่ากว่าผมจะเห็นว่ามันเป็น Code smell ก็ต้องสั่งสมประสบการณ์มาเยอะเหมือนกัน
Meaningful Daily Scrum (Standup meeting) happened when react and do something differently, according to the information in daily standups.
Otherwise, it just become status update. That would be tedious and I prefer just continue with my work.
เคยคิดกันบ้างมั้ยว่าทำไมเราถึงต้องเขียน User Story ด้วยนะ?
ในโลกของ Agile เรากำหนดว่า PO หรือ Product owner มีหน้าที่แค่ระบุปัญหาและความสำคัญของปัญหา ส่วนการออกแบบ Solution จะเป็นหน้าที่ของ Cross-functional team ที่จัดการตั้งแต่ต้นจนจบ
ในวงการ Developer เรามักจะมีคำพูดที่ว่า “ถ้าเห็นว่ามันไม่ดี บ่นทำไม ทำไมไม่แก้ไขให้มันดีขึ้นล่ะ”
คำพูดนี้ฟังดูเผินๆ ก็อาจจะเหมือนเป็นคำพูดที่มีเหตุผล Make sense แล้วเป็นเรื่องที่คนทำงานที่มีทัศนคติดีควรจะมีไว้
“Optimize code for reading, not for typing.”
I have face a lot of programmer, who when refactoring, tends to optimize for number of typing strokes, at the cost of understandability
ผมพบว่าในการทดลอง MVP หรือการทดสอบ Feature อะไรซักอย่างในตลาด สิ่งที่ผมพบว่ายากมากคือการอธิบายให้คนเข้าใจว่า เราควรตั้ง Assumption ที่เคลียร์
สมมติวันนี้เราบอกว่าเราออกฟีเจอร์ตัวนี้ออกไปเพื่อทดสอบตลาด เราควรมี Assumption ที่เคลียร์มากๆ เช่น
It so happens when I test an app on the staging environment, somehow, the app failed to boot up. A dreaded blank page appears!
ย้อนกลับมาคิด คือที่ผมมักชอบบอกว่าคิดดีๆ ก่อน Abstract โค้ด เพราะที่ผ่านมาผมทำร้ายตัวเองด้วยการ Reuse ของที่ไม่ควร Reuse บ่อยกว่าทำร้ายตัวเองด้วยการเขียนโค้ดซ้ำไปทั่ว
แล้วจังหวะที่เจ็บเพราะโค้ดซ้ำ มันเจ็บไม่เท่า Abstract โค้ดผิดแล้วต้องรื้อทิ้ง…
This is a very common mistakes, that even I have get it wrong for quite a while along my career.
Let’s say that we needs to send email, and we will use a single class and single object.