Чи добре переглядати програми зі старшими та начальником, навіть якщо це працює добре?

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

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

Вони кажуть, що огляд допомагає оптимізувати виконання програми та запитів, але чи можна віддати перевагу оптимізації над фактичним функціонуванням програми?

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

Хороший код - принаймні:

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

(Деякі з цих вимог насправді перекриваються, але їх добре враховувати окремо ...)

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

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

З позитивнішого боку, сесія також може стати приводом для обміну чудовими практиками / розробками.

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

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

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

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

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

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

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

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

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