Cách cải thiện kiểm tra mã của riêng bạn [đã đóng]

Hôm nay tôi đã kiểm tra một thay đổi trên một số mã hóa ra hoàn toàn không hoạt động do một thứ khá ngu ngốc nhưng rất quan trọng. Tôi cảm thấy thực sự tồi tệ về nó và tôi hy vọng cuối cùng tôi cũng học được điều gì đó từ nó. Điều ngu ngốc là, tôi đã làm những điều này trước đây và tôi luôn tự nhủ, lần sau tôi sẽ không ngu ngốc như vậy ... Sau đó, nó lại xảy ra và tôi cảm thấy tồi tệ hơn về nó.

Tôi biết bạn nên giữ cằm và học hỏi từ những sai lầm của mình nhưng đây là điều: Tôi cố gắng cải thiện bản thân mình, tôi chỉ không thấy làm thế nào tôi có thể ngăn chặn những điều này xảy ra.

Vì vậy, bây giờ tôi đang hỏi các bạn: Bạn có cơ sở nhất định khi kiểm tra mã của mình không?

Viết kiểm tra trước khi bạn thực hiện thay đổi mã.

Nếu thay đổi được đề xuất của bạn là sửa lỗi, ban đầu hãy kiểm tra lỗi bằng cách chứng minh lỗi. Sau đó hãy chắc chắn rằng nó vượt qua sau khi bạn đã sửa lỗi. Nếu bạn viết bài kiểm tra sau đó và chỉ từng thấy nó vượt qua, bạn không thể chắc chắn rằng nó đã kiểm tra đúng lỗi ngay từ đầu.

Nếu thay đổi được đề xuất của bạn là thay đổi chức năng hiện có hoặc thêm một tính năng, hãy viết một số thử nghiệm để đảm bảo phạm vi bảo vệ tốt của khu vực mã bạn sẽ thay đổi. Hãy chắc chắn rằng các bài kiểm tra này vượt qua trước khi bạn bắt đầu thay đổi mã và vẫn vượt qua khi bạn hoàn thành.

Đừng quên kiểm tra các trường hợp cạnh! Rất nhiều lỗi là do hành động phổ biến nhất đã được thử nghiệm nhưng không phải là hành động ít phổ biến hơn.

Thực hiện theo các lời khuyên kỹ thuật trong các câu trả lời theo định hướng kỹ thuật; đó là thứ tốt Câu trả lời của tôi là nhiều hơn về thái độ.

Cảm thấy tồi tệ khi phạm phải sai lầm mà mọi nhà phát triển đôi khi mắc phải chỉ là vô lý và không giúp bạn không mắc phải sai lầm đó trong tương lai. Trong khi bạn ngồi đó cảm thấy tồi tệ, bản dựng vẫn bị hỏng, bạn biết không? Và sau đó, công việc của bạn là tránh những sai lầm, điều mà tôi biết làm cho việc ra khỏi giường vào buổi sáng là một cuộc phiêu lưu thú vị mỗi ngày, phải không?

Tôi đã nghe nói về các công ty nơi kiểm tra mã bị hỏng là nguyên nhân cho sự xấu hổ công khai. Tôi thậm chí không thể có được suy nghĩ của mình về kiểu suy nghĩ vênh váo, thiếu niên, thiếu niên sẽ dẫn đến hành vi như vậy. Hầu như không thể có bất kỳ phản ứng nào hiệu quả hơn cho một trưởng nhóm hoặc người quản lý để làm.

Vì vậy, đừng tự đánh mình. Tất cả chúng ta đã làm điều đó. Tôi có thể phải trả giá nửa ngày mỗi tuần cho những sai lầm ngớ ngẩn và tôi đã làm điều này trong một thời gian dài. Đó là những gì nó trông giống như viết mã - bạn liên tục chống lại những gì có vẻ như bất cập của chính bạn. Điều làm cho một chuyên gia trở thành một chuyên gia không phải là một phẩm chất huyền thoại của việc không bao giờ mắc lỗi (bao gồm cả những lỗi lớn đôi khi), nhưng cách họ TRẢ LỜI những sai lầm mà họ mắc phải.

Nếu có một câu thần chú tôi có thể thấm nhuần trong mọi nhà phát triển mà tôi làm việc cùng, thì đó là: Bạn không phải là mã của bạn . Bạn viết mã. Bạn viết nó tốt và hiệu quả như bạn có thể. Sau đó bạn về nhà. Nếu bạn đánh đồng giá trị hoặc giá trị bản thân với tư cách là một người với chất lượng mã của bạn, thì bạn đang bỏ lỡ con thuyền về con người thực sự của bạn.

Một thực hành kiểm thử quan trọng khác là viết bài kiểm tra và đảm bảo rằng nó thất bại ít nhất một lần TRƯỚC KHI viết mã. Thật dễ dàng để làm rối và viết một bài kiểm tra tautology mà vô tình không kiểm tra tình trạng bạn đang kiểm tra. Đảm bảo sai gần như (và đôi khi tệ hơn) không có đảm bảo.

Một ý tưởng tôi đã sử dụng theo thời gian là thế này,

tạo một nhánh và phá mã của bạn, chạy thử nghiệm và đảm bảo rằng thử nghiệm bắt được lỗi.

Bạn có một số nền tảng nhất định khi kiểm tra mã của bạn?

• Luôn luôn kiểm tra mã của bạn và cố gắng đạt mức độ bao phủ cao nhất có thể.

Một số điểm chung bổ sung:

• đầu tư một chút thời gian vào thiết kế và lập kế hoạch trước khi bắt đầu viết mã
• cấu trúc lại mã của bạn!