Tần suất bạn chạy và kiểm tra mã của bạn trong khi lập trình? [đóng cửa]

Đặc biệt là khi viết mã mới từ đầu trong C, tôi thấy mình viết mã hàng giờ, thậm chí nhiều ngày mà không chạy trình biên dịch cho bất cứ điều gì ngoại trừ kiểm tra cú pháp thỉnh thoảng.

Tôi có xu hướng viết các đoạn mã lớn hơn một cách cẩn thận và chỉ kiểm tra kỹ lưỡng khi tôi tin rằng mã đó làm những gì nó phải làm bằng cách phân tích dòng chảy trong đầu tôi. Đừng hiểu sai ý tôi - Tôi sẽ không viết 1000 dòng mà không kiểm tra gì cả (đó sẽ là cờ bạc), nhưng tôi sẽ viết toàn bộ chương trình con và kiểm tra nó (và sửa nó nếu cần thiết) sau khi tôi nghĩ tôi đã hoàn thành.

Mặt khác, tôi đã thấy hầu hết những người mới chạy và kiểm tra mã của họ sau mỗi dòng họ nhập vào trình chỉnh sửa và nghĩ rằng trình gỡ lỗi có thể thay thế cho sự cẩn thận và tỉnh táo. Tôi coi điều này là rất nhiều phiền nhiễu một khi bạn đã học cú pháp ngôn ngữ.

Bạn nghĩ gì về sự cân bằng đúng đắn giữa hai cách tiếp cận? Tất nhiên cái đầu tiên đòi hỏi nhiều kinh nghiệm hơn, nhưng nó có ảnh hưởng đến năng suất tích cực hay tiêu cực không? Cái thứ hai có giúp bạn phát hiện ra lỗi ở mức độ tốt hơn không?

Nó thực sự phụ thuộc vào khía cạnh của dự án bạn đang làm việc.

• Khi tôi làm bất cứ điều gì với OpenGL (hoạt động như một máy trạng thái), tôi liên tục biên dịch và chạy để đảm bảo rằng tôi không vô tình làm hỏng bất cứ điều gì. Đặt một giá trị mà không nhớ đặt lại ở cuối chức năng có thể dễ dàng khiến ứng dụng chỉ hiển thị màn hình đen.

• Để phát triển "dưới mui xe" quy mô lớn hơn, tôi cố gắng thực hiện càng nhiều bài kiểm tra càng tốt trước đó. Vì các bài kiểm tra có thể dễ dàng cho tôi biết những gì đã phá vỡ, tôi có thể đi một lúc mà không phải chờ đợi quá trình biên dịch dài.

• Đối với thiết kế UX, tôi sử dụng một số loại thiết kế hình ảnh, nó luôn trông giống như cách nó sẽ chạy (hoặc gần với nó). Nó về cơ bản luôn luôn biên dịch mã thiết kế.

Cá nhân, tôi phải làm việc theo từng phần nhỏ vì tôi không đủ thông minh để giữ mã hóa hàng giờ trong bộ đệm L1 sinh học của mình. Do khả năng hạn chế của tôi, tôi viết các phương pháp nhỏ, gắn kết và thiết kế các đối tượng để có khớp nối rất lỏng lẻo. Các công cụ và ngôn ngữ mạnh hơn giúp mã hóa dễ dàng hơn mà không cần xây dựng, nhưng vẫn còn một giới hạn đối với tôi.

Sở thích của tôi là viết một mẩu nhỏ, xác minh rằng nó hoạt động như tôi mong đợi. Sau đó, theo lý thuyết, tôi thoải mái quên đi các chi tiết của mảnh đó và coi nó như một hộp đen càng nhiều càng tốt.

Tôi thích viết thử nghiệm trước khi tôi viết mã thực hiện. Tôi thích điều này vì ba lý do:

1. Viết mã kiểm tra của tôi trước khi bàn tay giúp tôi suy nghĩ về cách sử dụng mã của mình. Nó giúp tôi nghĩ về các trường hợp cạnh mà tôi không nghĩ đến khi tôi thiết kế chương trình ban đầu.
2. Tôi biết tôi đã viết xong mã thực hiện khi tất cả các trường hợp thử nghiệm của tôi vượt qua.
3. Tập thói quen viết bài kiểm tra trước khi viết mã cũng có tác dụng bổ sung để có thể chứng minh rằng mã của bạn chưa thêm bất kỳ lỗi mới nào (giả sử bạn đã viết các trường hợp kiểm thử tốt).

Tôi thấy mình viết mã trong nhiều giờ, thậm chí nhiều ngày mà không chạy trình biên dịch cho bất cứ điều gì ngoại trừ kiểm tra cú pháp thỉnh thoảng.

Vài giờ đến ngày - đó là một dấu hiệu rõ ràng cho thấy bạn bỏ lỡ khả năng chia mã của mình thành các phần nhỏ hơn có thể được xác minh và tự kiểm tra. Bạn chắc chắn nên làm việc trên đó.

Tôi có xu hướng viết các đoạn mã lớn hơn một cách cẩn thận và chỉ kiểm tra kỹ lưỡng khi tôi tin rằng mã đó làm những gì nó phải làm bằng cách phân tích dòng chảy trong đầu tôi.

Thay vì viết lớn hơn - và do đó phức tạp - các đoạn mã cần phân tích hàng giờ trong đầu, bạn nên cố gắng tạo các khối xây dựng nhỏ hơn, không quá lớn. Điều này được gọi là trừu tượng xây dựng - và đó là ý chính của lập trình tốt, chắc chắn không phải là dấu hiệu của một người mới.

Lập trình xuất sắc giống như chơi Billard xuất sắc - một người chơi giỏi không chơi những cú đánh mạnh. Thay vào đó, anh ta chơi theo cách mà sau mỗi cú đánh, các quả bóng dừng lại ở một vị trí mà cú đánh tiếp theo lại dễ dàng trở lại. Và một lập trình viên không tốt vì anh ta có thể viết mã phức tạp - anh ta tốt vì anh ta có thể tránh viết mã phức tạp.

Tôi biên dịch và kiểm tra nếu một trong những điều kiện sau được thỏa mãn:

• Biên dịch lần cuối là 15 phút trước
• Biên dịch cuối cùng là 25 dòng trước
• Chức năng / chương trình con mới đã được thực hiện
• Thay đổi lớn
• Tính năng mới (hoặc một lỗi được ngụy trang thành một tính năng)
• Sửa lỗi (đã xóa "tính năng")
• Tôi chán

Tần suất tôi chạy và kiểm tra mã tùy thuộc vào ngôn ngữ tôi đang làm việc cùng lúc. Nếu tôi đang mã hóa một thủ tục được lưu trữ, tôi thường sẽ đợi cho đến khi mọi thứ ở đó.

Mặt khác, nếu tôi đang mã hóa trong Lisp, tôi sẽ thử từng chức năng sau khi tôi nhập nó.

Nếu tôi đang mã hóa trong Haskell, thông thường tôi sẽ biên dịch sau mỗi hàm để bắt bất kỳ lỗi loại nào và chạy mã sau khi mọi thứ hoàn tất.

Tôi viết mã vừa đủ để kiểm tra màu xanh lá cây. Điều đó có nghĩa là tôi chạy thử nghiệm cứ sau vài phút. Đó là phong cách C ++ của tôi. Tuy nhiên, trong Ruby tôi sử dụng autotest, vì vậy mỗi lần nhấn lưu tôi sẽ nhận được phản hồi kiểm tra thông qua cửa sổ bật lên đẹp. Tôi thậm chí không ngừng viết mã, nó chỉ xảy ra trong nền.

Ba giờ một lần, cho dù nó cần hay không.

Chúng tôi lập trình thử nghiệm đầu tiên và chỉ cam kết mã làm việc với VCS. Smolderbot đi và kiểm tra repo cứ sau 20 phút và chạy bộ thử nghiệm. Bất kỳ lỗi nào được gửi ngay lập tức đến toàn bộ nhóm lập trình để khắc phục ngay lập tức.

Đối với tôi nó không phải là về việc tôi viết bao nhiêu. Tôi có thể viết hàng ngàn dòng mã đơn giản mà không cần phải kiểm tra nó. Nhưng khi tôi viết mã khó hơn, tôi có xu hướng kiểm tra từng chức năng riêng lẻ sau khi đã viết một tập hợp gắn kết của chúng.

Tuy nhiên, đôi khi, nhìn thấy mã của bạn đang chạy là một động lực rất lớn, khi bạn không chạy bất cứ thứ gì trong một thời gian, thật tốt khi thấy nó hoạt động.

Đối với tôi; - Dòng
thời gian ngắn (không có nhiều thời gian để suy nghĩ) - viết mã, biên dịch, kiểm tra. gỡ lỗi
Đủ thời gian - while (xong) {viết mã nhỏ, biên dịch}, kiểm tra, gỡ lỗi

Tôi kiểm tra cho từng khái niệm mã hóa. Đôi khi đây là một hàm hoặc lớp và đôi khi nó không hơn gì một câu lệnh if. Một khi khái niệm hoạt động, đi đến cái tiếp theo.

Tôi thử và viết các bài kiểm tra trước khi mã. Tôi chạy thử nghiệm ít nhất hai lần trước khi cam kết. Sau đó, nó chạy lại với máy chủ Tích hợp liên tục.