Ngừng lãng phí thời gian vào các lỗi mã hóa. Sửa ngay.

Tôi vẫn còn nhớ cảm giác đó. Một dự án sạch có thể trở thành một mớ hỗn độn trong vài giây khi một lỗi mã hóa nhỏ làm gián đoạn toàn bộ quy trình. Trang ngừng tải. Ứng dụng gặp sự cố. Một nút không làm gì cả. Lỗi này có thể trông nhỏ bé nhưng lại đánh cắp sự tập trung và làm mọi thứ chậm lại. Khi điều đó xảy ra, tôi không cố đoán. Tôi chậm lại, nhìn mã bằng con mắt rõ ràng và sửa nguồn từng bước một. 1. Tôi đọc thông báo lỗi trước khi chạm vào mã Nhiều người bỏ qua thông báo và chuyển thẳng sang chỉnh sửa. Tôi cũng đã từng làm điều đó. Điều đó thường khiến mọi việc trở nên tồi tệ hơn. Một thông báo lỗi tốt đã đưa ra manh mối. Nó có thể trỏ đến tên tệp, số dòng hoặc giá trị không hợp lệ. Nếu thông báo cho biết một biến không được xác định, tôi sẽ kiểm tra tên đó trước bất kỳ điều gì khác. Nếu thông báo không tìm thấy chức năng, tôi sẽ tìm lỗi chính tả hoặc nội dung nhập bị thiếu. Một ví dụ nhỏ: Có lần tôi đã dành 20 phút để tìm một lỗi trong JavaScript. Trang liên tục bị lỗi và tôi nghĩ vấn đề nằm ở lệnh gọi API của tôi. Vấn đề thực sự là một lỗi đánh máy đơn giản. Tôi đã viết userNmae thay vì userName. Thông báo lỗi đã gợi ý vấn đề. Tôi chỉ bỏ qua nó lúc đầu. Sai lầm đó đã dạy tôi một quy tắc đơn giản: đọc tin nhắn rồi hành động. 2. Tôi kiểm tra thay đổi cuối cùng mà tôi đã thực hiện Hầu hết các lỗi xuất hiện ngay sau khi thay đổi. Một dòng mã mới. Một tập tin được đổi tên. Một tình trạng có vẻ vô hại. Tôi tự hỏi: “Tôi đã chạm vào cái gì trước khi chuyện này xảy ra?” Câu hỏi đó giúp tôi tiết kiệm rất nhiều thời gian. Nếu mã đã hoạt động trước đó, tôi sẽ so sánh phiên bản cũ với phiên bản mới. Tôi tìm kiếm: - đã thay đổi tên biến - thiếu dấu ngoặc - dấu ngoặc kép bị hỏng - đường dẫn tệp sai - logic không còn phù hợp với mục tiêu Bước này hoạt động tốt vì nó thu hẹp tìm kiếm. Tôi không cần phải kiểm tra từng dòng trong dự án. Tôi chỉ cần tập trung vào phần đã thay đổi. 3. Tôi kiểm tra từng phần nhỏ chứ không phải toàn bộ hệ thống Các khối mã lớn có thể che giấu vấn đề thực sự. Khi tôi chia một vấn đề thành các phần nhỏ hơn, tôi có thể thấy lỗi bắt đầu từ đâu. Tôi kiểm tra một chức năng. Tôi đăng nhập một giá trị. Tôi kiểm tra một yêu cầu. Điều đó mang lại cho tôi một cái nhìn rõ ràng hơn. Ví dụ: nếu một biểu mẫu không được gửi, tôi không cho rằng toàn bộ biểu mẫu đã bị hỏng. Tôi kiểm tra giá trị đầu vào trước. Sau đó tôi kiểm tra trình xử lý gửi. Sau đó tôi xem xét yêu cầu mạng. Rất thường xuyên, lỗi nằm ở một nơi nhỏ. Cách tiếp cận này ban đầu có vẻ chậm hơn nhưng thường tiết kiệm được nhiều thời gian hơn. Tôi ngừng đuổi theo bóng tối. 4. Tôi sử dụng nhật ký như một chiếc đèn pin Nhật ký trên bảng điều khiển rất đơn giản nhưng lại giúp ích rất nhiều. Tôi in các giá trị tại các điểm chính để có thể xem mã đang làm gì. Tôi sử dụng chúng để kiểm tra: - dữ liệu nào được đưa vào - những thay đổi nào sau khi một hàm chạy - những gì rời khỏi thành phần hoặc điểm cuối - nơi giá trị dừng khớp với kế hoạch của tôi Một trường hợp thực tế từ công việc của tôi: Tôi đang trợ giúp với một ứng dụng React hiển thị thẻ người dùng trống. Cuộc gọi dữ liệu đã thành công nên nhóm cho rằng vấn đề nằm ở API. Tôi đã thêm một vài nhật ký và nhận thấy rằng hình dạng phản hồi khác với những gì giao diện người dùng mong đợi. Ứng dụng muốn data.user.name nhưng API đã gửi data.profile.name. Một sự không khớp nhỏ, một màn hình trống. Nhật ký đã biến một lỗi mơ hồ thành một bản sửa lỗi rõ ràng. 5. Tôi so sánh kết quả mong đợi với kết quả thực tế Thói quen này giúp tôi luôn vững vàng. Tôi viết ra những gì tôi mong đợi mã sẽ làm, sau đó tôi kiểm tra xem nó thực sự làm được những gì. Khoảng cách đó thường bộc lộ sai lầm. Nếu tôi mong đợi một lần nhấp vào nút để mở một phương thức, tôi sẽ kiểm tra ba điều sau: - sự kiện nhấp chuột có kích hoạt không - cập nhật trạng thái - phương thức có nhận được trạng thái mới không. Nếu một phần không thành công, tôi biết phải tìm ở đâu tiếp theo. Tôi không coi con bọ như một cuốn tiểu thuyết bí ẩn. Tôi coi nó như một trình tự. 6. Tôi cũng kiểm tra những thứ dễ dàng Một số lỗi ẩn trong tầm nhìn rõ ràng. Thiếu dấu phẩy. Một khoảng trống bên trong đường dẫn tập tin. Khóa API sai trong thiết lập cục bộ. Sự cố bộ đệm của trình duyệt. Những vấn đề này có thể lãng phí rất nhiều năng lượng vì chúng trông quá đơn giản để có thể trở thành nguyên nhân. Tôi đã từng sửa lỗi tải lên hình ảnh bị hỏng bằng cách thay đổi một đường dẫn thư mục. Bản thân mã đã ổn. Đường dẫn trỏ đến thư mục sai sau khi triển khai. Tôi đã kiểm tra logic hai lần nhưng câu trả lời nằm ở tên tệp. Kiểm tra đơn giản không phải là kiểm tra nhỏ. Họ là một phần của công việc. 7. Tôi giữ một danh sách ngắn các nguyên nhân phổ biến Theo thời gian, tôi nhận thấy những loại lỗi tương tự xuất hiện lặp đi lặp lại. Dưới đây là những lỗi tôi chú ý nhiều nhất: - lỗi chính tả trong tên biến hoặc hàm - nhập thiếu - kiểu dữ liệu sai - logic vòng lặp sai lệch - đường dẫn tệp sai - phản hồi API không khớp - trạng thái không cập nhật khi mong đợi - điều kiện được viết sai cách Tôi không chỉ dựa vào bộ nhớ. Tôi giữ danh sách này gần nơi làm việc của mình. Nó giúp tôi giữ bình tĩnh khi mã bắt đầu hoạt động. 8. Tôi yêu cầu trợ giúp sau khi kiểm tra những điều cơ bản. Tôi không coi trợ giúp là phương sách cuối cùng. Tôi coi đó là một bước đi thông minh sau khi loại trừ những nguyên nhân đơn giản. Nếu bế tắc quá lâu, tôi sẽ đưa mã cho đồng đội hoặc so sánh với các tài liệu đáng tin cậy. Một đôi mắt mới có thể phát hiện ra những gì tôi đã bỏ lỡ trong vài phút. Điều đó nói rằng, tôi cố gắng đưa ra một câu hỏi rõ ràng. Tôi giải thích những gì tôi mong đợi, những gì tôi đã thấy và những gì tôi đã kiểm tra. Điều đó làm cho cuộc trò chuyện trở nên hữu ích. Nó cũng tôn trọng thời gian của mọi người. Tôi tin rằng việc sửa lỗi tốt là một kỹ năng chứ không phải là sự phỏng đoán. Cách khắc phục nhanh nhất không phải lúc nào cũng là cách thông minh nhất. Nó thường được xây dựng dựa trên các bước bình tĩnh, kiểm tra rõ ràng và đọc mã một cách trung thực. Khi làm việc theo cách này, tôi ít lãng phí năng lượng hơn, ít mắc lỗi lặp lại hơn và học được nhiều điều hơn từ mỗi lỗi. Nếu mã của bạn bị hỏng hôm nay, hãy bắt đầu từ việc nhỏ. Đọc tin nhắn. Kiểm tra thay đổi cuối cùng. Kiểm tra từng phần một. Câu trả lời thường gần hơn vẻ ngoài của nó.

Tôi biết tiếng ồn của lỗi cảm thấy như thế nào. Một lỗi nhỏ xuất hiện và toàn bộ quy trình làm việc bị chậm lại. Một nút ngừng hoạt động. Một biểu mẫu từ chối đầu vào hợp lệ. Một báo cáo hiển thị sai số. Tôi đã chứng kiến ​​nhiều đội mất tập trung vì họ cứ theo đuổi cùng một vấn đề từ những góc độ khác nhau. Điều thường gây tổn thương nhất không phải là lỗi. Đó là sự qua lại. Nhà phát triển đoán. Người kiểm tra kiểm tra lại. Nhóm hỗ trợ nghe khiếu nại. Người dùng chờ đợi. Mọi người đều bận rộn, nhưng vấn đề vẫn còn bỏ ngỏ. Quan điểm của tôi rất đơn giản: lỗi không nên kiểm soát ngày làm việc. Tôi tập trung vào quy trình sửa lỗi rõ ràng để giúp các nhóm di chuyển ít căng thẳng hơn và ít vấn đề lặp lại hơn. Tôi bắt đầu với đường dẫn người dùng. Tôi hỏi một câu: lỗi xuất hiện ở đâu đối với người sử dụng sản phẩm? Biểu mẫu thanh toán có thể hoạt động trên máy tính để bàn và không hoạt động trên thiết bị di động. Trang đăng nhập có thể chấp nhận đúng mật khẩu nhưng vẫn chặn quyền truy cập do sự cố trường ẩn. Trang tổng quan có thể tải nhưng số khóa có thể không cập nhật sau khi làm mới. Đây là những vấn đề khiến bạn tốn nhiều công sức vì chúng tiềm ẩn trong quá trình sử dụng thông thường. Sau đó tôi thu hẹp cò súng. Tôi kiểm tra trình duyệt, thiết bị, loại đầu vào, vai trò người dùng và trạng thái trang. Tôi so sánh những gì hiệu quả với những gì phá vỡ. Bước này tiết kiệm rất nhiều phỏng đoán. Một nhóm thương mại điện tử nhỏ từng gặp phải vấn đề thanh toán chỉ xuất hiện trên một trình duyệt Android. Nút thanh toán có vẻ ổn nhưng biểu mẫu giao hàng lại gặp sự cố xác thực im lặng. Hộp thư hỗ trợ của họ chứa đầy thông báo “Tôi không thể thanh toán”. Sau khi họ truy tìm vấn đề theo một quy tắc trường, việc khắc phục đã diễn ra nhanh chóng. Phần khó khăn nhất là tìm ra nguyên nhân thực sự. Câu chuyện đó là phổ biến. Nhiều vấn đề về lỗi phát triển do mọi người xử lý triệu chứng và bỏ qua nguồn gốc. Quy trình của tôi vẫn thực tế: - Tái tạo sự cố trong một thiết lập rõ ràng - Viết ra các bước chính xác kích hoạt sự cố đó - Kiểm tra nhật ký, lỗi và hành vi của trình duyệt - So sánh đường dẫn hoạt động và đường dẫn bị hỏng - Khắc phục từng nguyên nhân cốt lõi tại một thời điểm - Kiểm tra lại đường dẫn tương tự sau khi khắc phục - Ghi lại một ghi chú ngắn để vấn đề tương tự không quay trở lại Tôi thích cách tiếp cận này vì nó giúp công việc trở nên đơn giản. Không có tiếng ồn. Không có vòng phỏng đoán. Tôi cũng chú ý đến việc giao tiếp. Nếu tôi tìm thấy một lỗi, tôi mô tả nó bằng những từ ngữ đơn giản: người dùng đã làm gì hệ thống đã làm điều gì đáng lẽ phải xảy ra điều gì đã xảy ra thay vào đó Thói quen nhỏ đó giúp nhóm phát triển nhanh hơn. Một ghi chú lỗi rõ ràng có thể giúp nhà phát triển không phải đọc 10 thông báo và 5 ảnh chụp màn hình chỉ để hiểu vấn đề. Tôi cũng nghĩ rằng việc phòng ngừa là quan trọng. Một danh sách kiểm tra tốt trước khi phát hành có thể phát hiện được những vấn đề nhỏ trước khi người dùng nhìn thấy chúng. Tôi kiểm tra biểu mẫu, trường hợp khó khăn, thông báo lỗi, hiển thị trên thiết bị di động, liên kết bị hỏng và hành vi tải cơ bản. Tôi tìm những nơi mà người dùng có thể nhấp, nhập, làm mới, thoát ra hoặc chuyển đổi màn hình. Đó là nơi ẩn náu của nhiều lỗi. Ý kiến ​​của tôi rất đơn giản: một sản phẩm sẽ đáng tin cậy hơn khi nhóm tôn trọng những kiểm tra nhỏ này. Tác phẩm không cần kịch tính. Nó cần sự nhất quán. Nếu lỗi tiếp tục khiến nhóm của bạn đi chệch hướng, tôi sẽ bắt đầu với đường dẫn người dùng, trình kích hoạt và ghi chú. Chỉ điều đó thôi cũng có thể cắt giảm rất nhiều nỗ lực lãng phí. Nó cũng làm cho lần sửa lỗi tiếp theo dễ dàng hơn vì nhóm không bắt đầu từ con số 0. Tôi thích phần mềm có cảm giác ổn định. Người dùng cũng cảm nhận được điều đó. Khi hệ thống hoạt động theo cách mọi người mong đợi, yêu cầu hỗ trợ giảm xuống, nhóm giữ bình tĩnh hơn và sản phẩm nhận được nhiều sự tin cậy hơn sau mỗi lần sửa chữa rõ ràng.

Tôi từng nghĩ clean code là một sự lựa chọn về phong cách. Tôi không thấy nó theo cách đó nữa. Khi mã trở nên lộn xộn, mọi thay đổi nhỏ sẽ biến thành việc tìm kiếm các dấu ngoặc bị thiếu, logic ẩn và các bản sửa lỗi cũ mà không ai nhớ. Nỗi đau xuất hiện trong công việc hàng ngày. Một đồng đội yêu cầu một bản cập nhật đơn giản và nhiệm vụ này trở thành công việc sửa chữa chậm chạp. Một lỗi lọt vào. Quá trình xem xét mất quá nhiều thời gian vì người đọc phải đoán ý định. Tôi quan tâm đến mã sạch vì nó bảo vệ thời gian và sự tin cậy. Tôi muốn mã mà người khác có thể đọc mà không cần đoán. Tôi muốn mã kể câu chuyện về tính năng từ trên xuống dưới. Tôi cũng muốn ít bất ngờ hơn khi sản phẩm thay đổi. Đây là cách tôi xử lý: - Tôi kể tên mọi việc như thể tôi đang nói chuyện với đồng đội. Nếu một biến chứa số lượng mặt hàng trong giỏ hàng, tôi gọi nó là cartItemCount. Tôi không che giấu ý nghĩa đằng sau những lối tắt mà chỉ có ý nghĩa đối với tôi. - Tôi giữ một chức năng trong một công việc. Khó có thể tin cậy một chức năng dài kiểm tra thanh toán, tính thuế, gửi thư và ghi nhật ký. Tôi chia nó ra. Mỗi phần đều có mục đích rõ ràng. - Tôi xóa mã không còn phù hợp với sản phẩm. Logic cũ có thể trông vô hại. Nó thường tạo ra sự nghi ngờ. Nếu không còn quy tắc nào, tôi sẽ loại bỏ nhánh cũ để sau này không ai phải kiểm tra đường dẫn ma. - Tôi viết bình luận vì lý do chứ không phải vì mã rõ ràng. Tôi không giải thích những gì một dòng đã nói. Tôi giải thích tại sao có sự lựa chọn. Điều đó giúp ích khi các quy tắc kinh doanh thay đổi. - Tôi kiểm tra những phần có thể gãy. Tôi đã thấy một trang thanh toán không thành công vì quy tắc phiếu giảm giá và quy tắc vận chuyển sử dụng cùng một trường theo những cách khác nhau. Một bộ thử nghiệm nhỏ đã phát hiện ra vấn đề trước khi có nhiều người dùng hơn tiếp cận nó. Sau đó, nhóm có thể thay đổi mã mà bớt sợ hãi hơn. Tôi cũng đọc mã của riêng mình như một người lạ. Thói quen đó đã thay đổi công việc của tôi. Nếu tôi cần tạm dừng và giải mã một khối, tôi biết mã đang yêu cầu hình dạng rõ ràng hơn. Tôi viết lại nó trước khi người tiếp theo trả chi phí. Mã sạch không có nghĩa là làm cho mọi tệp trông hoàn hảo. Tôi quan tâm nhiều hơn đến sự rõ ràng hơn là đánh bóng. Một cấu trúc đơn giản giúp tôi di chuyển nhanh hơn sau này. Một lối tắt lộn xộn có thể tiết kiệm được mười phút bây giờ, sau đó mất một giờ cho lần thay đổi tiếp theo. Tôi đã cảm thấy giao dịch đó nhiều lần. Quy tắc của tôi rất đơn giản. Nếu một đồng đội mở tập tin của tôi, tôi muốn bước đi tiếp theo diễn ra tự nhiên mà không cần phải đoán. Tư duy đó giúp công việc ổn định. Nó cũng giúp việc xem xét mã dễ dàng hơn, sửa lỗi nhẹ nhàng hơn và tính năng mới hoạt động nhẹ nhàng hơn. Mã sạch bắt đầu ngay bây giờ, không phải sau lần phát hành tiếp theo và không phải sau lần chạy nước rút dọn dẹp tiếp theo. Tôi bắt đầu với một chức năng, một tên, một bài kiểm tra, một sửa chữa nhỏ. Điều đó là đủ để thay đổi hình dạng của một cơ sở mã. Bạn muốn tìm hiểu thêm về các xu hướng và giải pháp của ngành? Liên hệ với wzsanying: 780877550@qq.com/WhatsApp 13858841904.

Robert C Martin 2008 Mã sạch Sổ tay về tay nghề phần mềm linh hoạt Andrew Hunt và David Thomas 1999 Lập trình viên thực dụng từ người hành trình đến bậc thầy Martin Fowler Tái cấu trúc năm 2018 Cải tiến thiết kế mã hiện có John Sonmez 2015 Hướng dẫn nghề nghiệp hoàn chỉnh của nhà phát triển phần mềm Kent Beck 2002 Phát triển dựa trên thử nghiệm bằng ví dụ Steve McConnell 2004 Hoàn thành mã Một cuốn sổ tay thực hành về xây dựng phần mềm