79: Thông thạo dụng cụ analysis code

Giá trị của testing đã bước vào đời của các nhà phát triển từ những giai đoạn đầu tiên. Trong một vài năm gần đây sự phát triển mạnh mẽ của unit testing, test-driven và những phương thức nhanh chóng đã cho thấy sự quan tâm đáng kinh ngạc đến việc kiểm tra qua tất cả các giai đoạn của chu trình phát triển sản phẩm. Tuy nhiên, testing là một trong những công cụ để bạn có thể nâng cao chất lượng code.

Trở lại dòng chảy của thời gian, khi mà C vẫn còn là một hiện tượng mới, thời gian mà CPU và bất kì phương tiện lưu trữ nào hoạt động cũng rất chậm. Phiên bản compiler đầu tiên của ngôn ngữ C đã không quan tâm đến vấn đề này và cắt giảm bớt số lượng code đi qua bằng cách loại bỏ một số analyses. Điều này có nghĩa là compiler chỉ kiểm tra một phần nhỏ của đoạn bug có thể được phát hiện trong thời gian biên dịch. Để khắc phục điều này, Stephen Johnson đã tạo ra một ứng dụng gọi là lint — cái mà xoá bỏ fluff khỏi code của bạn — nó hoạt động bằng cách cài đặt tĩnh một số analyses mà C compiler đã xoá bỏ. Công cụ static analysis, tuy nhiên, đã nhận được nhiều tiếng tăm vì những cảnh báo giả và những cảnh báo về những quy ước mà không phải lúc nào cũng nhất thiết để làm theo.

Mặt bằng chung hiện nay của các ngôn ngữ, compilers, và công cụ analysis phức tạp. Thời gian đọc ghi của CPU và bộ cũng trở nên nhanh hơn, chính vì thế compiler có thể cố gắng kiểm tra thêm một số lỗi. Hầu hết các ngôn ngữ đều tự hào khi có ít nhất một công cụ mà có thể kiểm tra các lỗi do sai cú pháp, lỗi gotchas, và đôi khi khéo léo chặn các lỗi thường rất khó để bắt gặp, như là pointer null dereferences. Những công cụ tinh vi hơn, như là Splint của C hoặc là Pylint của Python, có thể được tuỳ chỉnh, điều này giúp bạn có thể chọn những lỗi hoặc cảnh báo nào mà Compiler phát hiện bằng một file thiết lập, hay bằng dòng lệnh, hoặc điều chỉnh trong IDE của bạn. Splint còn có thể để bạn ghi chú code của bạn bằng comment giúp bạn có gợi ý về cách hoạt động của chương trình.

Nếu tất cả những điều trên sai, bạn nên tìm những lỗi đơn giản hay những xung đột các chuẩn mực mà chúng không thể bị phát hiện bởi compiler, IDE, hoặc công cụ lints, vậy thì bạn phải tự kiểm tra lấy thôi. Việc này không quá khó như bạn nghĩ đâu. Hầu hết các ngôn ngữ, đặc biệt là những ngôn ngữ mang danh dynamic, thường sở hữu hệ thống ngôn ngữ và công cụ của compiler như một phần của thư viện tiêu chuẩn. Đó là một điều đáng giá khi bạn có thể biết những góc khuất của bộ thư viện tiêu chuẩn được dùng bởi các nhóm nhà phát triển của ngôn ngữ mà bạn đang dùng, thường thì những điều này chứa những “viên ngọc quý” cho static analysis và dynamic testing. Ví dụ, thư viện chuẩn của Python có một disassembler cái mà sẽ cho bạn biết bytecode dùng để compile code hoặc đối tượng code. Chức năng này dường bị quên lãng bởi những nhà thiết kế compiler trong đội ngũ phát triển Python, tuy nhiên đây lại là một chức năng cực kỳ hữu ích không thể thiếu trong những tình huống hằng ngày. Một điều nữa mà thư viện này có thể tách rời là sự truy stack của bạn, giúp bạn theo dõi một cách chính xác bytecode nào là nguyên nhân của các ngoại lệ ⚠ cuối cùng không bị phát hiện.

Chính vì vậy đừng để testing là việc cuối cùng của việc bảo quản chất lượng của sản phẩm của bạn — hãy thông thạo các công cụ analysis và đừng sợ khi thực hiện điều đó một mình.