Мені відведено роль покращити розвиток нашої компанії. Перше, що я хотів почати - це огляди коду, оскільки цього раніше ніколи не робилося.

В нашій компанії є 3 програмісти. Я веб-програміст, мої відомі мови - це переважно PHP, ActionScript та JavaScript. Інші 2 розробники пишуть внутрішні додатки на VB.net

Ми проводимо огляд коду вже пару тижнів. Мені важко зрозуміти код VB. Тож коли вони кажуть, що це робить, я здебільшого просто повинен прийняти їхнє слово.

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

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

Це може бути правдою, але не знаючи мови, я не знаю, як підтвердити або спростувати ці твердження.

Я знаю, що одним із можливих рішень було б вивчити vb, щоб я міг робити кращі огляди коду. Мені справді не цікаво вивчати vb (тим більше, що у мене є список інших технологій, які я намагаюся вивчити для власних проектів) і хотів би зберегти це як крайній захід, але це варіант.

Ще одна ідея, яка прийшла до мене, полягає в тому, що вони обидва зацікавлені в C # і так само я. Її відносно них, тому що вона є .net і відносно мене, тому що вона більше схожа на мови, які я знаю. І все-таки вона нова для всіх нас. Я подумав про переваги усіх нас, що співпрацюють над домашнім проектом C # .net, і переглянув код інших для цього.

Я здогадуюсь, є також можливість найняти консультанта, щоб завітати до нас.

Що б ви порадили мені зробити в цій ситуації.

Ваші особисті бажання дізнатись інші речі повинні зайняти місце, щоб дізнатися, що вам насправді потрібно для вашої роботи. Дізнайтеся VB.net. Ви можете ефективно перевірити код коду, який ви не розумієте, коли знаєте мову, на якій він входить, задаючи багато питань (зазвичай це знак, що код недостатньо написаний, якщо ви знаєте мову і не можете зрозуміти, що вона робить і чому). Але не розуміючи коду, найкраще, що ви можете зробити, це змусити їх пояснити вам його та сподіватися, що вони побачать помилки в процесі пояснення. Не те, що я не знайшов помилок у власному коді в огляді, роблячи саме це, але це не найефективніший спосіб кодування. Перегляд коду зараз є частиною вашої роботи, займайтеся нею і дізнайтеся, що вам потрібно навчитися, щоб виконувати її ефективно.

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

Власне, я не згоден із усім вищесказаним. З JS / PHP / ActiopnScript ви маєте фундаментальне розуміння того, що має мова програмування та як вона працює. Насправді я б заперечував, що між VB та JS існує багато подібності. Однак це не моя суть. Навіть якщо ви дуже добре володієте мовою, легко не помітити щось, намагаючись слідкувати за чужими процесами мислення, тому те, що огляд повинен зробити, - це дає можливість програмісту пояснити, що (він) зробив і чому.

Друг одного разу описав це як "Теорію двірника": пояснюючи деталі комусь, комусь, навіть двірнику, програміст викриває перед собою будь-які недоліки в коді, що, звичайно, є кінцевою метою огляду процес. Однак потрібно, щоб код пояснювався ретельно і відкрито (огляди не працюють, коли розробники захищають).

Коротка версія

1. Пам’ятайте, що огляди коду - це шанс навчитися як рецензованого, так і рецензента.
2. Фразові відгуки як питання.
3. Не дозволяйте нестачі знань перешкоджати вам надавати відгуки (поки ви займаєтесь №2).
4. Уникайте "оглядів переваг" або, принаймні, намагайтеся уточнити, що це ваші особисті переваги, і вони не обов'язково повинні погоджуватися.
5. Спробуйте надіслати виправлення, а не "рецензент коду крісла".

Більш довга версія

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

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

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

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

Нарешті, чи використовуєте ви, розподілену систему контролю версій? Одне, що може допомогти, це якщо замість того, щоб просто зазначити, що з кодом не так, ви можете переписати код, як би ви його написали, протестуйте його, а потім надішліть його. Це допомагає показати, що ви щиро зацікавлені в удосконаленні їх коду, а не просто "рецензент коду крісла" і дає вам можливість краще вивчити мову. Плюс до цього, як правило, легше не погодитися з "я думаю, ти повинен це зробити", ніж це "Ось як я це зробив би, і ось патч, якщо ти згоден". Я припускаю, що вам не обов'язково потрібен DVCS для цього, але це, безумовно, допомагає.

Ви втратили фокус на проблемі і придумали неякісне рішення. Ви отримали завдання вдосконалити розвиток, і ваше рішення - поставити відповідальну за перегляд коду (себе), який не розуміє мови. Хто переглядає ваш код? Чому вони не можуть переглядати один одного, поки ви не вивчите мову?

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

Направлення нової розробки на мову, яку ніхто з вас не розуміє (C #) не займе багато часу, щоб виплатити себе, особливо якщо всі ви переносите свої шкідливі звички.

Зосередьтеся на дизайні (Про це було сказано). Якщо у них виникають труднощі з підтримкою поточного коду, перегляньте кілька інструментів рефакторингу для VB. Багато базових практик однакові.

Ви можете «підтвердити прочитане» речі, які ви насправді не знаєте, але не можете їх адекватно переглянути . Я високо компетентний в C, знаю C ++ досить добре, але я б не мріяв щось переглянути в C #.

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

І все-таки вирішувати результат слід лише окремим розробникам, які знають мову. Наприклад, якщо рецензент коду накинув мене на те, що я не використовую значення, що повертається printf(), я дивно дивлюся на них і ставлю під сумнів їхню тверезість, а потім запитаю: "Добре, чудово, що я можу зробити, коли нічого не можна надрукувати на консолі, що б бути корисним? "

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

І все-таки я думаю, що ви можете скористатися третьою стороною для аудиту. Більшість програмістів, які вартують своєї солі, звернуть увагу на законні занепокоєння, навіть якщо вони відкинуть наполовину неправдиві (такі, як я б у своєму printf()прикладі).

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

Одним із підходів було б використання інструментів для ворсинок, таких як FxCop та StyleCop, які стосуватимуться статичного аналізу передньою базою коду. Це дасть вам вихідну точку для обговорення звітів, створених за допомогою інструментів.

Іншим підходом було б перетворення оглядів коду на огляди дизайну. Дизайнерські огляди частіше тоді не розкривають проблеми задовго до того, як код навіть буде написаний. Якщо програміст має дизайн, він може працювати з ним, вони, як правило, набагато ефективніші у своєму підході, і помилки зменшуються через це. Коли дизайн не існує, він стає сприятливим у підході, і код страждає від збільшення кількості помилок. Перегляньте проблеми в огляді дизайну, перш ніж вони з’являться в огляді коду, переконавшись, що кожен з вас має конкретну конструкцію для втілення; UML - ваш друг тут, а такі інструменти, як мамлет , швидко і швидко користуються.

Погана новина полягає в тому, що для ефективної участі в оглядах коду вам доведеться вивчити VB. Також буде корисно використовувати VB в якомусь проекті (не обов’язково для виробництва).

Хороша новина полягає в тому, що після того, як ви це зробите, деякі з того, що ви дізналися, все ще будуть корисні при переході на C #.

Думка, яку ви повинні постійно дотримуватися при проведенні експертної оцінки:

"Я НАЙКРАЩИЙ ОДИН ПІДТРИМАТИ ЦІЙ КОД!"

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

Якщо ви не можете програмувати в VB, ви не можете підтримувати код, і ви не кваліфіковані для того, щоб бути рецензентом.

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

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

Я б почав із вибору існуючих рекомендацій (я не знаю жодних стандартів кодування VB.net, але Google дав мені:

• Вказівки щодо кодування VB .Net
• Підмайстер
• Все в одному кодовому каркасі

Використовуйте інструменти stylecop для VB .net

Проаналізуйте джерела за допомогою NDepend (у ньому є правила щодо циклічної складності, довжини, глибини тощо)

Коли ви зробите це, ви можете сказати, що код відповідає обраним стандартам, він нічого не говорить про правильність функціональності або про код, використовуючи належні принципи OOP. Але принаймні це щось.

Хороший огляд коду стосується речей, які вимагають від вас розуміння мови - належного використання мови, API та бібліотек, стилю, назв змінних тощо - і про те, наскільки добре код вирішує проблему - хороші коментарі, належна архітектура, відповідний дизайн шаблони, враховує всі випадки помилок тощо. Коли ви вперше починаєте робити огляди коду, ви схильні зосереджуватися на попередньому. Їх легше бачити і їх легше підбирати. (наприклад, мені не подобаються ваші імена змінних. Ви повинні використовувати імена стилів XXXX.)

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

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

Перш за все, будьте скромними на цьому етапі. Процес зміни важкий. Навіть якби ви були гуру VB.NET, зміни, швидше за все, не будуть легкими. Людям, які не використовували огляд коду, спочатку це не подобається. Довгі погляди на ваш код - важкий досвід. Щоб побачити цінність і терпіння навколо, потрібен час. Це прекрасний процес, коли ви купуєте, але це займе час.

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

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

Навіть якщо ви вивчите основи VB, виконання огляду коду, не знаючи всіх особливостей мови, не дасть змогу виявити використання небезпечних функцій у мові.

Припустимо, ви не знали, що функція input () в Python 2 насправді оцінювала вхід, перш ніж повернути його, щоб полегшити розбір непорядних типів введення. Тоді код буде вразливим для довільного виконання коду, що дозволяє користувачеві ввести щось __import__('os').execl('/bin/sh', '/bin/sh')на зразок системи Linux, щоб перетворити процес Python в оболонку. Натомість raw_input () слід використовувати для отримання необроблених вхідних даних.

Спроба провести перевірку коду, не знаючи про всі особливості мови, могла не лише завадити вам зрозуміти кращий спосіб провести певну процедуру на мові; це також може призвести до згубних вад безпеки.