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

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

Все начинается с потребности

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

У бизнеса обычно есть лучшие навыки, чтобы убеждать инженеров: нам это определенно нужно, мы уверены, что вы сможете решить эту проблему, вы умные инженеры, это ключевая особенность. Напротив, инженеры, которые в среднем более интроверты, менее склонны убедительно парировать нереалистичные запросы.

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

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

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

Инженеры не лучше

Причина непроработанных решений - это, конечно, сами инженеры.

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

Решения остаются с нами надолго, а слишком сложное решение требует более высоких затрат на обслуживание.

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

Как распознать чрезмерно сложную работу?

Обратите внимание на:

  • Ранние и чрезмерные обобщения
  • Преждевременная оптимизация
  • Проектирование с учетом слишком большой гибкости и конфигурации
  • Передовые технологии

Давайте посмотрим на некоторые конкретные технические примеры:

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

Когда вы создаете абстракции для своих модулей (класса, пакета, модуля Python и т. Д.) Без существующего варианта использования. Когда вы реализуете конфигурацию YAML в своем программном обеспечении, когда файла свойств Java будет достаточно для ваших двух параметров конфигурации.

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

Когда вы сначала создаете слои кеша без измерения производительности и оптимизации запросов к БД.

Когда вы решите использовать сильно распределенную базу данных NoSQL перед выполнением любого планирования емкости и сравнения производительности с реплицированной настройкой РСУБД. И вы упускаете из виду недостатки потери ссылочной целостности, транзакционной целостности и последствия конечной согласованности для вашего приложения в случае сети раздел и т. д.

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

Стоимость сложности

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

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

Я не говорю, что не используйте передовые технологии, я говорю, что это:

Всегда знай, что делаешь и зачем ты это делаешь!

Почему инженеры-программисты слишком инженерные?

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

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

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

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

Люди эгоистичны, инженеры надеются, что участие в технологически продвинутом проекте - одна из самых приятных вещей для любого инженера. Лучшая система является передовой, масштабируемой, достаточно универсальной, чтобы быть совместимой с новыми требованиями. Это отказоустойчивый. Он может обрабатывать триллионы транзакций в секунду. Это плохо связано и ориентировано на события, потому что в наши дни это дерьмо. Лучшая система написана на Golang, Elixir или Node.js, потому что только они не масштабируются.

Инженеры хотят обновлять свои знания. Приобретение новых знаний повышает рыночную стоимость разработчиков. Что может быть лучше, чем получать деньги за изучение новых технологий на работе? Существует термин «Развитие, управляемое резюме», но, честно говоря, я думаю, что большую часть времени RDD является скорее подсознательным, чем осознанным решением. Инженеры просто хотят получать удовольствие от своих профессиональных знаний и становиться лучше.

Для инженера жизненно важно всегда развивать свои способности и постоянно узнавать что-то новое.

Но личное развитие не должно ставить под угрозу успешный проект!

Что нужно делать инженеру

Процитируем Википедию по инженерному делу:

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

В первую очередь будьте реалистичны, будьте разумны!

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

Будьте прагматичны! Не выбирайте более сложное решение в угоду тенденциям.

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

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

Рим строили не день. Скорее всего, вы не Facebook, Amazon, Netflix или Google. Не пытайтесь имитировать. Скорее всего, у вас или вашей компании нет таких ресурсов. Но даже им потребовались годы и миллиарды долларов, чтобы добраться туда, где они есть.

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

Прежде чем выбирать «наиболее масштабируемое» решение, выполните планирование емкости. Сколько бизнес-транзакций в секунду у вас будет? Сколько операций чтения и записи БД им требуется? Ваше приложение требует большого количества операций чтения или записи? Какие технологии способны удовлетворить эти требования? Допускают ли ваши бизнес-требования возможную согласованность? Вы будете удивлены, с чем могут справиться реплицированный кластер MySQL и вертикально масштабируемая серверная часть Java.

Вам не нужно расширяться до 10 миллиардов пользователей, прежде чем ваш продукт появится на рынке. Как только у вас возникнет эта проблема, у вас будут ресурсы для решения этой проблемы с производительностью, как это сделали компании FANG.

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

Как инженер, говорите НЕТ нереалистичным бизнес-требованиям, но всегда предлагайте технически более жизнеспособное решение.

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

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

Вывод

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

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

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