Bài học kinh nghiệm: đọc kỹ specs…
Đó là bài học kinh nghiệm mà ở dự án nào tôi cũng gặp…
Bài học kinh nghiệm: đọc kỹ specs
Dưới đây mình xin chia sẻ về bài học kinh nghiệm: đọc kỹ specs
Khi có 1 bug xảy ra thì mọi người đều nghĩ là cần phải đọc kỹ specs hơn. Nhưng như thế nào là đọc kỹ specs, kỹ đến mức độ nào? Việc đọc kỹ specs này có loại trừ 100% khả năng xảy ra bug đó không?
Vậy làm thế nào để viết cụ thể hành động đề xuất?
Đó là bạn cần phải biết được nguyên nhân gốc rễ của vấn đề
Bài toán
Ví dụ: Dev làm thêm 1 chức năng là login 10 lần bị fail liên tiếp thì sẽ khoá tài khoản.
Nhưng khi làm thì gây ra 1 bug ảnh hưởng đến chức năng đăng ký, khi đăng ký xong thì không login được.
Vậy bài học kinh nghiệm ở đây là gì? Cần đọc kỹ specs?
Cùng xem xét vấn đề này một cách toàn diện nhé.
Phân tích vấn đề
Trong dự án này, Khi đăng ký xong thì sẽ default là status = enable (tức là account active luôn sau khi đăng ký, status có type là boolean).
Nhưng khi thực hiện chức năng lock, tài khoản thì cần phải thêm 1 trạng thái “lock” nữa vào trường status.
Nhưng status hiện tại là boolean không thể lưu được 3 trạng thái: “disabled”, “enable”, và “lock” được. Do đó cần phải thay đổi status từ kiểu boolean thành tiny int.
Khi thực hiện thay đổi từ kiểu boolean thành tiny int thì lại setting status default là 0.
Do đó khi đăng ký xong thì không login được do status default là 0 (disabled).
Nguyên nhân gốc rễ nhìn từ hướng dev
Nguyên nhân gốc rễ nhìn từ hướng dev: Khi thay đổi code cũ nhưng không tìm hiểu các xử lý phía trong code cũ. Cụ thể là không xem xét kỹ chỗ code mà migrate ra trường status xem nó default là bằng mấy. Mà đã set default của nó = 0.
Hành động đề xuất:
+ Tìm hiểu các xử lý liên quan đến chỗ code mình sửa. Cụ thể là khi sửa trường status thì cần check xem status lúc trước đang defaut là = mấy? Sau khi thay đổi kiểu thì phải set default giống với giá trị trước đó, tức là = 1
+Vậy làm thế nào để check được là mình đã tìm hiểu, tất cả những chỗ liên quan đến phần mình sửa? Đó là Search toàn bộ với keyword là status. Kiểm tra những logic liên quan đến trường mình sửa. Đó là 1 cách chắc chắn nhất nhưng sẽ tốn khá nhiều thời gian của bạn.
+Không tự ý làm bất cứ cái gì mà trong khi không confirm. Ở đây tại sao lại set giá trị default là 0? Specs không có yêu cầu thì cần phải hỏi lại, chỗ này là set giá trị default là mấy rồi mới được làm. Mỗi sự tự thay đổi nhỏ có thể làm ảnh hưởng lớn đến chất lượng dự án.
Thử đọc kỹ specs để giải quyết vấn đề xem…
Thử giải quyết theo hướng Đọc kỹ specs ở đây sẽ không biết kỹ đến mức độ nào?
Bạn đọc specs chức năng login? Chắc chắn nó sẽ không ghi default của trường status có giá trị là bao nhiêu. Do đó bạn đọc chức năng login cũng khó tránh khỏi bug này!
Chỉ có chức năng nào mà tạo ra giá trị status, mới có specs liên quan đến gía trị default của status.
Tạo ra thì chỉ liên quan đến đăng ký user? Vậy bạn xem chức năng đăng ký user, thấy nó có set default = . Bạn tự tin set default trong chức năng đăng ký user. Bạn cảm thấy chắc chắn là đúng rồi?
Nhưng không đâu backend cũng đăng ký được user mà!
Cái mà bạn xem chỉ là đăng ký user bên frontend thôi… Thế phải đọc cả đăng ký user bên backend nữa.
Đấy khi mà nói đọc kỹ specs thì không biết kỹ đến mức độ nào là đủ!
Kết
Ở cuối mỗi dự án sẽ đúc kết một số kinh nghiệm, giúp cho sợi dây kinh nghiệm dài ra.
Nhưng nếu bạn không biết cách viết thì bài học kinh nghiệm của dự án sẽ dài ra, nhưng bài học kinh nghiệm cho bạn sẽ không dài ra.
Lý do là cách bạn viết chưa đưa ra được cách xử lý cụ thể cho vấn đề, hay có thể bạn đang viết kinh nghiệm cho … người khác!
Cách bạn nhìn trực diện vào vấn đề và suy nghĩ nghiêm túc cho nó là 1 cách bạn cải thiện bản thân qua từng dự án một nhé.
Tác giả: Đặng Đình Diện
