Có hiệu quả để xem lại mã bằng ngôn ngữ tôi không biết?

Tôi là một nhà phát triển có kinh nghiệm, nhưng chưa thực hiện nhiều đánh giá mã. Tôi đang được yêu cầu xem lại mã được viết bằng Python nhưng tôi không biết Python.

Liệu nó có ý nghĩa gì khi xem lại mã bằng ngôn ngữ mà tôi không biết?

Có ý nghĩa gì không? Đúng. Ngay cả khi bạn không biết gì về ngữ nghĩa của ngôn ngữ lập trình, bạn vẫn có thể đọc các ký tự và nhận thấy định dạng không nhất quán, thiếu nhận xét, số nhận dạng được chọn xấu, trùng lặp rõ ràng, v.v.

Nhiều ý nghĩa, hoặc đủ ý nghĩa để trả lại chi phí thời gian của bạn ? Tôi không chắc. Điều này phụ thuộc vào vị trí của bạn, tầm quan trọng của đánh giá mã trong quy trình làm việc của nhóm của bạn và một số yếu tố khác mà chúng tôi không thể định lượng đủ tốt.

Là một người đóng góp thường xuyên tại Sàn giao dịch đánh giá mã , tôi gặp rất nhiều câu hỏi về các vấn đề bất khả tri về ngôn ngữ, ví dụ:

• Định dạng, thụt lề
• Phạm vi
• Vòng lặp
• Loại hoạt động

Và danh sách được tiếp tục. Tuy nhiên, trong khi tôi không cần biết ngôn ngữ, tôi vẫn có thể xem lại những vấn đề / điểm đó.

Một số người dùng hàng đầu của chúng tôi có câu trả lời hàng đầu bằng ngôn ngữ họ không chủ động sử dụng hoặc không biết. Ngay cả hai trong số mười ngôn ngữ hàng đầu của tôi là ngôn ngữ mà tôi không biết và cũng không thể biên dịch / chạy trên máy của mình.

Tôi thậm chí sẽ nói nó giống như xem xét mã giả của ai đó. Miễn là bạn có thể quan sát và nhận xét về những điều liên quan đến những điều bạn hiểu, bạn sẽ ổn, và nó sẽ có liên quan.

Lời khuyên chung

Đây là điểm mấu chốt, theo ý kiến ​​của tôi:

• Nếu bạn không biết ngôn ngữ đủ rõ để biết các tính năng và thành ngữ phổ biến , có lẽ bạn sẽ không đóng góp nhiều cho bài đánh giá.
• Nếu bạn muốn tìm hiểu các tính năng và thành ngữ của ngôn ngữ, bạn có thể tham gia đánh giá. Bạn nên tập trung quan sát các thành ngữ và đặt câu hỏi về các mẫu và tổ chức không có ý nghĩa với bạn. Điều này có thể giúp xác định các khu vực có vấn đề, nhưng chỉ theo nghĩa là bạn có thể buộc nhà phát triển bảo vệ những gì họ đã làm. Đặt câu hỏi của bạn theo cách để lại khoảng trống cho kiến ​​thức của bạn. Lưu ý rằng điều này có thể cuối cùng là một chi phí ròng trong bản đánh giá, nhưng chi phí đó là một khoản đầu tư vào kiến ​​thức của bạn.
• Khả năng đóng góp của bạn cho đến khi bạn làm quen với các tính năng, thành ngữ và tiêu chuẩn của ngôn ngữ sẽ bị hạn chế. Tôi sẽ không mong đợi điều này sẽ thay đổi cho đến khi bạn thực sự đã viết một lượng mã đáng kể bằng ngôn ngữ.

Xem xét và ví dụ cụ thể về Python

Đối với tình huống cụ thể của việc không biết Python, tôi sẽ đặc biệt cảnh giác với điều này. Python có rất nhiều thành ngữ và các thực tiễn tiêu chuẩn cuối cùng làm cho Python tốt trông rất khác so với những gì bạn có thể mong đợi ở các ngôn ngữ khác. (Thật vậy, tôi nghĩ rằng những điều Python nhấn mạnh đã làm cho mã của tôi trông tốt hơn trong các ngôn ngữ khác chứ không phải theo cách khác.) Beyond PEP8 có một ví dụ hay về cách bạn có thể hoàn toàn bỏ lỡ những suy nghĩ mà Python khuyến khích.

Hãy xem xét một ví dụ đơn giản. Lấy mã này:

f = open('/home/me/something.txt')
try:
    content = f.read()
finally:
    f.close()

Xem vấn đề với mã này? Nếu bạn chưa từng làm việc với Python, có lẽ bạn không làm thế. Vấn đề là có một nhiều phong cách ưa thích trong Python mà không chính xác những điều tương tự:

with open('/home/me/something.txt') as f:
    content = f.read()

Đây là một người quản lý bối cảnh. Bạn có biết chúng tốt cho cái gì không? Bạn có biết khi nào nó sẽ thích hợp để sử dụng một? Bạn có biết khi nào nó sẽ thích hợp để tạo ra của riêng bạn? Không? Sau đó, có lẽ bạn chưa sẵn sàng để xem xét Python.

Hãy xem xét một ví dụ khác.

def add_fifty(other_list):
   result = list()
   for i in other_list:
       result.append(i + 50)
   return result

x = range(10)
y = add_fifty(x)

Thấy vấn đề? Vấn đề là phương pháp này là hoàn toàn không cần thiết . Có lẽ bạn chỉ nên sử dụng một sự hiểu biết tại chỗ, khi thao tác này đơn giản:

x = range(10)
y = [i + 50 for i in x]

Nếu bạn không thấy điều đó, bạn không quen thuộc với các tính năng và thành ngữ của Python.

Họ có thể đã yêu cầu bạn xem lại mã Python chính xác vì bạn không biết Python . Có một lý thuyết quản lý rằng thật hữu ích khi có một "kẻ ngốc" trong một nhóm. Tôi không gọi bạn là một tên xấu :) Ý tưởng là một nhóm có thể bị suy nghĩ theo nhóm và phát triển tầm nhìn đường hầm. Một cách để thoát ra khỏi điều này là bao gồm một người nào đó trong nhóm mà các thành viên khác trong nhóm sẽ coi là "kẻ ngốc", nghĩa là, một người không biết vấn đề này. Bạn sẽ đặt câu hỏi để thông báo cho chính mình và các câu hỏi sẽ xuất phát từ quan điểm mà các thành viên khác trong nhóm có thể không bao giờ xem xét.

Bạn không biết Python, vì vậy những gì có vẻ bình thường đối với các lập trình viên Python có vẻ lạ đối với bạn. Bạn có thể đề xuất một cải tiến mà nhóm không bao giờ xem xét.

Đánh giá mã không phải là tìm kiếm các biến có lỗi chính tả và định dạng sai. Nếu bạn sử dụng xem lại mã để tìm những thứ như vậy, thì hãy ngừng lãng phí thời gian của bạn và sử dụng một công cụ.

Đánh giá mã là về cải tiến thiết kế và phát hiện các lỗi phổ biến của một lập trình viên mới làm quen.

Vì tôi lập trình trong C ++ và tôi không biết rõ về Python, nên tôi không dám xem lại mã Python. Tuy nhiên tôi có thể giúp với một đánh giá mã Java.

Bạn đã không nói bằng ngôn ngữ nào bạn lập trình, nhưng tôi không thấy những gì bạn có thể đóng góp trong đánh giá mã, nếu bạn không biết ngôn ngữ mà nó được lập trình.

Đánh giá mã (ngoài việc thực sự tìm kiếm sai sót) là một giới thiệu tốt từ một thành viên trong nhóm cho những người khác để mã được thêm hoặc thay đổi. Nếu bạn là một nhà phát triển có kinh nghiệm , bạn sẽ có thể đọc đủ để hiểu hầu hết những gì đang diễn ra.

Nhìn vào đánh giá mã theo quan điểm của trưởng nhóm: có ai đó hiểu ứng dụng nên làm gì (logic nghiệp vụ), có ai đó hiểu mã đang làm (logic thực hiện) và có thể một số người khác có ai cần phải có ý tưởng về việc làm thế nào tất cả những thứ đó khớp với nhau.

Bạn chắc chắn không nên là người đánh giá duy nhất , nhưng có rất nhiều lý do tốt để bạn trở thành một trong những người đánh giá. Không biết ngôn ngữ không phải là một trở ngại cho rất nhiều câu hỏi cần trả lời trong một đánh giá mã. Ví dụ, tôi là một trong 20 người trả lời hàng đầu trong thẻ C # trên trang web này và tôi không có nhiều như thế giới được biên dịch trong C #.

Một số chuyên môn bạn có thể chia sẻ mà không cần biết ngôn ngữ:

• Kiến thức tên miền.
• Thiết kế hướng đối tượng chung.
• Thực hành lập trình chung: đặt tên, rõ ràng, v.v.

Đó cũng là một cách hay để tăng tốc độ cho một sản phẩm mới. Tôi mới gia nhập một nhóm mới, nơi tôi biết các ngôn ngữ được sử dụng khá tốt, nhưng không biết tên miền. Tham gia vào các đánh giá mã đã giúp tôi tìm hiểu phía miền tốt hơn, mặc dù tôi chưa thể đóng góp nhiều trong các dòng đó.

Trong trường hợp của bạn, nó sẽ là một cách tốt để tìm hiểu các thành ngữ của một ngôn ngữ mới, khi bạn thấy các ý kiến ​​khác mà các nhà phê bình để lại. Đây là những điều rất khó học theo bất kỳ cách nào khác, bởi vì trình thông dịch của bạn không quan tâm liệu mã của bạn có phải là pythonic hay không.

Đây có thể là một tình huống đôi bên cùng có lợi Tôi sẽ đi xa hơn để nói rằng bạn có thể là một nhà phê bình đặc biệt có giá trị bởi vì bạn là một trinh nữ Python chưa bị nguyền rủa bởi Lời nguyền của kiến ​​thức .

Hãy nghĩ về nó theo cách này: nếu mã đủ rõ ràng mà ngay cả một trinh nữ Python cũng có thể hiểu nó, thì đó phải là mã tốt. Những phần mà bạn gặp khó khăn trong việc hiểu có thể là ứng cử viên để làm lại hoặc nhận xét tốt hơn.

Rõ ràng, nó cũng sẽ có ích cho bạn, bởi vì bạn sẽ chọn một ngôn ngữ mới khi bạn đi. (Hy vọng rằng mã bạn được cung cấp là một ví dụ tốt để học hỏi.) Sự sắp xếp này sẽ hoạt động đặc biệt tốt đối với Python, một ngôn ngữ có tiếng là "mã giả thực thi". Nếu bạn là một nhà phát triển có kinh nghiệm, thì bạn không nên gặp nhiều khó khăn trong việc hiểu ý chính của chương trình Python.

Thông báo trước là bạn sẽ không phát hiện ra các lỗi phát sinh từ các vấn đề cụ thể về ngôn ngữ . Nhưng tìm lỗi không phải là mục đích duy nhất của đánh giá mã. Nếu không có gì khác, bạn sẽ tham gia chuyển giao kiến ​​thức chỉ bằng cách nhận thức được loại công cụ nào diễn ra trong mã của đồng nghiệp của bạn.

Tôi đã từng được yêu cầu kiểm toán một dự án đang được thực hiện bởi một nhà thầu phụ và dường như có vấn đề nghiêm trọng về hiệu suất. Tôi khá nhanh chóng xác định rằng yếu tố quan trọng là một mô-đun Perl duy nhất. Tôi chưa bao giờ gặp Perl trước đây và chúng tôi không có ai trong tổ chức biết điều đó, vì vậy tôi bắt đầu cố gắng tự hiểu nó. Tôi chưa bao giờ hiểu được chi tiết, nhưng rõ ràng thuật toán mà nó đang sử dụng là bậc hai về kích thước dữ liệu và đây là nguyên nhân của tất cả các vấn đề. Vì vậy, có, đọc mã bằng ngôn ngữ bạn không hiểu đầy đủ có thể có hiệu quả. Phần thưởng là bạn học được những mánh mới trong khi bạn nói về nó.

Một vài quan sát:

1) Nếu bạn là một nhà phát triển có kinh nghiệm, bạn sẽ chọn Python (hoặc ít nhất là nhiều như bạn cần biết), chỉ bằng cách làm việc với nó. Nó sẽ là một trường hợp "vừa học vừa làm". Lúc đầu sẽ khó, nhưng sẽ dễ hơn khi bạn chọn ngôn ngữ. Hãy nghĩ về điều này như một cơ hội để học một ngôn ngữ khác (mọi người thường học các ngôn ngữ "nước ngoài" thông qua "ngâm".)

2) Có một số người có giá trị trên các trang SE là "phi kỹ thuật", nhưng có kỹ năng về ngữ pháp, giao tiếp và logic. Những người như vậy mang lại "con mắt mới" cho các đối tượng và thực hiện một số bản sửa lỗi "không có trí tuệ" mà người khác bỏ lỡ, vì họ quá "trói buộc" trong tài liệu. Bạn đang được tư vấn có lẽ là về các kỹ năng không "kỹ thuật" (tức là không phải Python) của bạn như logic và hiểu biết về lập trình tổng thể.

Và nếu bạn chưa thực hiện nhiều đánh giá mã, hầu như mọi trải nghiệm đánh giá mã sẽ giúp bạn là nhà phát triển. Điều này có vẻ như là một trận đấu tốt giữa các kỹ năng và nhu cầu của bạn và nhóm.

Điều đó phụ thuộc vào mục tiêu của đánh giá là gì; tức là những gì bạn có nghĩa là hiệu quả .

Bạn vẫn có khả năng có thể phát hiện một số vấn đề. Nếu bạn là tất cả những gì họ phải xem xét và họ chỉ hy vọng rằng bạn xem qua nó sẽ giúp một số và có thể nắm bắt được điều gì đó, thì chắc chắn. Nhiều khái niệm về cấu trúc tương tự nhau giữa các ngôn ngữ. Một đặc biệt là có thể xem xét các bình luận. Cần phải nhận xét đủ tốt để một lập trình viên không thuộc ngôn ngữ cụ thể đó vẫn có thể cảm nhận tốt về những gì đang xảy ra. Nếu không ... thì bạn có thể nói cho họ biết bình luận của họ thiếu ở đâu. Nếu nó được bình luận tốt ... thì bạn sẽ có thể xem xét khá nhiều cấu trúc của chúng chỉ thông qua các chú thích về những gì đang diễn ra thay vì thực sự đọc mã của những gì đang diễn ra.

Nhưng bạn sẽ không thể phát hiện ra nhiều vấn đề khác. Vì vậy, nếu họ có ý định cho đánh giá của bạn là một quyết định toàn diện về việc liệu đây có phải là một chương trình được thực hiện tốt / có thể thực hiện được hay không, họ sẽ thất vọng.

Việc kết quả đó có xứng đáng với thời gian bạn thực hiện hay không phụ thuộc phần lớn vào dự án.