Как мне исправить код от менее опытного программиста?

Немного предыстории: я один из двух программистов для нашего отдела из 10 человек (остальные художники и менеджмент). Мы вдвоем делаем все необходимое для правильного кодирования и разрабатываем любые проекты, которые появятся. Я занимаюсь программированием около 4 лет, где это его первая «настоящая» работа (как он выразился). Обычно мы работаем над разными проектами в любой момент времени.

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

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

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

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

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

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

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

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

Можем ли мы сделать вывод, что проект «работает» и был выполнен за разумное количество времени (хотя и с некоторыми вопиющими, но исправимыми проблемами проектирования)? Если так, то он в гораздо лучшей форме, чем многие проекты, которые я видел за эти годы.

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

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

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

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

Я предложил бы ему помощь в его новом проекте в обмен на некоторое обучение от старшего до младшего.

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