Làm thế nào để dành ít thời gian hơn cho việc gỡ lỗi? [đóng cửa]

Theo quy tắc Pareto, một lập trình viên chỉ dành 20% thời gian cho những thứ thực sự hữu ích.

Tôi dành 80% thời gian để gỡ lỗi, sửa chữa những thứ nhỏ nhặt để mọi thứ hoạt động.

Có cách nào để dành ít thời gian gỡ lỗi hơn không?

Mã trong Agda hoặc Coq . Khi mã của bạn biên dịch, nó sẽ hoạt động. Nếu quá khó, hãy chọn ngôn ngữ có hệ thống loại yếu hơn, ví dụ: Haskell hoặc F #.

Tuy nhiên, trong hầu hết các trường hợp, bạn sẽ có năng suất cao hơn khi dành 20% thời gian cho mã hóa và 80% cho thử nghiệm và gỡ lỗi. 100% một tuần là nhiều hơn 20% một giờ. Nếu gỡ lỗi là những gì bạn cần để hoàn thành công việc, hơn là gỡ lỗi không lãng phí thời gian và bạn không nên bận tâm đến việc "cải thiện" tỷ lệ này.

Kiểm tra đơn vị.

Sau khi tôi bắt đầu áp dụng thử nghiệm đơn vị, tôi thấy rằng mã tôi đã viết trở nên có cấu trúc tốt hơn. Sau đó, dễ dàng hơn để tránh và phát hiện lỗi. Tôi đã dành ít thời gian hơn để gỡ lỗi, nhưng nhiều thời gian hơn với bài kiểm tra đơn vị viết.

Tôi cũng nghĩ rằng thời gian đầu tư vào các bài kiểm tra đơn vị có lợi tức đầu tư tốt hơn sau đó gỡ lỗi. Sau một phiên gỡ lỗi tôi chỉ sửa mã. Lỗi tương tự có thể xuất hiện vài tuần sau đó và tôi phải gỡ lỗi một lần nữa. Nếu tôi viết một bài kiểm tra đơn vị, lỗi được ghi lại dưới dạng kiểm tra đơn vị và sau đó hoạt động như một bài kiểm tra hồi quy. Nếu lỗi xuất hiện trở lại, các bài kiểm tra đơn vị sẽ tiết lộ điều này cho tôi.

• Kiểm thử đơn vị, để bạn biết liệu mã của bạn có hoạt động ngay từ đầu không.
• Ít nhất một số lượng thiết kế trả trước, để bạn biết những gì bạn đang mã hóa.
• Đánh giá mã, bởi vì hai cái đầu tốt hơn một, và bốn mắt tốt hơn hai cái đầu. Chưa kể rằng thậm chí cố gắng giải thích mã của bạn cho người khác tiết lộ nhiều vấn đề.
• Kiểm soát phiên bản, để bạn có thể nhanh chóng cô lập những thay đổi có thể gây ra lỗi.
• Tái cấu trúc, để mã của bạn không biến thành một mớ hỗn độn khó hiểu.
• Đọc "Clean Code" của Robert C. Martin và làm những gì anh ấy nói với bạn. Bạn sẽ ngạc nhiên bởi kết quả.

Kiểm thử đơn vị sẽ giúp như hy vọng nếu bạn giới thiệu các lỗi chúng sẽ phá vỡ trước mã sản xuất của bạn - kiểm tra đơn vị được viết tốt cũng sẽ cho bạn biết chính xác những gì đã phá vỡ.

Điều đó sẽ giúp bạn có được hầu hết các cách, nhưng đối với 99,999% dự án, bạn vẫn sẽ cần gỡ lỗi mọi thứ theo thời gian. Điều tốt nhất để làm ở đây tôi tìm thấy là làm 4 việc:

1. sử dụng các loại không thay đổi bất cứ nơi nào có thể - nếu một cái gì đó có giá trị sai, bạn sẽ biết chính xác nơi cần tìm ngay lập tức (nơi nó đang được xây dựng).
2. thực thi các bất biến trong mã - nếu bạn biết một giá trị chắc chắn không được phép thì hãy kiểm tra nó và đưa ra một ngoại lệ trong các điểm nhập tới các phương thức và hàm tạo. Nếu bạn kết hợp điều này với các loại bất biến thì bạn cũng có thể bắt đầu đưa ra các giả định nhất định về những gì hợp lệ hay không.
3. đảm bảo bạn có đăng nhập đầy đủ - nhận được điều này sớm và nó sẽ cung cấp cho bạn nhiều thông tin quan trọng về thời điểm xảy ra sự cố. AOP hoạt động thực sự tốt ở đây. Đăng nhập như một suy nghĩ thường là một chút rác - hãy lấy nó sớm như là một phần của thiết lập dự án.
4. nếu cơ sở mã của bạn đủ lớn / phức tạp, hãy tránh sử dụng các nguyên hàm - ví dụ: có một loại gọi là 'Tuổi' thay vì chỉ sử dụng một int. Ban đầu có vẻ hơi vô nghĩa, nhưng có thể theo dõi tất cả việc sử dụng một cái gì đó ngay lập tức là một chiến thắng gỡ lỗi rất lớn.

80% của tôi là gỡ lỗi. Tôi đang sửa các lỗi đơn giản và cố gắng làm cho tất cả hoạt động.

Bắt đầu bằng cách viết bài kiểm tra đơn vị, và cố gắng có độ bao phủ càng cao càng tốt. Ai đó đã đề cập đến TDD, nhưng tôi sẽ đi với BDD .

Cuối cùng, rất có thể bạn sẽ dành 80% cho việc gỡ lỗi các lỗi phức tạp.

Làm thế nào để dành ít thời gian gỡ lỗi? Viết ít mã hơn.

Nghiêm túc, miễn là bạn viết mã, bạn sẽ cần gỡ lỗi nó. Các bài kiểm tra đơn vị, vv giúp ích rất nhiều, nhưng đừng nghĩ rằng bạn sẽ hoàn toàn loại bỏ nhu cầu về nó.

Hiểu những gì và tại sao trước khi bạn bắt đầu viết mã. Sau đó sử dụng một phương pháp nhất quán. Phương pháp nào bạn chọn không quan trọng bằng việc sử dụng phương pháp lặp lại nhất quán. Nếu bạn muốn có kết quả tốt, bạn cần phải làm tốt công việc và có "phương pháp cho sự điên rồ" là bước đầu tiên để có được những kết quả này. Khi bạn xác định các vấn đề, bạn có thể điều chỉnh phương pháp của mình khi cần thiết và theo thời gian, bạn sẽ cải thiện quy trình phát triển của mình và hy vọng sẽ có ít lỗi hơn và phát triển mới, có ý nghĩa hơn.

Cung cấp cho mã của bạn đọc cẩn thận trước khi bạn biên dịch nó. Một đọc rất cẩn thận cho cú pháp và chức năng. Nó có thể là thông tin đáng ngạc nhiên, và cũng là một chỉ số tốt nếu một phần của mã quá phức tạp.

Hầu hết các câu trả lời dường như tập trung vào cách giảm số lượng vấn đề bạn phải gỡ lỗi và điều đó rất có giá trị. Tuy nhiên, việc gỡ lỗi sẽ luôn luôn cần thiết vì vậy rất hữu ích khi xem xét các cách để nhanh hơn khi gỡ lỗi.

• Biết cách sử dụng phần mềm kiểm soát phiên bản của bạn.

  • Sử dụng các nhánh sẽ giúp bạn tách ra các khu vực phát triển và bạn sẽ có thể thấy khu vực phát triển nào có lỗi và khu vực nào không có lỗi.
  • Tìm hiểu cách sử dụng chia đôi trong VCS của bạn, Git đã tích hợp sẵn. Nếu bạn sử dụng một VCS khác không được chia đôi để tìm một công cụ hoạt động như git bisect nhưng cho VCS của bạn (tôi biết điều này tồn tại cho SVN và không nên quá khó để tạo cho các VCS khác). Điều này sẽ giúp bạn thu hẹp sự thay đổi mã đã đưa ra lỗi, điều này sẽ giúp biết được nơi để chỉ ra trình gỡ lỗi của bạn. Quá trình chia đôi này sẽ nhanh hơn nếu bạn có các bài kiểm tra lỗi và biết cam kết nào có thay đổi vi phạm sẽ hữu ích hơn nếu bạn thực hành các cam kết nguyên tử.

• Nâng cao hiểu biết của bạn về ngôn ngữ lập trình bạn sử dụng.

  • Đọc sách, blog và mã về ngôn ngữ lập trình.
  • Mỗi khi bạn sửa một lỗi, hãy chắc chắn rằng bạn hiểu kỹ lý do tại sao mã không hoạt động và tại sao sửa lỗi của bạn hoạt động. Theo thời gian, bạn sẽ học được nhiều vấn đề trong ngôn ngữ của mình, điều này sẽ giúp bạn tránh được các vấn đề của họ và phát hiện ra các triệu chứng của chúng nếu chúng xảy ra.

• Hãy logic

  • Đừng thay đổi nhiều thứ cùng một lúc nếu hành vi thay đổi bạn sẽ không biết thay đổi nào gây ra thay đổi hành vi.
  • Xác nhận giả định của bạn.

Thêm vào các bình luận cho Kiểm thử đơn vị nhưng nó chỉ thực sự tốt nếu mã của bạn đã được tách để hỗ trợ nó (ví dụ: MVC). Nếu bạn không thể triển khai MVC (hoặc tương tự) (dự án cũ), các bài kiểm tra đơn vị hoàn toàn không hoạt động đối với UI của bạn. Sau đó tôi sẽ thêm kiểm tra giao diện người dùng tự động (Kiểm tra giao diện người dùng được mã hóa của Microsoft, WaitN) vì điều này sẽ giảm lỗi trong phần mã đó của bạn.

Tôi cũng rất khuyên bạn nên chạy các công cụ phân tích tĩnh (ví dụ: Phân tích mã FxCop / Microsoft, Resharper, JustCode cho thế giới MS). Chúng có thể tìm thấy tất cả các loại vấn đề mã hóa phổ biến có thể làm giảm các tác vụ gỡ lỗi ngớ ngẩn và tập trung nhiều hơn vào việc gỡ lỗi logic kinh doanh.

Làm cho nó hoạt động, sau đó làm cho nó nhanh, sau đó làm cho nó đẹp. Hầu hết các lỗi đến từ tối ưu hóa sớm hoặc bao thanh toán lại tại các dòng mã hoàn toàn tốt. Nếu bạn đi theo hướng đối tượng, đừng lặp lại chính mình, hãy giữ nó đơn giản và luôn thực hiện kiểm tra độ chính xác của các phạm vi giá trị, đặc biệt nếu các phương thức của bạn vẫn hoạt động ở các ràng buộc. Nó sẽ không giúp bạn ít mắc lỗi hơn nhưng có thể sẽ giúp bạn phát hiện ra lỗi nhanh hơn và do đó việc gỡ lỗi mất ít thời gian hơn.

Gần đây tôi đã suy nghĩ rất nhiều về vấn đề này - câu trả lời đơn giản là hãy đọc Thiết kế của mọi thứ của Don Norman; Viết mã như bạn sẽ thiết kế một sản phẩm.

Để diễn giải, thiết kế tốt giảm thiểu lỗi. Điều đó có nghĩa là, một vài điều, hầu hết trong số đó bạn đã làm (mặc dù bạn có thể không biết chính xác tại sao ).

-Tên chức năng bằng trực giác. Điều này được chính thức gọi là khả năng chi trả. Đó là, một nút bấm được nhấn, một đòn bẩy sẽ được chuyển đổi, một tay cầm được kéo, v.v.

-Làm khó viết mã xấu. Kiểm tra đầu vào xấu và ném lỗi sớm hơn là muộn hơn, sử dụng các ứng dụng có sẵn khi thích hợp, v.v. Đây được gọi là các chức năng khóa.

-Sử dụng trừu tượng khi thích hợp. Trí nhớ ngắn hạn là yếu.

-Documentation rõ ràng là quan trọng, nhưng nó ít hiệu quả nhất trong việc đảm bảo mã được sử dụng đúng cách. Tóm lại, các sản phẩm được thiết kế tốt không cần bất kỳ tài liệu nào. (Cách rõ ràng nhất để thấy điều này là nhìn vào các ví dụ xấu: cụ thể là các cánh cửa có tay cầm mà bạn phải đẩy.)

-Unit tests. Chúng không thực sự ngăn ngừa lỗi, nhiều đến mức rõ ràng là lỗi ở đâu và cung cấp sự tỉnh táo.

Tôi chắc chắn rằng tôi còn thiếu nhiều nguyên tắc nữa, nhưng quan điểm là, hãy đọc về thiết kế cho lỗi.

Cách tốt nhất để giảm gỡ lỗi, IMO, là bằng cách tập trung và làm chậm khi mã hóa. Điều này buộc bạn phải nhìn thấy những sai lầm bạn có thể đã làm!

Mặc dù tôi hoàn toàn ủng hộ thử nghiệm đơn vị được đề xuất ở trên, TDD hoặc BDD sẽ có giá trị lớn vì trước tiên bạn cần nghĩ về vấn đề và giải pháp.

Nhưng cá nhân đối với tôi, dành vài phút chỉ để ngồi im lặng và suy nghĩ về vấn đề cũng như cách tiếp cận nó và bất kỳ sự ủng hộ nào với mỗi cách tiếp cận, làm nên điều kỳ diệu cho chất lượng mã của tôi và giúp tôi giải tỏa sự lộn xộn.

Đôi khi một nét vẽ nhanh trên một mảnh giấy giúp bạn nhìn thấy những mảnh ghép được kết nối lớn hơn.

Tôi viết mã tồi tệ nhất khi tôi chỉ lặn trong đầu và đập bàn phím. Một chút suy nghĩ và suy ngẫm tạo nên một thế giới khác biệt.

Tái bút Tôi có nghĩa là 5 có thể mười phút, không phải giờ viết một thông số lớn.

Một số câu trả lời tốt đã có, chỉ một số thực phẩm nữa mặc dù nghiện những gì người khác đã nói.

Học hỏi từ những sai lầm của bạn. Đừng tiếp tục làm những cái giống nhau nhiều lần.

Đảm bảo che các trường hợp cạnh khi lập trình - đó là những nơi thường xuyên có lỗi.

Hãy chú ý đến yêu cầu. Ngay cả khi nó hoạt động nhưng không làm những gì yêu cầu được chỉ định, đó là một lỗi.

Nhật ký ngoại lệ có thể là một trợ giúp thực sự khi có sự cố xảy ra sáu tháng kể từ bây giờ. Hãy có thói quen ghi lại các trường hợp ngoại lệ.

Hai suy nghĩ hàng đầu của tôi là 1) Viết mã tốt hơn sẽ thất bại khi bạn làm điều gì đó bất ngờ 2) Trở nên tốt hơn trong việc gỡ lỗi

Mã của tôi bị vấy bẩn

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

Bất cứ khi nào tôi thực thi đoạn mã đó, ngoại lệ bị ném khiến trình gỡ lỗi dừng lại, điều đó cho phép tôi viết mã trong các tính năng mới hoặc tránh các điều kiện thay vì nhầm lẫn về những gì đang xảy ra / có lỗi

Để trở nên tốt hơn trong việc gỡ lỗi lộn xộn với ngăn xếp cuộc gọi, điểm dừng (có điều kiện), cửa sổ ngay lập tức (còn được gọi là cửa sổ nhắc hoặc thay thế), biến 'xem' và bất cứ điều gì khác.