Có tốt để xem xét các chương trình với người cao niên và ông chủ ngay cả khi nó hoạt động tốt?

Trong công ty của tôi, trước khi giao bất kỳ dự án nào, sếp của tôi yêu cầu người cao niên của tôi xem xét các chương trình do tôi hoặc các thành viên khác trong nhóm viết hoặc đôi khi ông chủ cũng ngồi với chúng tôi để xem xét.

Tôi nghĩ rằng đó là một cách tốt để có được kiến ​​thức, nhưng đôi khi khi các chương trình hoạt động tốt, chúng không hoạt động giống nhau sau khi xem xét và tôi cần xem lại chương trình của mình.

Họ nói rằng việc xem xét giúp tối ưu hóa việc thực hiện chương trình và truy vấn, nhưng chúng ta có thể thích tối ưu hóa hơn chức năng thực tế của chương trình không?

"Làm việc tốt" thực sự là một thước đo tuyệt vời, nhưng nếu bạn là người duy nhất trong nhóm có thể giải mã những gì bạn đã viết, và do đó duy trì nó, mã này gần như vô giá trị đối với công ty trong trung hạn hoặc dài hạn.

Một mã tốt ít nhất là:

• Làm việc như dự định
• con người có thể đọc / rõ ràng
• dễ dàng bảo trì
• dễ dàng mở rộng cho những thay đổi trong tương lai
• an toàn
• không phụ thuộc không cần thiết
• xử lý chính xác các trường hợp không danh nghĩa
• Vân vân

(Một số trong những yêu cầu này thực sự chồng chéo nhưng tốt để xem xét riêng lẻ ...)

Đánh giá mã phục vụ mục đích ngoài phần "làm việc", có thể được thực hiện thông qua các bài kiểm tra tự động.

Cá nhân tôi biết điều này thật khó chịu khi có một cái gì đó hoạt động bị xé nát, và phải xây dựng lại từ đầu. Nhưng, thông thường, điều này là do một thông tin sai lệch từ lãnh đạo cấp cao / công nghệ. Vì vậy, nếu bạn nghĩ rằng bạn phải viết lại quá thường xuyên, lần tới, hãy đến gặp người đánh giá trước khi viết một dòng duy nhất và cố gắng lấy càng nhiều thông tin càng tốt về những gì anh ta đang mong đợi, trong từng chi tiết. Nó cũng có thể là tuyệt vời nếu nhóm các nhà đánh giá mã tóm tắt kỳ vọng của họ trong một tài liệu chính thức mà mọi nhà phát triển có thể tham khảo.

Về mặt tích cực hơn, một phiên cũng có thể là một dịp để chia sẻ các thực tiễn / thiết kế tuyệt vời.

Tôi đã giải thích câu hỏi của bạn là "Mã chức năng của tôi có thể bị đánh cắp trong một bài đánh giá đến một điểm mà nó thậm chí không còn được biên dịch nữa không?" .

Vâng, nó có thể. Nói chung, trong khi xem xét, bạn nhìn vào cách mã của bạn làm những gì nó làm. Khi bạn muốn nộp mã của mình, bạn nói rằng bạn đã hoàn thành một phần nhất định của chương trình.

Bạn nói nó hoạt động. Kiểm tra sau đó được thực hiện để xác minh điều này. Một mô-đun vượt qua kiểm tra không có nghĩa là mô-đun không nên được chạm lại.

Một mô-đun xuất hiện chức năng vẫn có thể là một thảm họa đang chờ xảy ra, trong thời gian chạy hoặc trong một vài tháng khi bạn hoặc người khác phải thực hiện bảo trì trên nó. Bằng cách thay đổi mã của bạn trong bài đánh giá và chỉ ra điều gì sai với nó, người đánh giá của bạn (hy vọng) đang cố gắng thực sự dạy cho bạn một cái gì đó.

Đánh giá ngang hàng là một cách tuyệt vời để học hỏi. Ai đó có thể thấy điều gì đó khác biệt, họ có trải nghiệm khác với bạn và có thể đóng góp những cải tiến. Điều này không nên chê bai, tôi mong bất kỳ nhà phát triển nào cũng có thể nhận xét và phê bình một cách xây dựng mã của bất kỳ ai!

Đối với tôi có vẻ như một số "cải tiến" này thực sự đang tạo ra những thay đổi đột phá bởi vì (như bạn mong đợi) nhà phát triển đánh giá có ít kinh nghiệm với phần mềm hơn tác giả.

Xu hướng này là tự phản hồi, có lẽ mã của bạn khó theo dõi hoặc duy trì? Nhận xét của bạn có giá trị? Chắc chắn rồi! Tôi có thể thấy làm thế nào nó có thể gây bực bội, để có mã làm việc mà các đồng nghiệp của bạn sau đó dường như bị phá vỡ, bạn không nên nản lòng - bạn nên làm việc để bảo vệ mã của mình trước những thay đổi này.

Câu hỏi sau đó trở thành cách bảo vệ chức năng của các chương trình của bạn để bạn biết chức năng vẫn hoạt động sau khi bạn hoàn thành các đánh giá của mình. Đề nghị của tôi sẽ là để đảm bảo bạn có phạm vi kiểm tra đơn vị phong nha. Bằng cách đó, bất cứ khi nào bạn / người đánh giá / người kế nhiệm của bạn thay đổi mã, họ có thể tin tưởng rằng những thay đổi họ đã thực hiện là an toàn.

ETA: Tôi vừa phát hiện một trong những bình luận của bạn, tôi chắc chắn rằng điều này không cần phải nói nhưng việc đánh giá mã nên được thực hiện trước khi nhóm thử nghiệm có được nó. Nếu không, họ không thử nghiệm sản phẩm cuối cùng.