Як мені зайнятися виправленням коду у менш досвідченого програміста?

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

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

Наступна частина цього проекту розпочалася, над якою я працюю. Я відкрив інтерфейс, щоб почати з наступних кроків, і негайно наштовхнувся на проблеми (трохи повільно було трохи заниження, помилки в загальних діях тощо). Я заглянув до коду для кількох питань і виявляю O(n^n)дзвінки, які повинні бути O(n), введіть припущення без перевірки помилок (це в Python), посилання на GUI, додані до оригінального коду тощо.

Тепер я, безумовно, хотів би навчити його, що було не так, і як це виправити, але він вже перейшов до свого наступного проекту, і це було кілька тижнів тому. Боюся, що я скажу "Повернись і зроби це правильно!" (за допомогою звичайно) занадто суворо, і у нас все ще є інші проекти, які потрібно тим часом завершити. Чи варто просто зараз виправити код і спробувати спіймати речі в майбутньому?

Начебто запровадження якоїсь політики перегляду коду може бути корисним на кількох рівнях. Деякі негайні переваги:

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

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

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

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

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

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

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

Люди добре навчаються, коли бачать, як виглядає справді хороший матеріал. Це краще, ніж систематично вказувати на кожен невеликий недолік. Однак O (n ^ n) слід обережно і конструктивно вказати.

Поділіться своїми знаннями.

Я б запропонував йому допомогу в його новому проекті в обмін на деякі вчення від старшого до молодшого.

Чому б не парувати програмування на обох проектах?