Làm thế nào để bạn lập trình hiệu quả khi mất nhiều thời gian để kiểm tra mã của bạn?

Quy trình làm việc của tôi luôn là viết một bước hợp lý và sau đó chạy chương trình và kiểm tra đầu ra. Quá trình này đã phục vụ tôi rất tốt cho các bài tập trong trường đại học. Tuy nhiên, khi tôi phát triển nhiều hơn, thường có lúc chỉ cần biên dịch và chạy mã của bạn mất từ ​​1 đến 2 phút. Các ví dụ bao gồm tải chương trình lên vi điều khiển, yêu cầu tương tác với máy chủ bên ngoài và không thể thực hiện tự động hóa do xác thực, kiến ​​trúc phần mềm hoặc độ phức tạp.

Các loại nhiệm vụ này rất không phù hợp với cách tôi thường lập trình và tôi gặp khó khăn khi viết mã hiệu quả. Tôi thường mắc rất nhiều lỗi cú pháp và lỗi logic, hầu hết tôi dễ dàng bắt gặp bằng cách kiểm tra. Tuy nhiên, với thời gian chờ đợi lâu như vậy, phương pháp này quá tốn thời gian.

Trước hết, bất kỳ loại gỡ lỗi tương tác là tuyệt vời. Bạn muốn điều đó trong bộ công cụ của bạn, bởi vì nếu chưa, thì một ngày nào đó bạn sẽ thực sự được hưởng lợi từ việc có nó. (Chi tiết thay đổi theo ngôn ngữ, nền tảng và IDE.)

yêu cầu tương tác với máy chủ bên ngoài và không thể thực hiện tự động hóa do xác thực, kiến ​​trúc phần mềm hoặc độ phức tạp.

Tôi sẽ xem xét một số khung để sử dụng các đối tượng giả . Điều này cho phép bạn bao quanh thành phần đang được thử nghiệm với hệ sinh thái giả của các thành phần khác, để các thử nghiệm của bạn được nhắm mục tiêu cụ thể hơn và bạn có thể tránh kiểm tra mọi thứ trong toàn bộ đơn vị.

Ngoài ra, bản thân các đối tượng giả có thể được lập trình với các xác nhận, vì vậy bạn có thể kiểm tra xem thành phần đang được kiểm tra có thực sự thực hiện một cuộc gọi nhất định hay không.

Tôi sẽ làm việc chăm chỉ để giảm thời gian thử nghiệm. Tôi đã làm việc trong một vài công ty phát triển mã nhúng và việc kiểm tra rất khó khăn, đòi hỏi các chuyến đi đến phòng máy chủ và FTP thủ công và khởi động lại và nhiều lệnh cho phần cứng kiểm tra. Sau đó, tôi tham gia một nhóm thực sự tốt, nơi tôi có thể chỉ cần gõ 'làm bài kiểm tra' tại bàn của mình và nhận lại kết quả trong vòng một phút. Trong một phút:

• Mã của tôi đã được tích hợp vào một hình ảnh hạt nhân mới cho phần cứng nhúng.
• Máy chủ DHCP đã được cập nhật để trỏ đến kernel mới.
• Bảng thử nghiệm đã được khởi động lại.
• Bảng thử nghiệm đã lấy kernel từ máy trạm của tôi thông qua ngàm NFS.
• Bảng thử nghiệm đã khởi động lại vào kernel mới.
• Các bài kiểm tra đơn vị đã được chạy.
• Đầu ra thử nghiệm đơn vị đã được gửi trở lại máy trạm của tôi.

Phải mất một thời gian để tất cả các công việc này hoạt động, nhưng nỗ lực tự động hóa tất cả các bước này đã được thu hồi gấp trăm lần khi các nhân viên phát triển tăng trưởng.

Kiểm tra tự động không thay thế để xem xét và hiểu.

Nó có thể là bạn đang sử dụng thử nghiệm như một cái nạng. Nếu bạn đang làm điều này, bạn sẽ cản trở việc học của bạn. Tôi không ủng hộ bạn không thử nghiệm. Thay vào đó tôi sẽ khuyên bạn rằng trước khi bạn chạy kiểm tra đánh giá những gì bạn đã viết. Hiểu những gì bạn đã viết, đảm bảo nó có ý nghĩa và đảm bảo cú pháp có vẻ chính xác.

Bạn đã đưa ra câu trả lời: I usually make a lot of syntax errors and logic errors

Vì vậy, làm việc chăm chỉ để cải thiện điều đó, bạn sẽ có thể giảm thời gian thử nghiệm. Các lỗi cú pháp nên là lần đầu tiên bạn nên giảm. Chưa bao giờ có một bài kiểm tra lập trình với một tờ giấy và một cây bút chì trong nghiên cứu của bạn?

Tôi đã có điều tương tự khi tôi chuyển từ PHP sang Java. Tôi đã phải học cách gỡ lỗi thay vì chỉ in một số biến và nhấn F5 trong trình duyệt ...

Bạn cần một nền tảng kiểm tra Đơn vị hoặc Chức năng tốt có thể tự động chạy thử nghiệm cho bạn, tốt nhất là trong nền. Điều này sẽ yêu cầu sử dụng Mocks như đã lưu ý ở trên và tùy thuộc vào ngôn ngữ bạn đang sử dụng một số loại tiêm phụ thuộc.

Bằng cách làm cho các đối tượng của bạn độc lập nhất có thể và sau đó sử dụng các phương thức tiêm để thêm các ràng buộc bên ngoài, không khó để tạo một nền tảng thử nghiệm cho mã của bạn.

Niềm vui thực sự đến khi bạn đơn giản không thể kiểm tra mã của mình ngoại trừ bằng cách sử dụng nó trong sự tức giận. Điều này xảy ra khá nhiều với các hệ thống giao dịch, vì các trình giả lập trao đổi có sẵn thường kém, không tồn tại hoặc thậm chí không tuân thủ những gì các nhà cung cấp phần mềm trao đổi nói. Đây là một phần của tấm thảm phong phú của cuộc sống mà tôi sợ. Cách tiếp cận của tôi là đảm bảo ít nhất là phía giao dịch của tôi được viết tốt và được ghi chép đầy đủ, vì vậy nó có thể dễ dàng được thay đổi nhanh chóng.

Kiểm tra đơn vị; Ứng dụng giả / mô phỏng.

Điều này sẽ mất thời gian, được cấp và bạn có thể cần thu thập và xoa bóp dữ liệu mẫu để tạo ra các mô hình phù hợp, nhưng cuối cùng nó sẽ được đền đáp: Bạn sẽ tiết kiệm cho mình tất cả thời gian và rắc rối bạn gặp phải khi thử chống lại bên ngoài hệ thống.

Được sử dụng một cách chính xác, các công cụ này sẽ đảm bảo rằng trước khi bạn đi bất kỳ nơi nào gần các hệ thống bên ngoài, bạn chắc chắn 99,9% rằng nếu mã của bạn bị lỗi, đó là thứ gì đó trong hệ thống bên ngoài / thay đổi môi trường gây ra nó, không phải là lỗi trong mã của chính bạn.

Tôi đã làm việc chuyên nghiệp trong một thời gian họ theo cách bạn đã làm ở trường, và trong nhiều trường hợp nó rất hiệu quả. Cuối cùng, tôi đã làm việc dưới một số người buộc tôi phải từ bỏ phương pháp đó và sử dụng thử nghiệm đơn vị và mô phỏng thay thế.

Bây giờ, tôi không bắt đầu bất kỳ dự án nào mà không suy nghĩ trước tiên thông qua việc thực hiện các giai đoạn thử nghiệm - thử nghiệm đơn vị, mô phỏng, mô phỏng, dữ liệu mẫu, v.v.

Tôi thường mắc rất nhiều lỗi cú pháp và lỗi logic

Có lẽ sử dụng Linter có thể giúp bạn một chút ở đây.

Tôi đã ở trong tình trạng tương tự với chủ nhân trước đây của tôi. Cơ sở mã của chúng tôi thực sự rất lớn và để thực hiện bất kỳ thay đổi nào tôi phải mã hóa, biên dịch sau đó thay thế .classcác tệp trong máy chủ dev sau đó khởi động lại dev-sever bằng tập lệnh khởi động lại. Và với sự thất vọng của tôi, sẽ mất khoảng nửa giờ để đưa dev-server trở lại.

Sau đó tôi phát hiện ra rằng Remote gỡ lỗi máy chủ dev cũng có thể.

Vì vậy, đây là những gì tôi đã làm để tối ưu hóa quá trình của tôi

• Vòng đầu tiên của gỡ lỗi từ xa, điều này cho phép tôi thấy dòng mã chính xác và các giá trị / trạng thái chính xác của các biến.

• Lập kế hoạch như thế nào và những thay đổi tôi sẽ thực hiện.

• Thay đổi và sau đó so sánh các khác biệt

• Lỗi bộ đệm bằng cách sử dụng linter hoặc bằng cách biên dịch.

• Đưa ra các sửa chữa nóng bằng cách thay thế các .classtập tin và khởi động lại.

Đôi khi tôi cũng sẽ bao gồm rất nhiều báo cáo nhật ký để kiểm tra lại dòng mã và kiểm tra kiểm tra các giá trị / trạng thái. Điều này đã giúp tôi rất nhiều.

Ngoài ra, sử dụng IDE có khả năng tự động hóa tốt có thể giúp ích rất nhiều trong việc giảm lỗi chính tả.

Hi vọng điêu nay co ich.