Làm thế nào tôi nên đi sửa mã từ một lập trình viên ít kinh nghiệm?

19

Một chút nền tảng: Tôi là một trong hai lập trình viên cho bộ phận 10 người của chúng tôi (phần còn lại là nghệ sĩ và quản lý). Hai chúng tôi làm tất cả các mã hóa cần thiết để làm cho mọi thứ trôi chảy, và phát triển bất kỳ dự án nào được đưa ra. Tôi đã lập trình được khoảng 4 năm rồi, đây là công việc "thực sự" đầu tiên của anh ấy (như anh ấy đã nói). Chúng tôi thường đang làm việc trên các dự án khác nhau tại bất kỳ thời điểm nào.

Một vài tháng trước, tôi đã phát triển một tập hợp các lớp (không có nghĩa là hoàn hảo) sẽ được sử dụng cho một dự án sau này. Một phần lớn của dự án đó đã được giao cho anh ta (vì lý do thanh toán) để thiết kế và lập trình giao diện GUI. Vì anh ấy là người mới, tôi đã giúp một chút với việc thiết kế, và nói sẽ yêu cầu giúp đỡ nếu anh ấy cần nó với phần còn lại. Anh ấy đã hoàn thành giao diện một vài tuần trước, mà anh ấy đã demo để cho thấy rằng nó hoạt động, mặc dù hơi chậm.

Phần tiếp theo của dự án đã bắt đầu mà tôi đang làm việc. Tôi đã mở giao diện để bắt đầu với các bước tiếp theo và ngay lập tức gặp sự cố (chậm một chút là thiếu hiểu biết, lỗi về các hành động thông thường, v.v.). Tôi đã xem xét mã cho một số vấn đề và đang tìm kiếm O(n^n)các cuộc gọi nên O(n), nhập các giả định không có kiểm tra lỗi (đó là trong Python), các tham chiếu đến GUI được thêm vào mã gốc, v.v.

Bây giờ, tôi chắc chắn muốn dạy anh ấy những gì sai và cách khắc phục, nhưng anh ấy đã chuyển sang dự án tiếp theo của mình, và đây là một vài tuần trước. Tôi sợ tôi nói "Quay lại và làm đúng!" (với sự giúp đỡ tất nhiên) là quá khắc nghiệt, và chúng tôi vẫn còn các dự án khác để hoàn thành trong thời gian này. Tôi có nên tự sửa mã cho bây giờ và cố gắng nắm bắt mọi thứ trong tương lai không?

code-reviews bug

— TorelTwiddler
nguồn

4

Trong tương lai, có khả năng đồng ý về các nguyên tắc mã hóa, điều đó sẽ ngăn ngừa các lỗi như bạn mô tả không?

— Benni

5

Một điều tốt là bạn không ngay lập tức chạy đến quản lý và nói với anh ta. Một số công ty được định hướng đổ lỗi. Khi bạn kiểm tra các bản sửa lỗi, hãy tìm cách nhóm chúng lại với nhau và sau đó để anh chàng này xem xét chúng sau. Mặt khác, ngay cả một sinh viên mới tốt nghiệp cũng không nên mã hóa bất cứ thứ gì O(n^n)trừ khi không có cách nào khác. Nếu họ làm như vậy, thì có lẽ họ đã đạt điểm C về thuật toán hoặc không lấy nó hoặc có một giáo viên nhảm nhí. Tận dụng một số loại công cụ để giúp tìm các vấn đề phổ biến sẽ tốt đẹp. Có lẽ là nhiệm vụ tiếp theo anh chàng này có thể viết một số bài kiểm tra hiệu suất?

— Công việc

Một O (n ^ n) không có tài liệu về lý do tại sao đơn giản là sai, thời gian. Nếu bạn thực sự phải làm điều đó, các ý kiến đã giải thích rõ hơn tại sao.

— Loren Pechtel

Đã định viết rằng "này, O (n * n) không tệ lắm, nhiều ứng dụng yêu cầu nó ..." nhưng sau đó tôi nhận ra rằng đó không phải là một dấu hiệu nhân, mà là một kẻ giết người ^!

— Tối đa

O (n ^ n) có thể nhanh hơn O (n) nếu O (n) có hằng số rất lớn và n nhỏ. mã hóa kinh dị.com / blog / 2007/09 / Từ đó một lần nữa, n ^ n là cực kỳ: D

— Coder

33

Âm thanh như thiết lập một số loại chính sách đánh giá mã có thể có lợi trên nhiều cấp độ. Một số lợi ích trước mắt:

Bạn có thể ảnh hưởng trực tiếp đến chất lượng mã của anh ấy trước khi mã được cam kết, do đó giữ cho chất lượng cơ sở mã cao
Giữ bạn khỏi những sai lầm tương tự mà một cặp mắt khác có thể bắt gặp
Trong trường hợp không có hướng dẫn mã hóa, các đánh giá tự nhiên dẫn đến sự nhất quán trong phong cách mã hóa
Chia sẻ kiến thức. Nếu chỉ có hai bạn và một người bị xe buýt đâm ...

Bây giờ khi bạn tiếp tục và bắt đầu làm sạch mã của mình, hãy sử dụng nó như một bài tập giảng dạy khi bạn tìm kiếm một đánh giá về mã này. Bạn sẽ được xem lại nội dung của mình và anh ấy có thể học cách làm nó tốt hơn vào lần sau.

— không
nguồn

3

Đánh giá mã +1 là một cách tuyệt vời để làm điều này. Tôi sẽ đề xuất phrasing nó nhiều hơn dọc theo dòng "Bạn có phiền khi xem xét những thay đổi tôi đã thực hiện để đảm bảo tôi không bỏ lỡ điều gì không" thay vì "Đây là những cách tôi đã cải thiện mã của bạn".

— Steve Jackson

1

+1 Tôi muốn nói rằng đánh giá mã phù hợp hơn nhiều so với bất kỳ "nguyên tắc mã hóa vàng" nào .. Không có nhiều điều không bao giờ ổn.

— Tối đa

Tôi thực sự thích ý tưởng này, cảm ơn. Bây giờ tôi sẽ chỉ cần nghiên cứu một chút về các cách tốt để thực hiện đánh giá mã!

— TorelTwiddler

1

Thực sự có một bài viết hay và thú vị với một số điều cơ bản có sẵn tại mumak.net/ ware / your-code-sucks.html . Chủ yếu là về các kỹ thuật hành vi để thực hiện đánh giá theo cách xây dựng, điều này cực kỳ quan trọng để đánh giá thành công.

— không có

@TorelTwiddler, chỉ cần nhớ rằng đánh giá mã là để học chứ không phải đổ lỗi. Chỉ ra những điều mà anh ấy đã làm tốt, vì vậy anh ấy biết rằng chúng tốt đồng thời với những gợi ý để cải thiện.

— CaffGeek

5

Không bao giờ không bao giờ sửa mã của họ, nếu không họ sẽ không học được gì ngoài việc họ mắc lỗi, bạn sẽ bắt chúng và sửa chúng. Nhiệm vụ không được thực hiện cho đến khi hoàn thành . Tôi đã thực sự may mắn khi tôi bắt đầu chuyên nghiệp và người giám sát trực tiếp của tôi đã kiểm tra lại mọi thứ tôi đã cam kết, và nếu có một giải pháp tốt hơn hoặc tôi đã phạm một sai lầm ngớ ngẩn sẽ cho tôi biết, điều đó có nghĩa là kỹ năng của tôi đã tốt hơn, có nghĩa là tôi đã cải thiện nhanh hơn và phát triển Một làn da cứng hơn.

Để nó trượt sẽ sinh ra những thói quen xấu, sửa chữa ngay bây giờ sẽ khiến chúng đối phó tốt hơn với những lời chỉ trích và kiểm tra ba lần trước khi tuyên bố nó đã được thực hiện.

— Nicholas Smith
nguồn

2

Chúng ta có thể suy luận rằng dự án "hoạt động" và được thực hiện trong một khoảng thời gian hợp lý (mặc dù với một số vấn đề thiết kế nghiêm trọng nhưng có thể sửa chữa)? Nếu vậy, nó có hình dạng tốt hơn nhiều so với nhiều dự án tôi đã thấy trong những năm qua.

Tôi nghĩ rằng giao tiếp nhiều hơn sẽ giúp nhóm của bạn-- và điều này có thể được thực hiện với việc xem xét mã thông thường.

Thật tốt khi bạn nhạy cảm với việc "quá khắc nghiệt" và tôi nghĩ rằng bạn sẽ nhớ rằng việc xem lại mã không phải là một trải nghiệm ngồi ghế nóng, nơi những người đàn em bị nướng và xem xét kỹ lưỡng. Nó cũng có thể là một cách để các nhà phát triển cao cấp thể hiện các thực tiễn tốt và để mọi người có được sự tin tưởng lẫn nhau bằng cách lịch sự và thân thiện ngay cả khi có "lỗi lầm".

Mọi người học tốt khi họ thấy những thứ thực sự tốt trông như thế nào. Điều này là tốt hơn so với hệ thống chỉ ra từng lỗ hổng nhỏ. Tuy nhiên, O (n ^ n) nên được chỉ ra một cách nhẹ nhàng và mang tính xây dựng.

— Angelo
nguồn

0

Chia sẻ kiến thức của bạn.

Tôi sẽ đề nghị anh ta giúp đỡ trong dự án mới của anh ta để đổi lấy một số lời dạy từ một học sinh cuối cấp đến một thiếu niên.

Tại sao không lập trình cặp trên cả hai dự án?

— mouviciel
nguồn