Taskworld Tech Blog

ใช้ User story อย่างไรให้มีความหมาย

เคยคิดกันบ้างมั้ยว่าทำไมเราถึงต้องเขียน User Story ด้วยนะ?

ในโลกของ Agile เรากำหนดว่า PO หรือ Product owner มีหน้าที่แค่ระบุปัญหาและความสำคัญของปัญหา ส่วนการออกแบบ Solution จะเป็นหน้าที่ของ Cross-functional team ที่จัดการตั้งแต่ต้นจนจบ

Meaningful Standups

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.

Step back from requirement

สมมติเราทำระบบบัญชีระบบนึง มีประเภทของ Transaction 3 แบบ คือ X,Y,Z

ถ้า Requirement แรกบอกว่าทุกๆ “รายการ Transaction ทุกอันต้องหักเงินในบัญชีลูกค้า”

account.debit(transaction.amount);

On framework dependencies

Avoid reusing data structure

ย้อนกลับมาคิด คือที่ผมมักชอบบอกว่าคิดดีๆ ก่อน Abstract โค้ด เพราะที่ผ่านมาผมทำร้ายตัวเองด้วยการ Reuse ของที่ไม่ควร Reuse บ่อยกว่าทำร้ายตัวเองด้วยการเขียนโค้ดซ้ำไปทั่ว

แล้วจังหวะที่เจ็บเพราะโค้ดซ้ำ มันเจ็บไม่เท่า Abstract โค้ดผิดแล้วต้องรื้อทิ้ง…

Code that tell a story

วันนี้ผมได้รีวิวโค้ดของน้องคนนึง ซึ่งเขาต้องการแก้โค้ดประมาณนี้

function doSomethingA() {
  // ............ Some statements

  step2()

  // ............ Another many statements
}

Why should we separate business logic out of view? in Layman term

ทำไมเราถึงควรแยก Business logic ออกจาก View ตั้งแต่แรกเลย? นี่เป็นเรื่องนึงที่ผมไม่กลัว Premature refactor

สมมติว่าเราได้รับ Requirement มาว่า

MVP & Clear assumption

ผมพบว่าในการทดลอง MVP หรือการทดสอบ Feature อะไรซักอย่างในตลาด สิ่งที่ผมพบว่ายากมากคือการอธิบายให้คนเข้าใจว่า เราควรตั้ง Assumption ที่เคลียร์

สมมติวันนี้เราบอกว่าเราออกฟีเจอร์ตัวนี้ออกไปเพื่อทดสอบตลาด เราควรมี Assumption ที่เคลียร์มากๆ เช่น

Refactor for readability, not for keystrokes

“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