Чи ефективно переглянути код мовою, яку я не знаю?

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

Чи має сенс взагалі переглянути код мовою, яку я не знаю?

Якийсь сенс? Так. Навіть якщо ви нічого не знаєте про семантику мови програмування, ви все одно можете читати символи та помічати непослідовне форматування, відсутні коментарі, неправильно вибрані ідентифікатори, очевидне дублювання тощо.

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

Як постійний довідник на Exchange Code Stack Exchange , я стикаюся з багатьма питаннями, які страждають на мовно-агностичних питаннях, наприклад:

• Форматування, відступ
• Область застосування
• Петлі
• Введіть операції

і список продовжується. Однак, хоча мені не потрібно знати мову, я все ще можу переглянути ці питання / моменти.

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

Я б навіть сказав, що це буде те саме, що переглядати чийсь псевдо-код. Поки ви зможете спостерігати та коментувати речі, що стосуються речей, які ви розумієте, ви будете добре, і це буде доречно.

Загальна порада

Ось підсумок, на мій погляд:

• Якщо ви не знаєте достатньо добре мови, щоб знати особливості та загальні фразеологічні фрази , ви, ймовірно, не збираєтесь багато сприяти рецензуванню.
• Якщо ви хочете дізнатися особливості та ідіоми мови, ви можете взяти участь у огляді. У центрі уваги слід спостерігати за ідіомами та задавати питання щодо моделей та організації, які не мають для вас сенсу. Це може допомогти визначити проблемні області, але лише в тому сенсі, що ви можете змусити розробника захищати те, що вони зробили. Задавайте свої питання таким чином, що залишає місце для вашої розриву в знаннях. Зауважте, що це може призвести до чистої вартості в самому огляді, але ці витрати є інвестицією у ваші знання.
• Ваша здатність робити внесок, поки ви не ознайомитеся з особливостями мови, ідіомами та стандартами, буде обмежена. Я б не очікував, що це зміниться, поки ви фактично не напишите значну кількість коду мовою.

Конкретні міркування та приклади 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.

Застереження полягає в тому, що від вас не очікується виявлення помилок, що виникають із -за специфічних для мови мовних програм . Але пошук помилок - не єдина мета огляду коду. Якщо нічого іншого, ви б брали участь у передачі знань, просто усвідомлюючи, які речі тривають у коді вашого колеги.

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

Кілька спостережень:

1) Якщо ви досвідчений розробник, ви підберете Python (або принаймні стільки, скільки вам потрібно знати), просто працюючи з ним. Це буде випадок "навчання ділом". Спочатку буде важко, але стане легше, коли ви підберете мову. Подумайте про це як про можливість вивчення іншої мови (люди часто вивчають "іноземні" мови через "занурення").

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

І якщо ви ще не зробили багато перегляду коду, практично будь-який досвід перегляду коду допоможе вам як розробнику. Це виглядає як гарна відповідність між вашими вміннями та потребами та командою.

Це залежить від того, яка мета огляду; тобто те, що ви маєте на увазі під ефективним .

Ви все одно зможете виявити деякі проблеми. Якщо ви все, що їм доводиться переглядати, і вони просто сподіваються, що якщо ви переглянете це, то це допоможе дещо і, можливо, щось схопить, то впевнені. Багато понять будови схожі між мовами. Особливо можна переглядати коментарі. Слід прокоментувати досить добре, що програміст, який не є цією мовою, все-таки повинен мати можливість добре відчути те, що відбувається. Якщо ні ... то ви можете сказати їм, де бракує їх коментарів. Якщо це так добре прокоментовано ... тоді ви повинні мати можливість переглянути трохи їх структуру за допомогою анотацій того, що відбувається, а не насправді читати код того, що відбувається.

Але ви, швидше за все, не виявите багатьох інших проблем. Тож якщо вони мають намір для вашого огляду вичерпне визначення того, чи це добре зроблена / дієва програма, вони будуть розчаровані.

Від того, чи варто цей результат вартий часу, коли ви це зробите, багато в чому залежить від проекту.