«Правильно ли я делаю?»
Вопрос возникает, потому что правильно чувствую хорошо, а это значит, что я мне хорошо.
Для меня как разработчика программного обеспечения быть правильным было несколько узко с точки зрения эффективности, например, лучше алгоритмически для машин или эргономически лучше для разработчиков. Мне потребовалось время, чтобы понять, что получение правильного технического решения - это лишь одна часть уравнения компромисса. В этой статье я пытаюсь перечислить примеры с точки зрения затрат и советы, которые помогли мне их минимизировать.
Стоимость обсуждения
Изменение архитектуры иногда может означать изменение, на обсуждение и реализацию которого уходит месяцы, но которое не приносит немедленной выгоды для пользователя. Хотя это правда, что лучшие функции могут быть созданы на основе изменений на уровне структуры, каждый инженер в конференц-зале имеет альтернативные издержки, связанные с неиспользованием того, что оказывает немедленное влияние на пользователя. Как сообщество, мы склонны подшучивать над сбрасыванием велосипедов в шутливой манере «инженеры - инженеры», но это также влечет за собой реальные финансовые затраты, а также снижает отдачу.
Совет: составьте повестку дня встречи с конкретными целями решения и временными рамками для каждой, чтобы ограничение по времени действовало как оценка масштабов проблемы, так и как механизм принуждения. для принятия решений.
Стоимость усыновления
Переход на новый фреймворк не означает, что все сразу же примутся за него и начнут его использовать. Раньше я думал: «но как ты можешь не попробовать этот крутой новый XYZ ??!» Для большой группы инженеров переход на последнюю версию и обновление до последней версии является препятствием в их повседневной работе, если только преимущества и использование четко сообщаются. Есть менее гламурная, но критическая работа по написанию документации, евангелизации, обучению и поддержке тех, кто хочет полностью использовать результаты проделанной работы. В противном случае это просто кусок кода, который никто не понимает!
Совет: Предоставляйте оценки для принятия и отслеживайте такие задачи, как написание документации и обмен знаниями с большей группой. Парное программирование - также отличный способ привлечь больше последователей и одновременно выполнять работу.
Стоимость сложности
Добавление функции, даже если это изменение в один ряд, не обходится без затрат. Техническое обслуживание сопровождается обратной совместимостью и поддержкой. Каждая строка косвенного обращения и настройки увеличивает мысленные накладные расходы разработчиков. Поскольку кодовая база также увеличивается в размере, у нее также могут возникать проблемы с производительностью, связанные со временем сборки, CI и развертыванием.
Совет. Создайте показатель, который будет служить индикатором сложности. Возможно, это отслеживание времени сборки или внедрение инструментов для статического анализа кода. Даже если это маркированный список разочарований, документирование источника проблемы с помощью достоверных данных может оправдать выделение ресурсов на устранение существующего технического долга или выбор альтернативного подхода, предотвращающего дальнейшее усложнение.
Стоимость включения
Я заметил, что во многих технологических компаниях не хватает разнообразия в командах, отвечающих за архитектуру. На практике важно, кто предлагает и поддерживает идеи. Иногда этот авторитет исходит от положения человека в компании или сообществе, а иногда на него влияют такие факторы, как пол, возраст, раса и образование. Когда направление кодовой базы постоянно формируется одними и теми же голосами в комнате, не только укрепляются стереотипы, но и предлагаемые решения могут также начать отражать личное знакомство или предпочтение существующей парадигмы, независимо от того, решают ли они проблемы. другие сталкиваются.
Совет: При оценке компромиссов выявите потенциальные предубеждения и обсудите с группой, может ли это повлиять на предложение. Избегайте таких выражений, как «кажется естественным» или «это просто кажется правильным». Постарайтесь получить отзывы от инженеров всех уровней, а не только от старших инженеров. Я не думаю, что существует единственное решение для решения проблем инклюзии в организации, но честное общение - хорошее начало.
Цена ошибки
Неинтересно думать обо всех возможных ошибках в нашем коде. Иногда мы даже не знаем, правильно ли мы поступили, пока не реализуем его. Лучше подумать об этом с точки зрения затрат на переключение. Есть ценность в выборе решения, которое позволит вам вернуться к альтернативному подходу.
Совет: когда дело доходит до задач с низкими затратами на переключение, отдавайте приоритет начальной реализации и итерации, а не достижению консенсуса. Получайте отзывы как можно раньше и чаще, вместо того, чтобы пытаться довести до совершенства с первого раза.
Я надеюсь, что эта статья поможет расширить кругозор инженерных компромиссов. Если у вас есть предложения или отзывы, я @kaylie_alexa в Твиттере.
Также спасибо Бену Илегбоду и Марии Казанджиевой за идеи и предложения!
