Эффективно ли просматривать код на языке, которого я не знаю?

Я опытный разработчик, но не сделал много обзоров кода. Меня просят просмотреть код, написанный на Python, но я не знаю Python.

Есть ли смысл пересматривать код на языке, которого я не знаю?

Какой смысл? Да. Даже если вы ничего не знаете о семантике языка программирования, вы все равно можете прочитать символы и заметить несоответствующее форматирование, пропущенные комментарии, неправильно выбранные идентификаторы, очевидное дублирование и т. Д.

Большой смысл или достаточный смысл, чтобы окупить стоимость вашего времени ? Я не уверен. Это зависит от вашей позиции, важности проверок кода в рабочем процессе вашей команды и ряда других факторов, которые мы не можем определить достаточно хорошо.

Как постоянный участник в Code Review Stack Exchange , я сталкиваюсь с множеством вопросов, страдающих от не зависящих от языка проблем, например:

• Форматирование, отступ
• Объем
• Loops
• Операции типа

И список продолжается. Тем не менее, хотя мне не нужно знать язык, я все же могу рассмотреть эти вопросы / моменты.

У некоторых наших лучших пользователей есть лучшие ответы на языках, которые они либо не используют активно, либо не знают. Даже две из моей первой десятки написаны на языках, которые я не знаю и не могу скомпилировать / запустить на моей машине.

Я бы даже сказал, что это было бы так же, как просмотр чьего-то псевдокода. Пока вы можете наблюдать и комментировать вещи, относящиеся к вещам, которые вы понимаете, у вас все будет хорошо, и это будет актуально.

Общий совет

Вот итог, на мой взгляд:

• Если вы недостаточно хорошо знаете язык, чтобы знать особенности и общие идиомы , вы, вероятно, не собираетесь вносить большой вклад в обзор.
• Если вы хотите изучить особенности и идиомы языка, вы можете принять участие в обзоре. Ваше внимание должно быть сосредоточено на соблюдении идиом и задании вопросов о моделях и организации, которые не имеют смысла для вас. Это может помочь выявить проблемные области, но только в том смысле, что вы можете заставить разработчика защищать то, что он сделал. Задайте свои вопросы таким образом, чтобы оставить место для вашего пробела в знаниях. Обратите внимание, что это может в конечном итоге привести к чистой стоимости самого обзора, но эта стоимость является инвестицией в ваши знания.
• Ваша способность вносить свой вклад до тех пор, пока вы не ознакомитесь с особенностями, идиомами и стандартами языка, будет ограничена. Я не ожидал бы, что это изменится, пока вы на самом деле не написали значительное количество кода на языке.

Python конкретные соображения и примеры

Для конкретной ситуации незнания Python я бы особенно остерегался этого. В Python есть много идиом и стандартных приемов, которые в итоге приводят к тому, что хороший Python выглядит совсем не так, как вы могли ожидать в других языках. (Действительно, я думаю, что то, что подчеркивает Python, заставило мой код выглядеть лучше на других языках, а не наоборот.) Помимо PEP8 есть хороший пример того, как вы можете полностью пропустить мышление, которое поощряет Python.

Давайте посмотрим на простой пример. Возьми этот код:

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

Видите проблему с этим кодом? Если вы не работали с Python, возможно, нет. Проблема заключается в том, что существует много предпочтительного стиля в Python , что делает ровно то же самое:

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

Это контекстный менеджер. Ты знаешь, для чего они хороши? Вы знаете, когда было бы целесообразно использовать один? Знаете ли вы, когда было бы целесообразно создать свой собственный? Нет? Тогда вы, вероятно, не готовы к рассмотрению Python.

Давайте посмотрим на другой пример.

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)

Видишь проблему? Проблема в том, что этот метод совершенно не нужен . Вы, вероятно, должны просто использовать понимание на месте, когда операция так проста:

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

Если вы этого не видели, вы не знакомы с особенностями и идиомами Python.

Возможно, они попросили вас пересмотреть код Python именно потому, что вы не знаете Python . Есть теория управления, что полезно иметь «дурака» в команде. Я не называю вас плохим именем :) Идея в том, что команда может страдать от группового мышления и развития туннельного видения. Один из способов избежать этого - включить в команду кого-то, кого другие члены команды сочли бы «дураком», то есть того, кто не знает предмета. Вы будете задавать вопросы, чтобы информировать себя, и вопросы будут исходить из точки зрения, которую другие члены команды, вероятно, никогда не рассматривали.

Вы не знаете Python, поэтому то, что может показаться обычным для программистов Python, может показаться вам странным. Вы можете предложить улучшение, которое команда никогда не рассматривала.

Обзор кода не касается поиска переменных с неправильным написанием и неправильным форматированием. Если вы используете проверку кода, чтобы найти такие вещи, то прекратите тратить свое время и пользуйтесь инструментом.

Обзор кода посвящен улучшению дизайна и выявлению распространенных ошибок начинающими программистами.

Поскольку я программирую на C ++ , и я недостаточно хорошо знаю Python, я бы не посмел пересмотреть код Python. Однако я мог бы помочь с обзором кода Java.

Вы не сказали, на каком языке программируете, но я не вижу, что вы могли бы внести в обзор кода, если вы не знаете язык, на котором он программируется.

Обзоры кода (в дополнение к фактическому поиску недостатков) - хорошее введение от одного члена команды к другим для добавления или изменения кода. Если вы опытный разработчик , вы должны быть в состоянии прочитать достаточно, чтобы в основном понять, что происходит.

Посмотрите на обзор кода с точки зрения руководителя группы: там есть кто-то, кто понимает, что должно делать приложение (бизнес-логика), есть кто-то, кто понимает, что код делает (логика реализации), и, возможно, несколько других людей там, кто должен иметь представление о том, как все это сочетается.

Вы определенно не должны быть единственным рецензентом, но есть много веских причин для того, чтобы стать одним из рецензентов. Незнание языка не является большой помехой для многих вопросов, на которые нужно ответить в обзоре кода. Например, я один из 20 лучших ответчиков в теге C # на этом сайте, и я не так много, как скомпилированный привет мир в C #.

Некоторый опыт, которым вы можете поделиться, не зная языка:

• Базовые знания.
• Общий объектно-ориентированный дизайн.
• Общие практики программирования: наименование, ясность и т. Д.

Это также хороший способ быстро освоить новый продукт. Я только что присоединился к новой команде, где я знаю, что языки используются достаточно хорошо, но не знаю предметную область. Участие в обзорах кода помогло мне лучше изучить предметную область, хотя я пока не смог внести большой вклад в этом направлении.

В вашем случае это будет хороший способ выучить идиомы нового языка, поскольку вы видите комментарии других рецензентов. Это те вещи, которые очень трудно выучить любым другим способом, потому что вашему интерпретатору все равно, является ли ваш код питоническим или нет.

Это может быть беспроигрышная ситуация. Я бы даже сказал, что вы можете быть особенно ценным рецензентом, потому что вы - девственница Python, которая не была испорчена Проклятием Знаний .

Подумайте об этом так: если код достаточно ясен, чтобы даже Python-девственница могла его понять, то это должен быть хороший код. Части, которые у вас есть проблемы с пониманием, могут быть кандидатами на доработку или лучшее комментирование.

Очевидно, это также будет полезно для вас, потому что вы будете выбирать новый язык, как вы идете. (Надеемся, что приведенный вами код является хорошим примером для изучения.) Это расположение должно особенно хорошо работать для Python, языка, который имеет репутацию «исполняемого псевдокода». Если вы опытный разработчик, то вам не составит труда понять суть программы Python.

Предостережение заключается в том, что вы не должны будете обнаруживать ошибки, возникающие в зависимости от языка . Но поиск ошибок - не единственная цель проверки кода. Если бы не что иное, вы бы участвовали в передаче знаний, просто зная, что происходит в коде вашего коллеги.

Однажды меня попросили провести аудит проекта, который выполнялся субподрядчиком и у которого были серьезные проблемы с производительностью. Я довольно быстро установил, что критическим фактором был один модуль Perl. Я никогда раньше не сталкивался с Perl, и в организации не было никого, кто бы знал это, поэтому я попытался понять это сам. Я никогда не доходил до понимания деталей, но было очень ясно, что алгоритм, который он использовал, был квадратичным по размеру данных, и это было причиной всех проблем. Так что да, чтение кода на языке, который вы не до конца понимаете, определенно может быть продуктивным. Бонус в том, что вы учитесь новым трюкам, пока вы об этом.

Несколько замечаний:

1) Если вы опытный разработчик, вы приобретете Python (или хотя бы столько, сколько вам нужно знать), просто работая с ним. Это будет случай «учиться на практике». Поначалу это будет сложно, но с выбором языка вам станет легче. Думайте об этом как о возможности выучить другой язык (люди часто изучают «иностранные» языки через «погружение»).

2) На сайтах SE есть ряд ценных людей, которые «не являются техническими», но владеют грамматикой, коммуникациями и логикой. Такие люди дают «свежий взгляд» на предметы и делают ряд «простых решений», которые другие пропускают, потому что они слишком «связаны» в материале. С вами, вероятно, консультируются по поводу ваших «не технических» (то есть не Python) навыков, таких как логика и общее знание программирования.

И если вы не сделали много обзора кода, практически любой опыт проверки кода поможет вам как разработчику. Это похоже на хорошее соответствие между вашими навыками, потребностями и командой.

Это зависит от того, какова цель обзора; т.е. что вы подразумеваете под эффективным .

Вы все еще, вероятно, сможете обнаружить некоторые проблемы. Если вы - все, с кем им нужно ознакомиться, и они просто надеются, что вы посмотрите на это, это поможет некоторым и, возможно, поймает что-то, тогда точно. Многие понятия структуры похожи между языками. Особенно это касается возможности комментирования. Это должно быть достаточно хорошо прокомментировано, чтобы программист, не принадлежащий к этому конкретному языку, все же мог хорошо понять, что происходит. Если нет ... тогда вы можете сказать им, где их комментарии отсутствуют. Если это так хорошо прокомментировано ... тогда вы должны быть в состоянии просмотреть довольно немного их структуры только посредством аннотаций того, что происходит, вместо того, чтобы фактически читать код того, что происходит.

Но вы вряд ли обнаружите много других проблем. Так что, если они намерены сделать ваш обзор исчерпывающим, чтобы определить, является ли это хорошо сделанной / выполнимой программой, они будут разочарованы.

Стоит ли этот результат того времени, которое вы потратили на это, во многом зависит от проекта.