Chia việc fix bugs như thế nào cho đúng trong một team dev?

ancomtrua22 · August 2, 2016, 1:38am

Chào mọi người,
Mình lập topic này để mời mọi người bày tỏ, chia sẻ ý kiến về chủ đề như tiêu đề topic. Có 2 vấn đề mình muốn thảo luận như sau:

Trong lúc phát triển (development phase), khi xuất hiện bug, và tìm ra nguyên nhân gây ra bug đó do code của dev nào, thì nên để tác gỉa đoạn code đó fix, hay một dev khác đang rảnh fix?
Trong giai đoạn bảo trì (maintainance), khi dev bảo trì muốn sửa lại luồng xử lý một feature nào đó để fix một bug, mà tác gỉa cũ không cho, thì nên fix theo ý kiến của tác gỉa cũ hay không? (Đa số trường hợp này sẽ là phải fix lụi).

Mình có hỏi google sama, thì câu trả lới cũng đa chiều lắm. Nên mình tạo topic này để hỏi mọi người, đặt vào bối cảnh Việt Nam ta, tính cách con người, cách thức làm việc của người Việt mình vào, thì 2 thắc mắc trên nên xử lý thế nào cho ổn nhất.

P/S: Lý do mình tạo topic này là bởi mình vừa trải nghiệm ở vài team và cách làm việc khá khác nhau. Team gần nhất, mình bị người cùng team đùn bug, nhờ mình fix, mình fix qua thì không triệt để, chê mình test không kỹ, còn mình fix lâu thì cũng chê này chê nọ, đổ thừa code mình gây crash (fail). Trước đó là hai team khác, thì không như team gần nhất này, mà việc ai người ấy làm, bug ai người đó fix.

petehouston · August 1, 2016, 11:06am

Sử dụng Git để quản lý thôi

Rule #1: nếu code mà không có test kèm theo (Unit tests, Integration Tests, …) thì reject không cho merge.
Rule #2: có issue, tạo branch hot-fix-issue-{number}, rồi thực hiện fix. Chạy test đảm bảo ok thì merge, không thì vẫn reject.
Rule #N: Chạy code coverage với unit test là biết ngay có test đủ hay không.

Kiểm tra bằng tay không được gọi là test, mà phải viết code để test.

ancomtrua22 · August 2, 2016, 1:29am

chưa thỏa mãn với câu trả lời của bạn lắm!
Git để quản lý source, commit. Ý bạn có phải là trong một team, giao bug bất kỳ cho dev nào fix cũng được, phải không?
Còn 3 cái rule kia, như mình thấy, làm gì có mấy team có văn hóa viết unit test kèm theo đâu, toàn đâm đầu vào code luôn không à. Ngay cái rule #1 cũng khó của Nam Cường, đâu phải feature nào cũng viết được test case (vd: mạng network chập chờn, dung lượng bộ nhớ đầy…)

nguyenhuuca · August 2, 2016, 1:54am

Trong giai đoạn dev, chú là người phát triển feature, nên fixed vẫn là trách nhiệm của chú. Có thể chú đang làm feature mới, feature cũ bị bug, tùy theo mức độ ưu tiện mà làm cái nào trước. Còn chú bảo để người rảnh fix, cái này sếp chú quyết định chứ không phải chú. Phải nhớ nguyên tắc là: Lỗi do mình làm mình phải chịu trách nhiệm. không thể để người khác đổ vỏ cho chú. Với là chú làm chú sẽ fix nhanh hơn.

Trong giai đoạn maintainance: lúc này thường sẽ là Integration Tests. sẽ có bug, enhance, improve, task sẽ được chia điều, không phân biết task đó trước đó ai làm. mà cũng sẽ theo mức độ ưu tiên. tất nhiên vẫn ưu tiên để người đã làm trước đó fix, bởi người đó nắm logic. Người khác fix, người ta cũng sẻ hỏi chú thôi.
Người ta dựa trên yêu cầu để làm, không có chuyện dev cũ không cho. Chú phải chứng mình, cách làm của người ta sai, không hợp lý,dẫn đến bug, chứ không phải chú bảo người ta làm không hay rồi sửa lại hết luồng. Không có chuyện fix lụi., khi fix mà gây ra lỗi khác gọi là level down, do chú không năm rõ logic, ảnh hưởng đến các thành phần khác. Khi fix lỗi của người khác, tốt nhất nên hỏi kỹ logic mình làm là gi. cái feature đó nằm ở đâu trong toàn hệ thống.

ancomtrua22 · August 2, 2016, 2:54am

Thanks anh! Câu trả lời rất chi tiết