Что не стоит делать во время проектирования

Rate this post

Если вы нетехнический специалист, но все же вовлечены в проектирование и разработку программного обеспечения, не спешите закрыть статью. Сначала поговорим о так называемых soft skills ошибках, которые случаются в процессе консалтинга, а затем перейдем к техническим.nnНадеюсь, статья поможет вам избежать неудач.n

Типичные ошибки в процессе консалтинга

Ошибка 1. Делать то, что просит клиент, а не то, что ему действительно нужно

Прийти, послушать клиента и сразу начать работу согласно его инструкциям – самая распространенная ошибка во время pre-sale фазы. Вы можете возразить, ведь мы ему нужны для того, чтобы сделать то, что он хочет. Но нет.nnСамое первое и самое важное — выяснить реальную бизнес-проблему клиента и понять, как ее решить. Это задача бизнес-аналитика и архитектора. Наружных консультантов нанимают именно для этого.nnЕсли бы заказчик имел более глубокую экспертизу и сам мог понять, что у него не так, наша помощь ему не нужна. А если он выделил бюджет и нанял нас, значит, уже пытался решить эту проблему самостоятельно (или нанимал другого партнера), но из этого ничего не вышло.nnОднажды к нам пришел клиент с проблемой, что все, к кому он обращался раньше, предлагали слишком сложное и дорогостоящее решение под его задачу. Мы начали разбираться. Оказалось, что на тот момент заказчики хранили и редактировали данные в Excel и хотели иметь тот же функционал, но чтобы это было веб-приложение в облаке. Мы допустили стандартную ошибку — не уточнили, зачем это, и просто просчитали два варианта реализации приложения, которое вроде бы было нужно. Обе суммы были намного выше, чем ожидалось.nnМы уже почти простились с заказчиками, и тут я спросил, чем их не устраивает работа в Excel. Выяснилось, что им требовалось, чтобы данные постоянно копировались и была возможность одновременного доступа к ним из разных мест, так чтобы данные были одинаковы (consistent) для всех пользователей. А еще клиенты очень неплохо разбирались в SQL. И здесь решение пришло само собой — сделать миграцию данных в SQL-базу, которая будет храниться в облаке и будет копироваться автоматически, а пользователи будут иметь одновременный доступ с разных точек планеты. Это решение мало похоже на коммерческое приложение, но это именно то, в чем нуждался клиент и именно за ту цену, которую он мог заплатить.nnЕсли мы ясно понимаем проблему, то можем предложить лучшее и дешевле решение.n

Ошибка 2. Не готовиться к сессиям с потенциальным клиентом

Казалось бы, к нам клиенты приходят за экспертизой, которая уже у нас есть, зачем готовиться? Но здесь речь о том, что нужно проанализировать контекст, углубиться в конкретную область и проблематику, иначе вы не сможете увидеть лучшее решение.nnПодготовка к pre-sale. Первая встреча с клиентом – это этап pre-sale. От нее в значительной степени зависит, подпишут ли с вами контракт. Поэтому нужно собрать как можно больше информации о самом проекте, компании, сфере ее деятельности, конкурентах, аналогичных решениях на рынке. Ведь без этих знаний мы не сможем быть полезны. К тому же, понимание контекста поможет подобрать оптимальную проектную команду.nnЧто бывает, если не приготовиться? Представим, что к вам обратилась компания, которой необходимо развернуть e-learning платформу для клиентов. Специалисты, ранее с таким не сталкивавшиеся и не исследовавшие эту сферу, предлагают с нуля разработать собственный продукт, а не адаптировать готовый. Безусловно, это долго и дорого. Здесь еще предстоит учитывать, что компании обычно ведут переговоры с несколькими консультантами. Конечно, они выберут тех, кто предложит более быстрый и более дешевый вариант.nnДругой возможный сценарий — у заказчика низкие показатели производительности (performance), он хочет выявить причину и устранить ее. Самое рациональное решение – подключить системы, помогающие найти подобные проблемы, внедрить тестирование нагрузки (Performance Testing) и выяснить их причину. Для команды консультантов, не являющихся экспертами в таком типе тестирований, это неочевидно, поэтому они предлагают провести длинную и дорогую discovery-фазу. Вряд ли клиент согласится.nnПоэтому перед pre-sale сессией тщательно изучите информацию, которую можно найти в интернете, напишите письмо клиенту с уточняющими вопросами, можно провести короткий звонок, чтобы узнать больше деталей, прежде чем начинать обсуждать технические нюансы и делать конкретные предложения.nnПодготовка к discovery-фазе. Эта тема заслуживает отдельной статьи, но вот основные, пункты:n

Уделите еще больше внимания изучению информации о клиенте и проекте, чем при подготовке к pre-sale. На этом этапе у вас должно быть уже больше контекста и возможностей отыскать данные.
Подберите команду (об этом подробнее поговорим дальше).
Подготовьте адженду – это как бы очевидный этап, но его часто пропускают, особенно начинающие. Были даже ситуации, когда команда прилетела к заказчику за океан и стучала в закрытую дверь офиса, поскольку заранее не согласовала адженду. Чтобы во время discovery не возникло недоразумений, советую сюда вносить такую информацию по каждой встрече:n
- время, продолжительность;
- перечень пришедших стейкхолдеров от вас;
- список стейкхолдеров со стороны клиента;
- вопросы к обсуждению;
- ответственный эксперт с вашей стороны (если будете обсуждать архитектуру, это должен быть архитектор, если функциональные требования — бизнес-аналитик).

nПопросите менеджер со стороны клиента согласовать график с ключевыми лицами для каждой встречи и запланировать встречи в календаре.nnТакая подготовка значительно повысит шансы на успех.n

Ошибка 3. Неправильно выбранная проектная команда

На pre-sale должны быть привлечены специалисты, которые не только имеют высшую техническую экспертизу, но могут говорить на языке бизнеса и понять бизнес-проблемы.nnЧто может пойти не так, если на первой встрече будут чисто технические люди? Возможно, вы даже припомните себя в прошлом. Когда такой эксперт видит архитектурную проблему, он стремится переписать все с нуля. На его взгляд, это единственное правильное решение. Стоимость и продолжительность работы не учитывается. Скорее всего, бизнес не поддержит такую идею и потенциальный клиент уйдет от вас.nnЕсли говорить о discovery, то главные действующие лица здесь:n

Архитектор закрывает нефункциональные требования и дизайн.
Бизнес-аналитик – функциональные требования и потребности бизнеса.
Технические эксперты в узкой отрасли в зависимости от потребностей проекта.

У каждого члена команды должна четкая роль. Иначе могут возникнуть две ситуации:n

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

Ошибка 4. Не определить четкие измеренные значения нефункциональных требований

Одна из главных обязанностей архитектора при консалтинге — это собрать нефункциональные требования (non-functional requirements), их еще называют атрибутами качества (quality attributes). Это тема, на которую люди пишут целые книги. Но разберемся хотя бы в основных ошибках, существенно влияющих на успех проекта.nnСпрашивая у клиента требования к качеству будущего решения, часто в ответ можно услышать, что оно должно быть быстрым, безопасным, что код должен быть качественным и т.д. Принимать это как исчерпывающий ответ – огромная ошибка. Следует договариваться о четких критериях, которые можно измерить. Иначе в определенный момент окажется, что понятие «быстрое приложение» вы с клиентом понимаете по-разному. Но уже будет поздно что-нибудь исправлять.nnНо согласитесь, что правильно задокументировать требования к качеству – это всего лишь пол пути к успеху. Важно, чтобы архитектор правильно с ними работал.nnЗвучит сложно, поэтому рассмотрим снова на примере. Было обычное discovery. Мы с клиентом начали обсуждать нефункциональные требования. На тот момент уже было понятно, что нужно работать с сервисами AWS, чтобы снизить затраты на DevOps и настройку инфраструктуры. Когда пришли к обсуждению доступности (availability) приложения, клиент сказал, что хочет 99,98%.nnНа мой вопрос, почему такая цифра, он не ответил ничего существенного, только сказал, что где-то слышал и все. Для общего понимания здесь стоит отметить, что в общем-то те сервисы Amazon, которые мы собирались использовать, имели доступность 99,95%. Когда я начал ему объяснять, что для обеспечения доступности 99,98% нам нужно будет делать нестандартное решение, значительно повысит стоимость проекта, заказчик согласился на 99,95%. Если бы мы это не обсудили, то либо проект в конце концов обошелся бы клиенту гораздо дороже, либо он остался бы недовольным нашей работой.n

Типичные ошибки в дизайне архитектуры

Ошибка 1. Не думайте о безопасности на этапе дизайна архитектуры

Все проекты, с которыми я сталкивался, имели проблемы с безопасностью. Даже мировые известные бренды их имеют, что уж говорить о меньших компаниях.nnБольшинство проблем возникает из-за неправильного дизайна системы в начале проекта. Как обычно разрабатывают проект? Приблизительно так: сейчас быстро напишем функционал, проверим, работает ли он, и если все хорошо, то в самом конце прикрутим авторизацию. Затем оказывается, что приложение должно поддерживать несколько тенантов (tenants), быть совместимым с GDPR и так далее. И чтобы не переписывать всю аппликацию, разработчики понемногу добавляют быстрые, но не самые лучшие решения в виде атрибута, идущего через несколько десятков методов, или проверки ролей пользователя, прибитой гвоздями в коде перед вызовом каждого контроллера. И еще много вещей, которые вы сами видели не раз.nnПонемногу приложение обрастает такими быстрыми решениями и превращается в груду кода, с которой уже сложно что-либо делать. О микросервисах речь даже не идет, поскольку, чтобы отделить хотя бы часть функционала, нужно переписать пол аппликации. Что с этим делать? Здесь уже ничего не поможет, нет серебряного шара. Большинство проектов с такими проблемами начинались в качестве стартапов, где о безопасности думали в последнюю очередь, из-за чего потом получили много проблем.nnПоэтому как архитектор или технический лидер, проектируя систему, на старте сделайте так, чтобы ваш функционал безопасности не был жестко связан с бизнес-логикой и при необходимости мог расширяться. Если в будущем вы решите добавить функционал SSO, несколько тенантов или многофакторную аутентификацию, это можно будет сделать без труда.nnЕсли вы уже получили проект в таком состоянии, то могу вам только пожелать терпения. Ибо, как я уже сказал, универсального решения не существует.n

Ошибка 2. Затруднения с моделями данных

Еще одна большая проблема – это неправильное использование базы данных. А если есть выбор между SQL и NoSQL, то уже есть две проблемы.nnМы используем SQL-базу данных как NoSQL-решение. Несколько раз мне случались решения, когда SQL-базу пытались использовать в качестве NoSQL-решения. Может быть, вы тоже такое видели.nnТаблицы на 200–250 столбцов, да еще называются column1, column2 и т.д. Естественно, в этих таблицах полная денормализация без всякой согласованности (consistency) данных. А еще можно встретить объединение двух таких таблиц.nnВторая реализация этого антипатерна выглядит следующим образом. Есть только несколько столбцов, например id, refId, тип значения и самое значение. И как вы уже поняли, объект собирается за refId из многих строк в таблице, затем для каждого атрибута в этом объекте получается его значение и тип.nnКонечно, как во время первой, так и во второй реализации возникают проблемы с производительностью и поддержкой кода.nnВ большинстве ситуаций здесь дела немного лучше, чем с безопасностью, потому что такие изменения легче локализовать и сделать необходимые исправления. Сделайте отдельный слой кода, который будет отвечать за доступ к этим данным и, если возможно, используйте NoSQL-базу данных для таких случаев. Этот вариант подходит, если вам не нужно много join-операций и генерации разного типа отчетов.nnЕсли это новый проект, то после вышеописанных примеров и проблем всем очевидно, что лучше потратить время архитектора и бизнес-аналитика на дизайн моделей данных. Ибо в будущем такие незначительные вещи могут привести к большим проблемам на проекте.nnИ это ответ на вопрос, стоит ли привлекать архитектора и бизнес-аналитика на последующие фазы имплементации после discovery, команда ли разработчиков сама все сделает как следует.nnПользуемся NoSQL базой данных, но что-то пошло не так. Конечно, что думать? Берешь NoSQL-базу данных и никаких проблем. Она и хорошо масштабируется, и позволяет легко работать со структурами данных, что не положишь туда, все будет сохранено. Так думает большинство малых проектов и стартапов. И это было бы, если бы они со временем не превращались в коммерческие проекты со более сложной бизнес-логикой.nnВот несколько примеров, когда разработчики и архитекторы вовремя не поняли, что нужно изменить базу данных, пока не стало поздно. Если вы замечаете такую логику и у себя в коде, тоже стоит задуматься.n

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

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

Ошибка 3. Наш малый стартап превратился в успешный, но громоздкий монолит

Здесь можно упомянуть все вышеописанные проблемы и ошибки, а также те, что будут дальше в этой статье, потому что такие проекты это учебник о том, как делать не надо. Но сюда я хотел бы добавить больше психологическую, чем техническую проблему.nnВозможно, вы замечали, что если пытаетесь убедить заказчика в необходимости переделать части проекта, например вынести определенную логику в отдельный сервис, то сопротивляетесь со стороны архитектора или CTO компании. Они как бы понимают потребности в изменениях, и с точки зрения бизнеса это рационально, но не решаются сделать первый шаг.nnВсе потому, что они писали этот код три года назад. А как же можно «убить» собственного ребенка? Она же так хороша и в общем работает. Все сводится к «на этот раз еще допишем кусочек функционала, а в следующий раз уж точно вынесем в отдельный сервис».nnИ это повторяется всякий раз. Каждый такой кусочек кода – это плюс несколько недель в копилку технического долга. Каждое такое решение делает поддержку существующего функционала и разработку нового все более сложной и дорогой.nnВозможно, вы видели такие проекты, на которых только для поддержки и исправления ошибок могут работать до двадцати человек. Разработчик тратит неделю на настройку среды разработки с нуля. А чтобы найти ошибку, а тем более ее исправить, нужно еще не меньше недели. Вот в таких монстров и превращаются стартапы, в которых действуют по принципу «а может, допишем еще кусочек кода».nnЧто делать? Есть, по крайней мере, две опции.nnДля малых проектов и команд – когда наступает тот же момент вносить изменения в дизайн проекта, технический лидер в пятницу вечером говорит всей команде больше не трогать код до понедельника. ~~пиво~~, кофе и за выходные вносит существенные изменения в проект Помню, сам так поступал.nnДля крупных коммерческих компаний нужно иметь список задач с техническим долгом проектов, который будет содержать все необходимые изменения в архитектуре и дизайне. И команда часть рабочего времени (скажем, 10–15%) будет тратить на задачи из этого списка.n

Ошибка 4. Мы еще не в продакшене, но уже есть проблемы с производительностью (performance)

Это обычная ошибка. Не поверил бы, что такое бывает, если бы не видел подобных кейсов.nnОднажды нас позвали улучшить производительность проекта. Проблема была такова: проект еще не в продакшене, но его тестировали на 200 пользователях и выявили проблемы с производительностью, запуск состоится через несколько месяцев, после чего еще через несколько месяцев ожидается 5–10 тыс. пользователей.nnМы начали разбираться. Быстро нашли много проблем с производительностью, и по коду было видно, что его никто сильно и не старался писать под более-менее нормальные нагрузки. Это было удивительно, поскольку те, кто за это отвечал, могли выполнить работу гораздо лучше. Надо было понять, почему так произошло.nnОказалось, что этот код писали для проверки концепции (Proof of concept) и не предполагалось, что его будут использовать на коммерческом проекте. Но заказчик имел доступ к коду, потому что вся работа велась в клиентской среде. И он решил довести его до презентабельного облика и выходить с ним в продакшен. Однако после тестирования на небольших нагрузках понял, что такой подход не работает, и нужно улучшить производительность.nnВсе умные книги говорят: если вы пишете какой-нибудь POC или Spike, то должна быть мертвая ветвь с кодом. Его нужно выбросить на свалку и никогда не использовать в коммерческом проекте.nnЕще один пример, показательный как для этого раздела, так и для предыдущего. Как-то под Новый год мы с коллегой писали качественный, хороший код, как следует делать для коммерческого проекта. Работали над ним вдвоем в течение двух недель. А когда начали тестировать его даже на малых нагрузках, увидели, что производительность была вдвое ниже ожидаемой. Проведя исследования, мы нашли решение для производительности, подходящее гораздо лучше. Ошибка была в том, что мы не совершили быстрый РОС и не протестировали производительность до того, как писать код. Но мораль этой истории другая.nnМы не постеснялись сказать заказчику, что этот подход плохой, что мы допустили ошибку и месяц труда одного человека надо выбросить в мусорник. Хотя могли это скрыть, сделать какие-нибудь улучшения и это не было бы сразу заметно. Проблемой уже стало бы в продакшене на больших нагрузках. Но какую бы цену пришлось заплатить в этом случае?nnПоэтому не стесняйтесь выбросить код, который либо изначально не был предназначен для коммерческого проекта, либо так получилось, что он плохой и приведет к проблемам в будущем. Это лучше, чем обрекать на вечные мучения разработчиков, которые будут его поддерживать.n

Ошибка 5. Мы уже в продакшене, но до сих пор не знаем, почему у нас проблемы с производительностью

В таких случаях все (или почти все) написано хорошо, как должно быть в коммерческом проекте. Но проблемы с производительностью все равно возникают. Когда было 500 пользователей, все работало нормально, а когда стало 200 тыс., замедлилось неизвестно почему. Знакомая картина?nnГлавная ошибка таких проектов состоит в том, что они слишком поздно начинают думать о производительности. Эти вопросы нужно задавать, когда вы только стартуете разработку:n

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

Могу дать несколько советов для таких кейсов. Конечно, лучше реализовывать это на этапе разработки, но для уже готового проекта они тоже подходят.nnЕще когда начинаете проектировать приложение, подумайте, как вы будете измерять и контролировать метрики производительности на уровне базы данных, сервисов, инфраструктуры и т.д. Есть коммерческие решения, такие как New Relic, Datadog, которые без больших затрат времени помогут вам все настроить. Если вы не хотите за них платить, можете развернуть схожие системы сами, но это займет больше времени. Это могут быть ELK (Elasticsearch, Logstash, Kibana) или EFK (Elasticsearch, Fluentd, Kibana) stack.nnНастройте статические анализаторы кода, например Sonarqube. Они помогут найти типичные ошибки, связанные с производительностью кода, неоптимальные рекурсивные вызовы, возможно бесконечные циклы и так далее. Конечно, самые интересные ошибки вам придется искать своими руками, но анализатор поможет хотя бы частично сделать код чище и лучше.nnПомните о performance и load тестировании. Делайте эти тесты максимально приближенными к реальности. Если ваша задача протестировать тысячу одновременных пользователей, то не пытайтесь упростить себе жизнь и сделать тысячу вызовов одним пользователям, это не то же самое. Если уже сделали performance-тесты, то проверьте разные сценарии, так чтобы был запас. Поскольку, например, до тысячи пользователей может быть все хорошо, а после — резкий спад производительности.nnУ нас на проекте однажды была такая ситуация, когда забыли выключить load-тесты на выходные. И в понедельник на утреннем совещании технический лидер сказал, что у него две новости — хорошая и плохая. Плохая заключалась в том, что за выходные мы потратили лишние 400$ на ресурсы Amazon, а хорошая – наше приложение выдерживает нагрузку в десять раз больше, чем то, что потенциально будет на продакшене.nnДумайте, когда пишете код, и постоянно проверяйте код ваших коллег (code review), поскольку наиболее интересные ошибки всегда находит человек. До сих пор можно увидеть такие шедевры, как извлечение всех 100 500 сущностей из таблицы, а затем на frontend-стороне разбиения на страницы (pagination).n

Ошибка 6. Клиенты раньше разработной команды замечают ошибки и сами на них указывают

Этот последний совет может прозвучать банально, грустно и смешно одновременно, но, поверьте, его актуальность сложно переоценить.nnДелайте нормальное логирование! Это не так сложно, и его можно сделать повсюду – на старом проекте, на новом, на монолите, на микросервисах. Есть много коммерческих решений, которые помогают этому.nnДумаете, это просто? Может и так, по моим наблюдениям 20–30% проектов до сих пор испытывают проблему с логированием.nnРасскажу об этом процессе на примере одного проекта. Все ошибки перехватывал один-единственный обработчик, пытавшийся пересылать то на почту администратора. Этот адрес был записан в самом коде. Конечно, большая часть сред разработки и тестирования (dev, stage and test environments) были даже не настроены. Но похоже, что и для продакшена этот подход не слишком работал. Потому что процесс сообщения об ошибке и выяснении, в чем дело, выглядел так: у клиента возникала проблема с приложением — он звонил по телефону в техническую поддержку и сообщал об этом. Разработчик объяснял, как открыть панель разработчика в браузере и сделать снимок экрана так, чтобы были видны ошибки, появившиеся в графическом интерфейсе аппликации, и ошибки, которые пишутся в консоль панель разработчика в браузере.Клиент посылал этот снимок в поддержку для дальнейшего исследования проблемы.nnМожет быть, проще сделать логирование?n

Чтобы не заканчивать на печальной ноте

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