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

20

Я разработал нашу текущую архитектуру проекта и начал разрабатывать ее самостоятельно (достигнув чего-то вроде, 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".
  • ... (это, вероятно, не все) .

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

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


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

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

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

Yippie-Кай-яй
источник
7
Почему вы не сели с остальными 4 программистами до того, как ушли в отпуск (или даже до того, как начали проект), и не поговорили с ними о дизайне? Я нахожу, что люди с гораздо большей вероятностью будут уважать стандарты кода и инфраструктуру проектирования, если вы лично включите их в обсуждение и объясните им, почему ваши проектные решения являются подходящими. Возможно, ваш дизайн слишком спроектирован, возможно, у этих ребят есть смысл (хотя они все равно должны были уважать оригинальный дизайн при внесении изменений). Я думаю, что вы должны иметь немедленную встречу, поговорить о том, что вы пытаетесь сделать.
Марти Б
Можете ли вы улучшить название вашего вопроса, пожалуйста? Текущий заголовок является расплывчатым и на самом деле не характеризует ваш вопрос.
Роберт Харви
1
Привет, Yippie-Kai-Yay, из вашего вопроса неясно, что представляет собой практическая, решаемая проблема, которую вы нам задаете. Programmers.SE - это не доска обсуждений, на которой вы можете рассуждать о проблемах дня: можете ли вы определить конкретную проблему, с которой вам нужна помощь опытного программиста, и спросить об этом?
1
@ Марк, я думаю, что, если хотя бы 12 человек считают эту тему полезной и есть что обсудить, закрывать ее просто странно.
Yippie-Kai-Yay
1
Я думаю, что это может быть сформировано в соответствующий вопрос (а не просто закрытый), который касается управления проектами и командной работы, которые являются важными аспектами программирования и разработки.
Росс

Ответы:

18

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

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

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

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

DoubleMalt
источник
Я думаю, что это единственный реальный ответ, учитывая обстоятельства.
Роберт Харви
Когда у меня есть надежные тесты, я не смущаюсь ломать все, когда передается плохой код. Это ключ к поддержанию ремонтопригодности проекта.
Deadalnix
@dead: Хмм, что это вообще значит?
Роберт Харви
@Robert Хорошо, правильно написанные юнит-тесты на самом деле очень хороши для рефакторинга, потому что вы можете легко изменить многие вещи и при этом быть уверены, что ваша программа верна.
Йиппи-Кай-Яй
@ Роберт> Это означает, что вы не должны отказываться помещать некоторый код в корзину, когда он недостаточно хорош. Если у вас есть тщательное тестирование, вы можете заполнить пробелы более качественным кодом и быть уверенным, что он будет вести себя так же, как и остальная часть программы.
Deadalnix
10

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

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

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

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

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

mattnz
источник
Приятные мысли, возможно, мне придется что-то переосмыслить. Спасибо,.
Йиппи-Кай-Яй
8

Пара.

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

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

Карл Манастер
источник
2
Я много слышал о спаривании, но никогда не слышал, чтобы кто-то на самом деле делал это и получал выгоду.
Роберт Харви
4
Это никогда не работает. Когда вы соедините двух лошадей, если они не обладают одинаковой силой тяги, одна из них станет балластом. А в программировании мы говорим о технических навыках, а главное, об интеллектуальных возможностях. Очень редко иметь двух человек, обладающих одинаковыми интеллектуальными способностями, чтобы соединение было успешным, и чем выше интеллект, тем меньше вероятность такого события. Только конвейер может легко использовать несколько участников, это никогда не случается с интеллектуальной работой. Все очень успешные проекты всегда были результатом одного, очень редко двух или более мозгов.
Джин Бушуев
Оно работает. Это работает, если разработчики имеют сопоставимый опыт и способности, и это работает для обоих разработчиков, если навыки не совпадают. Удивительно, как надёжно критики спаривания никогда не пробовали этого. Я сделал это; Я делаю это. Оно работает.
Карл Манастер
@Carl Manaster> Работает с правильными парами. Я сделал это несколько раз успешно, но сейчас я на самом деле медленнее и создаю худший код с моей настоящей парой, чем соло. Поэтому важно, если не капитал, соединиться с нужным человеком.
Deadalnix
@Carl Manaster - я всегда удивляюсь, что люди настаивают на том, чтобы что-то попробовать - на телевидении, радио, форумах, религиозных культах и ​​т. Д. Попытка , известная также как случайное свидетельство, не является доказательством чего-либо, это логическая ошибка. Сначала сделайте убедительное доказательство, затем вы можете поговорить об экспериментах.
Джин Бушуев
7

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

george711
источник
3

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

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

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

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

Фабио Секонелло
источник
2

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

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

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

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

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

Ной Гудрич
источник
1

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

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

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

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

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

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

Нафанаил
источник
1

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

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

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

JeffO
источник