Bài này khá hay, các bạn dev nên đọc qua. Có thể thông tin không có gì mới nhưng vài chi tiết người Nhật nghĩ hơi khác. Các bạn đọc bài rồi tham khảo nhé.
Nguyên tắc đọc thì mình có chia sẻ trong bài trước, đọc JP trước, không hiểu mới đá qua VN.
Khi fix bug thì tôi nghĩ rằng điều quan trọng nhất là phải document lại (ghi chép thành tài liệu). Tùy vào môi trường hoạt động của ứng dụng mà sẽ phát sinh ra những vấn đề khác nhau. Ngoài ra, cũng có thể do các yếu tố khác nhiều khi làm phát sinh việc fix bug ngoài ý muốn. Việc fix những lỗi phát sinh này dẫn đến tăng dần độ phức tạp cho ứng dụng, và làm chúng ta khó mà quản lý được sự thay đổi trong hệ thống. Lúc này ta hãy ghi chép thật kỹ thông tin từng dòng. Tôi nghĩ thói quen lưu giữ này là tối quan trọng.
Đã là lập trình viên thì ai cũng có kinh nghiệm fix bug cả. Bởi vì không có chương trình nào hoàn hảo. Lý do là chương trình nào cũng được tạo ra bởi con người, vậy nên có lẽ việc phát sinh lỗi là không tránh khỏi rồi nhỉ.
Bây giờ ta hãy suy nghĩ về việc làm sao để fix bug này không làm phát sinh ra bug khác. Tuy nhiên, trên thực tế sẽ phát sinh ra những bug mới ngoài dự tính, và có trường hợp xấu nhất mà ta sẽ phải chấp nhận đó là sẽ không thể xử được các lỗi đó.
Để tránh tình trạng này thì sẽ có những chú ý đặc biệt. Ta hãy thử suy nghĩ về những gì mà lập trình viên cần để tâm.
Trường hợp nâng cấp version phần mềm, ta hãy định hình đúng “kaihi bug code” – tức là mã số các bug mình chưa fix kịp hoặc chưa nghĩ ra cách làm sao fix, 1 dạng cài bom trong code có chủ đích và nằm trong phạm vi có thể xử lý được. Việc chỉnh sửa sau khi bàn giao sản phẩm (release) thì với những thay đổi qui mô lớn là rất khó, vậy nên có nhiều khi dev nhà ta giấu nhẹm bug đi. Nói như vậy thì việc cài bom khôn lanh kiểu đỏ sẽ đẩy được bug sang giai đoạn maintain làm mình dễ thở hơn. Vậy nên để cho chắc ăn thì hiển nhiên các bạn phải comment cho đầy đủ, rồi còn phải tạo danh sách các đoạn đã chỉnh sửa nếu có thể.
各コンポーネントの独立性を高める
Nâng cao tính độc lập cho các component ( cái này nằm trong nguyên tắc SOLID – các bạn google thêm)
Nếu tính liên kết giữa các component càng thấp thì việc chỉnh sửa code càng dễ dàng.
Nói suông vậy chắc hơi khó hiểu. Ví dụ nhé, ta có 2 biến “Global” vs “Public”, có nhiều module sử dụng nó, điều này dẫn đến khi có 1 thay đổi thì việc điều tra chỉnh sửa sẽ khá vất vả. Vì vậy không chỉ code sao cho dễ đọc – dễ hiểu, mà các lập trình viên còn phải nâng cao tính độc lập cho các component.
よいコードを参考にする
Tham khảo các code đẹp (kotex code hoặc clean code tùy bạn hiểu sao hiểu)
Đọc càng nhiều code thì sẽ hình thành nên ý thức code sao cho tốt.
Để lập trình viên có thể tạo ra những dòng code chất lượng ổn định và tuyệt hảo thì cần có know how (hiểu biết) rộng. Có nghĩa là nếu ta đọc nhiều thì chất lượng code của mình sẽ càng tốt lên.
Trước khi sửa code chúng ta nên tìm hiểu thật kỹ mấu chốt vấn đề là gì.
Có lẽ đây là điều hết sức bình thường nhưng trên thực tế việc tiến hành giải quyết vấn đề mà không đánh đúng trọng tâm thì không hiếm. Nếu chỉ dựa vào hiện tượng ta nhìn thấy, sau khi sửa xong có thể sẽ còn tồn động những case khác mà không hề hay biết.
Vì nhiều lý do mà cũng có trường hợp phải tiến hành các chỉnh sửa mang tính chữa cháy. Đối với case này, ta phải ghi chép hay comment lại thật đầy đủ.
Đây là điều nhắn nhủ đặc biệt gửi đến các lập trình viên khi fix bug giai đoạn sau khi đã release sản phẩm. Vậy nên đừng chống chế kiểu “em không đủ thời gian test”. Hay “em đã fix được cái đó rồi mà”. Trong khi bug vẫn chưa giải quyết triệt để thì trách nhiệm cuối cùng cũng thuộc về lập trình viên (số khổ).
Việc test lại sản phẩm sau khi fix bug, không chỉ chăm chăm test cái bug đó thôi mà phải coi cho rộng, xem nó có ảnh hưởng đến những phần khác hay không. Vậy nên cần phải tạo tài liệu tuần tự test confirm. Để khi xem tài liệu có thể dễ dàng phát hiện ra được thiếu sót mà test bổ sung.
Quan trọng nhất trong việc fix bug theo tôi chính là việc phải ghi chép lại toàn bộ.
Những tài liệu này không chỉ file giải thích bug bằng câu chữ, mà còn gồm cả comment source code, loại database thông tin bug, phương pháp fix, và những thông tin liên quan khác. Việc fix bug khó khăn 1 phần cũng vì việc ghi chép thiếu tường minh (rõ ràng).
4 thoughts on “[IT読解]Bài 3 : Những chú ý đặc biệt khi fix bug”
sao không thấy bản dịch tiếng Việt nữa a?
Loading...
Sorry em, mấy hôm nay anh hơi bận. Giờ mới ngồi dịch đây 🙂
Loading...
Cảm ơn bài chia sẻ của a nhiều ak:D
E mạo muội có ý kiến 1 chỗ liên quan đến tiếng Việt và tiếng Nhật.
Đó là từ đối ứng. Không biết có phải a dịch từ từ 対応 ra không, nhưng e thấy mọi người làm cùng e cũng rất hay gọi chung từ 対応 là “đối ứng” (dùng luôn hán việt).E thì thấy từ này không thuần Việt cho lắm. Trong trường hợp nói như a ở trên là “Đối ứng khi phát sinh bug” thì sao không nói là ” Xử lý khi phát sinh bug” ạ.
Loading...
xử lý nó là từ 処理 em, ai cũng dùng vậy thì cứ dùng vậy cũng chả sao đâu, miễn hiểu là được, ngôn ngữ mà.
sao không thấy bản dịch tiếng Việt nữa a?
Sorry em, mấy hôm nay anh hơi bận. Giờ mới ngồi dịch đây 🙂
Cảm ơn bài chia sẻ của a nhiều ak:D
E mạo muội có ý kiến 1 chỗ liên quan đến tiếng Việt và tiếng Nhật.
Đó là từ đối ứng. Không biết có phải a dịch từ từ 対応 ra không, nhưng e thấy mọi người làm cùng e cũng rất hay gọi chung từ 対応 là “đối ứng” (dùng luôn hán việt).E thì thấy từ này không thuần Việt cho lắm. Trong trường hợp nói như a ở trên là “Đối ứng khi phát sinh bug” thì sao không nói là ” Xử lý khi phát sinh bug” ạ.
xử lý nó là từ 処理 em, ai cũng dùng vậy thì cứ dùng vậy cũng chả sao đâu, miễn hiểu là được, ngôn ngữ mà.