Как сохранить согласованность в архитектуре приложения по мере роста команды?

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

Перенесемся через 4 года и приобретением позже, у меня есть команда из 5 человек, и часто это похоже на дикий запад. Люди, принимающие любое дизайнерское решение, им нравятся: целочисленные значения и перечисления для типов БД в одном месте и строки в другом, этот каркас для проблемы, а затем другой каркас для той же проблемы в другом месте и т. Д.

Как мне обеспечить согласованность? Для меня это важно, но члены моей команды, похоже, согласны с методологией «если это работает, это работает».

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

Что делает тебя таким особенным?

Мой процессор говорит, что работает, и я хочу домой. Почему ты мне мешаешь?

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

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

Лучший способ сделать это - общаться раньше. Не говорите мне «мы не используем строки для наших типов БД в этом магазине» через 6 месяцев после того, как я решил эту идею. Сказать, что это было похоронено в документации на 2 года, не является основанием для того, чтобы позволить мне это сделать.

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

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

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

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

Предоставь мне возможность навязать свое видение, помогая мне увидеть твое, и мы отлично ладим.

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

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

Я знаю, откуда ты, потому что я был там. Вы имели контроль, и теперь это ушло. Вы хотите это вернуть. Ну, переживи это. Теперь у вас есть команда. Их не нужно контролировать. Что им нужно, так это лидерство. То, что вам нужно, это не контроль. Это влияние. Это работает лучше и намного меньше работы. Освойте это и расслабьтесь. Это должно быть весело.

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

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

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

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

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

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

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

И я не имею в виду, что только вы должны выполнять проверки кода. Каждый должен просмотреть код всех остальных. Это распространяет знания о системе по всей команде, но также создает ситуацию, когда Кэрол просматривает код Боба и говорит: «Я вижу, что вы использовали целое число там. Я всегда использую перечисление». Они обнаружат несоответствия, которые вы видели, и, если им все равно, они поймут, что каждый должен попасть на одну и ту же страницу.

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

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

Получите выходные данные инструментов, записанные в документе «системы показателей», например, на листе Google со строкой на единицу (например, на «приложение» или проект, API или другое), с колонками для различных метрик / стандартов. Это даст людям представление о том, какие стандарты существуют, насколько хорошо они приняты и т. Д. И обеспечит некоторый порядок в хаосе.

Вы также можете обновлять столбцы вручную, но удачи в их обновлении: D

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

1 - Создать и следовать соглашениям кодовой базы

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

2 - Внедрить четкие программные архитектуры

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

3 - чем меньше, тем лучше: языки, рамки и инструменты

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

4 - Вовлекайте свою команду в решения по проектированию системы

Наиболее эффективный способ создания общей среды знаний - это вовлечение команды во все решения по проектированию системы. Преимуществ много:

• Люди чувствуют себя ценными и частью команды
• Важные решения оспариваются всей командой до принятия
• Сильные и слабые стороны системного дизайна понятны каждому
• Создает чувство коллективной ответственности и доверия

5 - Правило олл-ин

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

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

Я недавно написал сообщение в блоге на эту тему, вы можете найти подробную информацию по этим темам здесь: https://thomasvilhena.com/2019/11/system-design-coherence