Бретт Боскофф

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

Бретт получил степень бакалавра технических наук в области биомедицинской / медицинской инженерии в Университете Вандербильта.

_____________

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

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

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

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

1. Стратегии внедрения: добивайтесь больших успехов или идите домой

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

По мере увеличения вашей скорости исправления могут трансформироваться в функции и превращаться в выпуски грандиозного размера с несколькими зависимостями, прежде чем они будут объединены. Не позволяйте этому случиться! Хороший способ - учесть это на собраниях по планированию спринта. Задайте вопрос: «Как эта функция будет доступна нашей аудитории?» как можно скорее.

Предоставление функций 100% вашей пользовательской базы, вероятно, будет жестокой. Создание тихих стратегий выпуска для сборок с длинным хвостом было невероятно полезным для нас (кашель, кашля, модное слово). Для более немедленных сборок с большим воздействием разработайте план, который будет распространяться на выбранную вами аудиторию - 10%, 20% и т. Д. Когда все стабилизируется, откройте шлюзы наводнения.

2. Модульное тестирование: мы сделаем это, когда у нас будет время.

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

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

3. Один файл Javascript, чтобы управлять ими всеми.

Ах, старые добрые времена, когда 20 000 строк спагетти jQuery запускали большую часть нашего интерфейса. Не делай этого. Если вы работаете над новой функцией для существующей части продукта, выделите ее в отдельный файл. Сделайте его расширяемым для использования в будущем на несуществующих частях вашего сайта. Это правило применяется к интерфейсным, внутренним, CSS-файлам и т. Д. Найдите модульные точки останова и отдельные.

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

Для справки, наш собственный набор правил для внутренних передовых практик Javascript можно посмотреть здесь: http://devhonorcodejavascript.splashthat.com /

4. Помещение новых разработчиков в пузырь

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

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

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

5. Быстрое обучение.

Как можно быстрее избавьтесь от заблуждения о невозвратных затратах. Если вы застрянете на своем пути, то в долгосрочной перспективе вам придется дорого обойтись. Это не означает, что вы должны внедрять новые технологии при каждой возможности - на самом деле я предпочитаю стабильные, приземленные технологии (Дэн МакКинли хорошо осветил эту тему - http://mcfunley.com/choose-boring-technology ). Однако важно понимать, где в вашем процессе / технологии есть слабые места, и совершенствоваться.

Многие из этих изменений будут исходить от новых сотрудников. Будьте внимательны к отзывам новейших умов. Если бы новый сотрудник не подвергал сомнению наш процесс развертывания, мы все равно выполняли бы процесс развертывания вручную из 10 шагов. Или потратите 3 дня на настройку компьютера для нового сотрудника после начала работы.

Воспользуйтесь воспоминаниями.

Я также хотел бы услышать о любых (теперь очевидных) ошибках, которые вы сделали. Пожалуйста, напишите мне на адрес [email protected]