Имея дело с коллегами при разработке, нужен совет [закрыто]

Я разработал нашу текущую архитектуру проекта и начал разрабатывать ее самостоятельно (достигнув чего-то вроде, revision 40) .

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

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

Теперь, что было сделано:

• Я запустил несколько реализаций соответствующих интерфейсов, портировал несколько удобных библиотек и написал заглушки для некоторых частей приложения.
• У меня был документ, описывающий стиль кодирования и примеры использования этого стиля кодирования (мой собственный письменный код).
• Я заставил использовать более или менее современные C++методы разработки, включая no-deleteкод (обернутый с помощью умных указателей) и т. Д.
• Я задокументировал цель конкретных реализаций интерфейса и то, как они должны использоваться.
• Модульные тесты (в основном интеграционные тесты, потому что не было много «реального» кода) и набор макетов для всех основных абстракций.

Я отсутствовал в течение 12 дней .

Что у нас сейчас (проект разрабатывали еще 4 члена команды):

• 3 разных стиля кодирования по всему проекту (я думаю, два из них согласились использовать один и тот же стиль :) , то же самое относится и к именам наших абстракций (например CommonPathData.h, SubwaySchemeStructures.h) , которые в основном являются заголовками, объявляющими некоторые структуры данных.
• Абсолютное отсутствие документации по недавно реализованным деталям.
• То, что я мог недавно назвать, single-purpose-abstractionтеперь обрабатывает как минимум 2 различных типа событий, имеет тесную связь с другими частями и так далее.
• Половина используемых интерфейсов теперь содержит переменные-члены (sic!).
• Использование сырых указателей практически везде.
• Модульные тесты отключены, потому что " (Rev.57) They are unnecessary for this project".
• ... (это, вероятно, не все) .

История коммитов показывает, что мой дизайн был истолкован как излишнее, и люди начали комбинировать его с личными велосипедами и переопределенными колесами, а затем возникли проблемы с интеграцией фрагментов кода.

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

Можно ли что-нибудь сделать в этом случае?

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

По сути, я думал, что хороший (ну, я сделал все, что мог) старт для проекта, вероятно, приведет к чему-то хорошему, однако я понимаю, что ошибаюсь.

Рефакториться безжалостно, чтобы выйти из беспорядка!

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

Хуже всего то, что вам нужно вернуться к 40-й редакции, и ваши программисты провели 12-дневную тренировку, которая дала им лучшее понимание предмета.

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

Перефразируя ваш вопрос: «Я ушел на пару недель и не согласен с тем, что сделала моя команда, когда меня не было, как я могу заставить их делать то, что я хочу, когда меня нет здесь?»

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

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

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

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

Пара.

То, что вы описываете, это много делать правильно, технически, соло . Да, вы пытались документировать, пытались навязать стандарты - но вы (по-видимому) не смогли связаться.

Ну, ваша команда только что общалась с вами, довольно громко. Они сказали: «Эй, Йиппи, ты не общаешься!» Самая мощная форма общения, которую я знаю, - это спаривание. Пара. Пока они не получат это, или пока они не убедят вас сделать это иначе.

Как Брукс говорил нам в течение последних 30 лет, концептуальная целостность является наиболее важной частью любого проекта. Для любой нетривиальной и полной подсистемы должен быть ровно один человек, ответственный за ее разработку и уполномоченный руководить ее реализацией. Что-то пошло не так с этой частью в вашем проекте. Как бы то ни было, единственным решением является откат к коду в репозитории, который существовал до того, как это произошло. Потеря 12 дней ничто по сравнению с затратами на поддержание нарушенного дизайна. Я также подумал бы о том, как отстранить людей, вовлеченных в этот приворот, от дальнейшей работы над проектом, поскольку они оказались некомпетентными.

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

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

Со временем вы можете вернуться к другим частям кода, которые являются проблемными, и снова переназначить оригинального (плохого) автора. Через некоторое время они осознают преимущества хорошей работы с первого раза.

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

Одна вещь, о которой я не упомянул, но которая недавно возникла, когда я работаю, это проблемы «бункеров разработчиков» и «бай-инов».

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

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

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

Короче говоря - если вы хотите, чтобы качество кода повышалось и было последовательным, я бы посоветовал вам собрать всю команду для разработки стандартов, стилей и т. Д. Кроме того, каждый раз, когда кто-то собирается создать фундаментальную или основную часть вашего приложения, я бы посоветовал ответственному лицу руководить всей командой при разработке классов и т. д., так что в конце концов вся команда должна принять участие в общей архитектуре приложения. Кроме того, если они знают, как работает код другого члена команды, у них будет меньше шансов внедрить его снова так, как это работает для них.

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

Учитывая, что вы находитесь в сжатые сроки, вам, возможно, придется отправить код как есть, и рефакторинг (переписать?) После выпуска.

Это также звучит так, как будто вам нужно определить и применить некоторые распространенные методы работы с кодом. У вас есть процесс проверки кода на вашей работе? Если нет, звучит так, как будто сейчас самое время для реализации. Кстати, обзоры кода - отличный способ научить начинающих разработчиков передовой практике.

РЕДАКТИРОВАТЬ:

Недавно я столкнулся с подобной ситуацией. Руководство моей компании настояло на том, чтобы мы использовали контрактных разработчиков для написания большей части нашего приложения. Код, который они создали, был ужасен (мягко говоря), но мы были вынуждены его использовать. На сегодняшний день я переписал 80% кода, написанного для нас подрядчиками. Он был полон ошибок и его невозможно было расширить новыми функциями. Еще через пару месяцев моя команда переписает все это, фактически превратив деньги, вложенные в разработку контракта, в пустую трата времени.

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

Вы сделали усилие, но факт, что никто не отвечает . «Но я предпочитаю свой стиль кодирования», не дерьмо. Я хотел бы работать над моими личными проектами весь день и все еще получать деньги.

Надеюсь, вы можете представить это властям и показать им, что можно было сделать в отличие от Шоу Дикого Запада, которое продолжалось две недели. Похоже, вам придется что-то вытащить за дверь, но продолжайте следить за проблемой отсутствия контроля и последовательности.

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