Баланс между настоящим и будущим вашего решения
Одним из наиболее важных аспектов разработки программного обеспечения является принятие технических решений. Принятие решений не зависит от вашей роли и является чем-то, что вы уже испытали или испытаете как часть своего пути в разработке программного обеспечения. Существует множество технических советов, и нет недостатка в предложениях SaaS и Open Source, которые ошеломят вас знаниями и передовым опытом.
Принятие технических решений — это искусство выбора технологии, инструмента, фреймворка, языка программирования, службы, архитектуры или шаблона для научного решения проблемы. Решение может иметь большое значение для того, чтобы сделать вашу жизнь легче, проще, быстрее или медленнее, сложнее и несчастнее в будущем.
Трата времени, ресурсов и энергии на то, чтобы сделать это правильно, имеет большое значение для вашего будущего успеха. Кроме того, технологический ландшафт повторяется и движется экспоненциально, увеличивая путаницу и сложность выбора правильного решения. У меня нет для вас панацеи или блок-схемы принятия решений, которая работала бы во всех ситуациях.
Много раз участвуя в этом процессе, я получил знания, которые помогли мне принять решение объективно, одним глазом глядя на настоящее, а другим на будущее.
Выявление проблем
Хорошо понятая проблема наполовину решена и всегда требует лучших решений. Однако почти каждый раз я видел расползание масштаба. Да, важно думать о будущих последствиях, но в то же время расширение масштабов вашей проблемы приведет только к выбору слишком сложного решения или решению проблем, которых у вас нет в настоящее время.
«Если бы у меня был час на решение проблемы, я бы потратил 55 минут на обдумывание проблемы и 5 минут на размышления о решениях». - Альберт Эйнштейн
Всякий раз, когда люди входят в комнату, чтобы решить проблему, они говорят о приятном, а не о необходимом. Здорово иметь в машине подогрев сидений, но как насчет того, чтобы сначала поговорить о сборке двигателя. Моя любимая партия — это те, кто предлагает решение, прежде чем рассматривать проблему, в конечном итоге превращая проблему в решение, что приводит к напрасной трате времени, усилий и непреодолимому техническому долгу.
Урок, который необходимо получить здесь, заключается в том, чтобы убедиться, что все согласны с постановкой проблемы, масштабом и целями, прежде чем приступать к решению.
Копировать вставить
Компании нанимают людей с опытом, схожим с их проблемами, чтобы они могли применить свои прошлые знания. Это палка о двух концах, потому что вы хотите, чтобы люди с соответствующими знаниями и навыками поделились своей мудростью, чтобы принять обоснованное техническое решение. Тем не менее, в основном это заканчивается копированием и вставкой решения без должной осмотрительности.
Проблемы могут показаться идентичными, но вряд ли они одинаковы в двух организациях. Сопоставление с образцом — это самое простое, и новые сотрудники, как правило, делают это чаще, чтобы подтвердить свои знания и опыт в соответствующей области.
Я поддерживаю то, чтобы люди с соответствующим опытом делились своими знаниями из прошлого, особенно когда проблема, которую вы пытаетесь решить, пересекается с чем-то, что они уже решили. Как говорится, дьявол кроется в деталях, поэтому лучше решать проблемы из вашего предыдущего решения и разрабатывать что-то, относящееся к проблеме, а не просто копировать последний ответ.
Эмоциональный выбор
Люди — существа эмоциональные, и, как технологам, свойственно привязываться к технологии, языку, структуре или шаблону. Кроме того, легко увлечься последними предложениями в области технологий. Мне нравится быть в курсе новинок индустрии и оценивать грядущие тенденции, но в то же время я не привязываюсь к этому.
У меня было несколько бесед с людьми, которые предлагали что-то, потому что они слишком привязаны к этому или чувствуют себя комфортно.
Давайте использовать React, потому что он превосходен. Я использовал его в прошлом, и мне очень нравится разрабатывать приложения с его помощью.
Это не аргумент и довольно наивно для принятия решений. Нет никакой очевидной причины для предпочтения, и это скорее эмоционально, чем логично. Вместо этого мы должны поддерживать выбор, основанный на аналитических обсуждениях и данных.
Предвзятый выбор приводит к техническому долгу, неэффективным решениям, уменьшению принятия и зависимости от одного человека, который это предложил. Ни это разумно, ни это жизнеспособно для решения проблем.
Всегда требуйте оценки на основе данных, чтобы убрать из нее эмоциональный аспект. Несколько способов решить одну и ту же проблему, но логическая оценка каждого варианта только поддержит вашу цель. Как разработчику, то, что выгодно вам, может не подойти вашей организации.
Шип
Быстрая, грязная и хакерская оценка намного лучше, чем отсутствие ранней оценки вашего выбора решения. Инновация Extreme Programming (XP), всплески стали нормой для agile-команд для оценки технологий, фреймворков и дизайна, прежде чем передавать их в производство.
Неудача быстро дает обзор недостатков ваших технологических предпочтений, позволяя вам либо двигаться дальше, либо жить с ними без слепой зоны. Всегда желательно знать ограничения заранее, а не сталкиваться с препятствиями позже.
Я участвовал в реализациях, которые пропустили это из-за сжатых сроков, и в итоге они стали хитами. Если вы потерпите неудачу на ранней стадии, не вложив слишком много ресурсов, вы можете пропустить шип.
Для более крупных проектов или программ может быть сложно провести проверку концепции для каждой части; полезно определить наиболее важные аспекты, а затем объявить, что нам нужно сосредоточиться на них больше, чем на других.
Полезный, масштабируемый, ремонтопригодный
Наиболее игнорируемой частью технических дискуссий является удобство использования, масштабируемость и ремонтопригодность. Техническое решение с низким уровнем внедрения — не очень хорошее решение. Простота использования вашего инструмента, фреймворка или языка так же важна, как и любая другая функция, которую они предоставляют. Опыт разработки не должен страдать, так как он напрямую влияет на мораль команды.
Разумные решения настроят вас на светлое будущее, если вы сбалансируете свои текущие желания с будущими потребностями. Вы проектируете систему для текущей нагрузки 1000 пользователей в секунду. Примите во внимание точки шкалы, чтобы вы могли справиться с дополнительной нагрузкой на вашу систему. Однако разработка решения, рассчитанного на 1 миллиард пользователей в секунду, приведет лишь к дорогостоящему и неэффективному использованию ресурсов. Это хорошая проблема в будущем, поэтому ваш сервис популярен.
«То, что работает в масштабе, может отличаться от масштабирования того, что работает. Пилотные проекты часто успешны, а масштабирование часто терпит неудачу при изменении контекста». — Рохини Нилекани
Никто не любит просыпаться в 3 часа ночи, чтобы сортировать и решать инцидент. Вот где в игру вступает ремонтопригодность вашего решения. Потратьте время на оценку NFR для вашего выбора. «Вы представляете риск? Является ли это решение оптимизированным? Это самоисцеление?» являются вопросы, которые должны быть оценены.
Существующие навыки, технологии, фреймворки
Оценка вашего текущего стека технологий и его компонентов помогает принять лучшее техническое решение. Если ваш технический стек уже использует Python, нет смысла вводить новый язык программирования, если вы не мигрируете. Точно так же, если ваша команда уже имеет опыт работы с инфраструктурой или технологией, рассмотрите их влияние на ваше решение.
«Лучшая часть — это отсутствие части. Лучший процесс — это отсутствие процесса». — Илон Маск
Повторное использование существующих шаблонов и моделей поведения — это блестящий и быстрый способ быстрее приносить пользу. Не путайте это с копипастом, который передает сообщение о приближении решения проблемы.
Вместо этого не изобретайте велосипед; использовать существующие знания, технологии и процессы для поиска инновационных решений ваших проблем. Добавление ненужных компонентов в ваше решение означает увеличение сложности и снижение удобства сопровождения в долгосрочной перспективе.
Социализируйте свое решение
После того, как вы приняли решение, распространите его и доведите до сведения заинтересованных сторон. Самая распространенная ловушка среди организаций — найти решение и не поделиться им. В конце концов, это становится шоком для затронутых членов, вызывая недоверие и дисгармонию. Наоборот, если вы поделитесь им заранее, вы заработаете их доверие, лояльность и отзывы, заставив их почувствовать себя частью процесса.
Ранняя обратная связь помогает устранить потенциальные проблемы и добиться принятия решения. Не забывайте, что реализация так же важна, как и принятие решения. Стороны, задающие тон, возможно, не реализуют его. Вовлечение всех заинтересованных сторон на раннем этапе остановит игры с обвинением и создаст у них чувство сопричастности. В конце создайте ADR вашего решения, чтобы будущие участники могли понять его обоснование.
Заключение
Принятие технических решений — это сложный процесс, которым занимается каждая организация, чтобы последовательно и последовательно создавать ценность. Это сложный, но полезный по своей природе для отдельных лиц и команд. Балансировать между прошлым, настоящим и будущим — непростая задача, требующая терпения, понимания и позитивного отношения к решению проблем. Решайте мудро.
«Вы не можете принимать решения, основываясь на страхе и возможности того, что может произойти». ― Мишель Обама
