Как я могу провести рефакторинг кодовой базы, в то время как другие быстро ее передают?

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

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

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

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

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

Вы никогда не «недостаточно велики, чтобы общаться». Если ваши пальцы могут печатать, ваши губы тоже могут говорить. В конце концов, улучшение технологий - это 85% коммуникаций и 15% технических. То, что вы предпочитаете писать код, а не разговаривать с кем-то, не означает, что это хорошая идея. На самом деле общение - это трудная часть того, что вы пытаетесь сделать, но не просто избегайте этого.

Да, филиал является хорошим решением для этого.

Я бы посоветовал вам начать работать над этим в ветке и убедиться, что он HEADв то же время корректно накладывается на ваш текущий уровень (т. Е. Регулярно выполнять повторные проверки и слияния, чтобы убедиться, что вы можете легко применить свои изменения и ваши тесты по-прежнему проходят - - также обратитесьgit rerere за помощью gitс этим). Затем, как только вы закончите, сделайте ребаз и объедините ваши изменения с вашим HEAD.

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

Рассматривали ли вы вариант "Не делай этого пока"?

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

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

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

tl; dr - Похоже, пришло время перейти в высшую лигу. Нанесение помады на свинью не делает ее более красивой, если только вы не увлекаетесь такими вещами ...

Проблема людей

Первая проблема - синхронизация фиксации. Если у вас есть несколько человек, работающих над одним и тем же кодом одновременно, вам нужно только одно правило для предотвращения проблем:

Rule 1: Always pull before you merge/rebase

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

Проблема с кодом

Откуда вы знаете, что сделанные вами изменения не нарушают код?

Простой ответ ... Напишите тесты, чтобы доказать, что они этого не делают. Если вы игнорируете школу мышления TDD (Test Driven Design), весь смысл тестов заключается в том, чтобы добавить уровень проверки, который позволяет изменять код, не нарушая его.

Rule 2: Don't make assumptions, write proofs (ie tests).

В дополнение к этому, перед выполнением перехода к исходному / удаленному мастеру необходимо выполнить полную гамму тестов.

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

Сначала вам может потребоваться некоторая организационная реструктуризация

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

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

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

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

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

Миф о "Мифическом месяце человека"

Верьте или нет, более крупные / более успешные проекты с открытым исходным кодом не работают как демократия. Они работают как иерархия. Заявление о том, что проект не может эффективно выйти за пределы 8-10 разработчиков, наивно. Если бы это было правдой, то таких мегапроектов, как ядро ​​Linux, не было бы. Более глубокая проблема заключается в том, что предоставление каждому обязательного доступа просто затрудняет эффективное взаимодействие.

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

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

Приятно слышать о проекте с открытым исходным кодом, переживающем трудности роста Поздравляю и удачи.

чистый / красивый и, что самое главное, долговременный обслуживаемый код.

По моему опыту, чистый / красивый - враг ремонтопригодного. Красивый код часто:

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

С другой стороны, поддерживаемый код:

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