Tôi đã được trao vai trò để cải thiện sự phát triển trong công ty của chúng tôi. Điều đầu tiên tôi muốn bắt đầu là đánh giá mã vì điều đó chưa bao giờ được thực hiện ở đây trước đây.

Có 3 lập trình viên trong công ty chúng tôi. Tôi là một lập trình viên web, các ngôn ngữ tôi biết chủ yếu là PHP, ActionScript và JavaScript. Hai nhà phát triển khác viết các ứng dụng nội bộ trong VB.net

Chúng tôi đã thực hiện đánh giá mã trong một vài tuần nay. Tôi thấy khó hiểu mã VB. Vì vậy, khi họ nói những gì nó làm, phần lớn tôi chỉ cần nói lời của họ cho nó.

Nếu tôi thấy có gì đó không ổn, tôi sẽ giải thích ý kiến ​​của mình và tôi giải thích cách tôi sẽ giải quyết nó bằng một trong những ngôn ngữ mà tôi biết.

Đôi khi các đề xuất của tôi được hoan nghênh nhưng nhiều lần tôi được nói những điều như "đây là cách tốt nhất để thực hiện bằng ngôn ngữ này " hoặc "không áp dụng cho ngôn ngữ này " hoặc những điều tương tự có tính chất đó.

Điều này có thể đúng, nhưng không biết ngôn ngữ tôi không chắc chắn làm thế nào để xác nhận hoặc bác bỏ các khiếu nại này.

Tôi biết một giải pháp khả thi sẽ là học vb để tôi có thể đánh giá mã tốt hơn. Tôi thực sự không có hứng thú với việc học vb (đặc biệt là khi tôi có một danh sách các công nghệ khác mà tôi đang cố gắng học cho các dự án của riêng mình) và muốn giữ nó như là phương sách cuối cùng nhưng đó là một lựa chọn.

Một ý tưởng khác đến với tôi là, cả hai đều có hứng thú với C # và tôi cũng vậy. Nó liên quan đến họ vì .net và tương đối với tôi vì nó giống với các ngôn ngữ tôi biết. Tuy nhiên, nó là mới cho tất cả chúng ta. Tôi đã nghĩ về lợi ích của tất cả chúng ta khi hợp tác trong một dự án C # .net thú cưng và xem xét mã của nhau từ đó.

Tôi đoán cũng có khả năng thuê một chuyên gia tư vấn đến và đưa cho chúng tôi một số đánh giá mã.

Bạn muốn giới thiệu tôi làm gì trong tình huống này.

Mong muốn cá nhân của bạn để học những thứ khác nên ngồi ở ghế sau để học những gì bạn thực sự cần ngay bây giờ cho công việc của bạn. Tìm hiểu VB.net. Bạn có thể viết mã đánh giá một cách hiệu quả mà bạn không hiểu khi bạn biết ngôn ngữ đó bằng cách đặt nhiều câu hỏi (thường đó là một dấu hiệu mã không được viết tốt nếu bạn biết ngôn ngữ và không thể hiểu được nó đang làm gì và tại sao). Nhưng không hiểu mã, điều tốt nhất bạn có thể làm là yêu cầu họ giải thích cho bạn và hy vọng họ sẽ thấy bất kỳ lỗi nào thông qua quá trình giải thích nó. Không phải là tôi đã không tìm thấy lỗi trong mã của riêng mình trong bài đánh giá bằng cách thực hiện điều đó, nhưng đó không phải là cách hiệu quả nhất để đánh giá mã. Xem lại mã bây giờ là một phần công việc của bạn, giải quyết nó và tìm hiểu những gì bạn cần học để làm điều đó một cách hiệu quả.

Trong khi bạn đang học, khi họ nói tốt đó không phải là cách chúng tôi làm bằng ngôn ngữ này, hãy khiến họ chỉ cho bạn một nguồn nói rằng đó là một kỹ thuật tốt để sử dụng. Tùy thuộc vào họ để biện minh cho bạn trong đánh giá mã chứ không phải cách khác. Bạn cũng sẽ trở nên tốt hơn về ngôn ngữ khi bạn bắt đầu thấy các liên kết đó.

Thật ra, tôi không đồng ý với tất cả những điều trên. Với JS / PHP / ActiopnScript, bạn có hiểu biết cơ bản về ngôn ngữ lập trình có gì và cách thức hoạt động của nó. Trong thực tế, tôi sẽ lập luận rằng có rất nhiều điểm tương đồng giữa VB và JS. Tuy nhiên, đó không phải là quan điểm của tôi. Ngay cả khi bạn rất thành thạo ngôn ngữ, bạn vẫn dễ dàng bỏ qua điều gì đó khi cố gắng theo dõi quá trình suy nghĩ của người khác, vì vậy những gì cần xem xét là tạo cơ hội cho lập trình viên giải thích những gì anh ta đã làm và tại sao.

Một người bạn đã từng mô tả đây là "Lý thuyết của người đi rừng": bằng cách giải thích chi tiết cho ai đó, bất cứ ai, thậm chí là người gác cổng, lập trình viên đã tiết lộ bất kỳ điểm yếu nào trong mã cho họ, tất nhiên, đó là mục tiêu cuối cùng của đánh giá quá trình. Tuy nhiên, yêu cầu mã phải được giải thích kỹ lưỡng và công khai (các đánh giá không hoạt động khi các nhà phát triển phòng thủ).

Phiên bản ngắn

1. Hãy nhớ rằng đánh giá mã là cơ hội cho cả người đánh giá và người đánh giá học hỏi.
2. Phản hồi cụm từ như một câu hỏi.
3. Đừng để thiếu kiến ​​thức ngăn bạn cung cấp phản hồi (miễn là bạn đang làm # 2).
4. Tránh "đánh giá ưu tiên" hoặc ít nhất là cố gắng làm rõ rằng đó là sở thích cá nhân của riêng bạn và họ không nhất thiết phải đồng ý.
5. Cố gắng gửi các bản vá thay vì là một "người đánh giá mã ghế bành".

Phiên bản dài hơn

Trước hết, hãy nhớ rằng đánh giá mã không chỉ là cơ hội để người đánh giá học hỏi. Đó cũng là cơ hội để người đánh giá học hỏi. Trên thực tế, tôi đã nghe nói về một số tổ chức khiến các lập trình viên mới bắt đầu thực hiện đánh giá mã để họ có thể cảm nhận về mã.

Với suy nghĩ này, có một lời khuyên đánh giá mã mà tôi luôn thấy hữu ích nói chung, nhưng đặc biệt thích hợp ở vị trí của bạn. Phát âm phản hồi của bạn dưới dạng câu hỏi chứ không phải là một tuyên bố. Nói cách khác, thay vì nói "Mã này thật tệ!", Bạn có thể nói "Tại sao bạn viết mã theo cách này thay vì làm ..." Điều này làm cho quá trình xem xét mã dễ chịu hơn và cho phép bạn học tốt.

Một lời khuyên khác mà tôi dành cho bạn là đừng để sự thiếu hiểu biết của bạn khiến bạn chùn bước. Nếu bạn thấy điều gì đó mà bạn cho là sai và bạn nhận được câu trả lời gợn sóng từ người đánh giá, đừng lùi bước (ít nhất là không phải do thiếu kiến ​​thức). Hãy nhớ rằng, những gì tạo ra mã tốt trong một ngôn ngữ hiếm khi khác với những gì tạo ra mã tốt trong bất kỳ ngôn ngữ nào khác. Có, một số ngôn ngữ nhất định có các thành ngữ khác nhau để giúp bạn viết mã tốt. Nhưng điều quan trọng là phải nhận ra rằng những thành ngữ đó là công cụ chứ không phải là kết thúc trong chính chúng.

Tiếp theo, cố gắng tránh làm "đánh giá ưu tiên". Đây là điều mà tôi (và nhiều người khác) phải nỗ lực rất có ý thức. Nói cách khác, cố gắng tránh thực hiện các đánh giá dọc theo dòng "Bạn đã làm x , nhưng tôi thích y ". Bây giờ, không có gì sai với việc nêu rõ các ưu tiên, nhưng bạn nên dán nhãn rõ ràng như vậy và ghi chú rằng bên kia có quyền không đồng ý. Điều này rất quan trọng, bởi vì hầu hết mọi thứ khác nhau từ ngôn ngữ này sang ngôn ngữ đều thuộc danh mục này.

Cuối cùng, các bạn có sử dụng hệ thống kiểm soát phiên bản phân tán không? Một điều có thể hữu ích là nếu thay vì chỉ lưu ý những gì sai với mã, bạn có thể viết lại mã như thế nào bạn sẽ viết nó, kiểm tra nó, và sau đó gửi một bản vá cho nó. Điều này giúp cho thấy rằng bạn thực sự quan tâm đến việc cải thiện mã của họ và không chỉ là một "người đánh giá mã ghế bành" và cho bạn cơ hội học ngôn ngữ tốt hơn. Ngoài ra, thường không dễ đồng ý với "Tôi nghĩ bạn nên làm điều này" hơn là "Đây là cách tôi sẽ làm nó, và đây là một bản vá nếu bạn đồng ý". Tôi cho rằng bạn không nhất thiết cần một DVCS cho việc này, nhưng nó chắc chắn có ích.

Bạn đã mất tập trung vào vấn đề và đưa ra một giải pháp kém. Bạn đã được giao nhiệm vụ cải thiện sự phát triển và giải pháp của bạn là đưa một người chịu trách nhiệm xem xét mã (chính bạn), người không hiểu ngôn ngữ. Ai đang xem lại mã của bạn? Tại sao họ không thể xem xét lẫn nhau cho đến khi bạn học ngôn ngữ?

Phải có một số lĩnh vực vấn đề khác có thể được lựa chọn để có một cải tiến ngay lập tức hơn. Bằng cách này, họ chỉ thổi khói vào bạn và không có gì cải thiện.

Hướng sự phát triển mới vào một ngôn ngữ mà không ai trong số các bạn hiểu (C #) sẽ mất nhiều thời gian để trả hết, đặc biệt nếu mọi người đều mang theo những thói quen xấu của họ với họ.

Tập trung vào thiết kế (Điều đó đã được đề cập.). Nếu họ gặp khó khăn trong việc duy trì mã hiện tại, hãy xem xét một số công cụ tái cấu trúc cho VB. Nhiều thực hành cơ bản là như nhau.

Bạn có thể 'đọc bằng chứng' những thứ mà bạn không thực sự biết, nhưng bạn không thể xem xét đầy đủ . Tôi có năng lực cao về C, biết C ++ khá tốt, nhưng tôi sẽ không mơ ước được xem xét điều gì đó trong C #.

Tôi không nghĩ rằng bạn cần phải đi xa hơn khi mang đến một nhà tư vấn, vì một số công ty chuyên chạy mã của bạn mặc dù có rất nhiều bài kiểm tra và cho bạn biết điều gì có thể sai với nó.

Tuy nhiên, sẽ tùy thuộc vào từng nhà phát triển biết ngôn ngữ để giải thích kết quả. Chẳng hạn, nếu một người đánh giá mã khiến tôi không sử dụng giá trị trả về printf(), tôi sẽ nhìn họ một cách kỳ lạ và đặt câu hỏi về sự tỉnh táo của họ, sau đó hỏi "Ok, tuyệt, tôi có thể làm gì khi không thể in ra bảng điều khiển có ích không? "

Những gì bạn có thể muốn xem xét là nói chuyện với các sếp của bạn về việc thiết lập các phòng ban và lãnh đạo nhóm, để bạn có thể có hiệu quả trong miền của mình, trong khi một người khác có hiệu quả trong miền của họ.

Tuy nhiên, tôi nghĩ rằng bạn có thể sử dụng bên thứ ba để kiểm toán. Hầu hết các lập trình viên đáng muối của họ sẽ chú ý đến những mối quan tâm chính đáng , ngay cả khi họ loại bỏ một nửa là không có thật (như trong printf()ví dụ của tôi ).

Cung cấp hướng dẫn về một cái gì đó bạn không hiểu giống như người mù dẫn dắt người mù vì bạn nhận thức rõ.

Một cách tiếp cận sẽ là sử dụng các công cụ lint như FxCop và StyleCop sẽ giải quyết mặt trước phân tích tĩnh của cơ sở mã. Điều này sẽ cung cấp cho bạn một điểm khởi đầu để tranh luận về các báo cáo được tạo ra từ các công cụ.

Một cách tiếp cận khác là biến các đánh giá mã thành đánh giá thiết kế. Thiết kế đánh giá thường xuyên hơn sau đó không phát hiện ra vấn đề lâu trước khi mã thậm chí được viết. Nếu một lập trình viên có một thiết kế, họ có thể làm việc từ họ nói chung hiệu quả hơn nhiều trong cách tiếp cận của họ và lỗi giảm vì điều này. Khi một thiết kế không tồn tại, nó sẽ trở thành adhoc trong cách tiếp cận và mã chịu đựng số lỗi ngày càng tăng. Nắm bắt các vấn đề trong đánh giá thiết kế trước khi chúng xuất hiện trong phần đánh giá mã bằng cách đảm bảo mỗi bạn có một thiết kế cụ thể để thực hiện; UML là bạn của bạn ở đây và các công cụ như umlet rất nhanh và nhanh để sử dụng.

Tin xấu là để tham gia hiệu quả vào đánh giá mã, bạn sẽ phải học VB. Nó cũng sẽ hữu ích để sử dụng VB trong một số loại dự án (không nhất thiết phải cho sản xuất).

Tin vui là một khi bạn đã thực hiện điều này, một số điều bạn đã học sẽ vẫn hữu ích khi bạn chuyển sang C #.

Ý nghĩ mà bạn nên giữ mọi lúc khi thực hiện đánh giá ngang hàng là:

"TÔI LÀ NGƯỜI TIẾP THEO ĐỂ KIẾM MÃ SỐ NÀY!"

Bạn phải hiểu nó đủ tốt để có thể làm điều đó như là một phần của sự chuẩn bị của bạn để đánh giá, và công việc của bạn là làm cho lập trình viên ban đầu nhận thức được bất kỳ thiếu sót nào khiến nó trở nên cồng kềnh hơn mức cần thiết để hiểu mã đủ tốt để duy trì nó .

Nếu bạn không thể lập trình trong VB, bạn không thể duy trì mã và bạn không đủ điều kiện để trở thành người đánh giá ngang hàng.

Bạn không nên xem lại mã mà bạn không hiểu, điều đó sẽ chỉ gây khó chịu cho các nhà phát triển, những người phải giải thích mọi điều trông lạ mà họ đã làm.

Những gì bạn có thể làm chọn / xác định các nguyên tắc mã hóa và kiểm tra mã theo các nguyên tắc này. Khi một cái gì đó không tuân thủ các nguyên tắc, bạn có thể yêu cầu nhà phát triển giải thích.

Tôi sẽ bắt đầu với việc chọn các nguyên tắc hiện có (tôi không biết bất kỳ tiêu chuẩn mã hóa VB.net nào nhưng google đã cho tôi:

• Hướng dẫn mã hóa VB .Net
• Thay đổi
• Tất cả trong một khung mã

Sử dụng stylecop như các công cụ cho VB .net

Phân tích các nguồn với NDepend (nó có các quy tắc về độ phức tạp chu kỳ, độ dài, độ sâu, v.v.)

Khi bạn đã thực hiện mà bạn có thể nói rằng mã tuân thủ các tiêu chuẩn đã chọn, nó không nói gì về chức năng là chính xác hoặc mã sử dụng các nguyên tắc OOP thích hợp. Nhưng ít nhất nó là một cái gì đó.

Đánh giá mã tốt là về những điều đòi hỏi bạn phải hiểu ngôn ngữ - sử dụng ngôn ngữ, API và thư viện phù hợp, kiểu dáng, tên biến, v.v. - và về cách mã giải quyết vấn đề - nhận xét tốt, kiến ​​trúc phù hợp, thiết kế phù hợp các mẫu, xem xét tất cả các trường hợp lỗi, v.v. Khi bạn mới bắt đầu thực hiện đánh giá mã, bạn có xu hướng tập trung vào cái trước. Chúng dễ nhìn hơn và dễ chọn hơn. (ví dụ: tôi không thích tên biến của bạn. Bạn nên sử dụng tên kiểu XXXX.)

Đánh giá mã trở nên có giá trị hơn khi có nhiều sự tập trung vào việc mã giải quyết vấn đề tốt như thế nào. Vì bạn không thể cung cấp nhiều giá trị trong khu vực đầu tiên ngay bây giờ, hãy tập trung vào việc đặt câu hỏi và đưa ra lời khuyên về giải pháp cho vấn đề, chứ không phải về cách thức thực hiện.

Tất nhiên có sự chồng chéo giữa hai. Biết VB.NET sẽ cho phép bạn cung cấp lời khuyên về lý do tại sao một mẫu thiết kế nhất định không phải là một lựa chọn tốt trong một tình huống cụ thể chẳng hạn.

Trên hết, hãy khiêm tốn ở giai đoạn này. Quá trình thay đổi là khó khăn. Ngay cả khi bạn là một guru VB.NET, sự thay đổi có thể sẽ không dễ dàng. Những người chưa sử dụng đánh giá mã lúc đầu không thích nó. Có người khác nhìn vào mã của bạn là một kinh nghiệm khó khăn. Phải mất thời gian để thấy giá trị, và kiên nhẫn xung quanh. Đó là một quá trình tuyệt vời khi bạn mua vào nhưng sẽ mất thời gian.

Bạn có thể chuyển trọng tâm để tập trung vào các bài kiểm tra hơn là nhìn trực tiếp vào mã không? Tôi không nói từ bỏ các đánh giá mã, nhưng ban đầu có thể có ý nghĩa hơn để khiến các ứng dụng nội bộ đó có đủ các bài kiểm tra có thể giúp giải mã một số điều đang xảy ra. Ý tưởng ở đây là các bài kiểm tra cũng có thể giúp bạn làm quen hơn với một số chức năng. Tôi chỉ xem đây là một con đường khác để đi. Ý tưởng ở đây là các đánh giá sẽ quay lại sau và có thể được thực hiện trong một vài phần vì nó có thể đáng để có một tổng quan / phiên trả trước và sau đó nghỉ ngơi một chút. Việc nghỉ đó kéo dài đến một hoặc hai ngày tiếp theo để có đủ thời gian cho bất kỳ ai muốn ngủ đêm suy nghĩ về mã hoặc một cái gì đó tương tự trước khi quay lại với câu hỏi và thảo luận.

Tất nhiên nếu bạn đã có bài kiểm tra thì điều này không có ý nghĩa gì. Ý nghĩ khác là đưa ra một ví dụ về nơi họ tuyên bố rằng trong VB.Net điều này được thực hiện theo một cách cụ thể, vì điều đó có thể giúp làm cho câu hỏi này rõ ràng hơn theo cách mà tôi có thể tưởng tượng điều này thay đổi từ các tiêu chuẩn mã nhỏ đến một phần của trung tâm của cách VB.Net được xây dựng theo một nghĩa nào đó.

Ngay cả khi bạn học các kiến ​​thức cơ bản về VB, thực hiện đánh giá mã trong khi không biết tất cả các tính năng của ngôn ngữ sẽ không cho phép bạn phát hiện việc sử dụng các tính năng không an toàn trong ngôn ngữ.

Giả sử rằng bạn không biết rằng hàm input () trong Python 2 thực sự đã đánh giá đầu vào trước khi trả về nó, để giúp phân tích các kiểu đầu vào không phải chuỗi dễ dàng hơn. Sau đó, mã sẽ dễ bị thực thi Mã tùy ý, cho phép người dùng nhập một cái gì đó giống như __import__('os').execl('/bin/sh', '/bin/sh')trên hệ thống Linux để biến quy trình Python thành một trình bao. Thay vào đó, raw_input () nên được sử dụng để lấy dữ liệu đầu vào chưa được xử lý.

Cố gắng thực hiện đánh giá mã trong khi không nhận thức được tất cả các tính năng của ngôn ngữ không chỉ có thể ngăn bạn nhận ra một cách tốt hơn để thực hiện một quy trình nhất định trong ngôn ngữ; nó cũng có thể dẫn đến sai sót an ninh bất lợi.