Анализ рисков разработки веб-проектов и программ

2024-01-07 21:51:32 Время чтения 20 мин 147

Введение 

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

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

У нас есть отдельная статья про карту рисков сайта (сайт упал, пароли украли и т.д.). Данная статья отличается тем, что мы здесь сосредоточимся именно на процессе разработки и полученном результате - программном продукте.  

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

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

Производительность и быстродействие

Это серьезная проблема для кастом проектов, где используется не готовое решение, а создается что-то свое. 

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

Проблема в том, что программисты делали свой код на небольших тестовых данных. Если в таблице 100-1000 строк, то даже если вы напишете суперкривой запрос SQL, он все равно будет работать быстро. Но как только в таблице станет достаточно много данных (100 000+), то запросы начинают уходить в таймаут, т.к. сервер подвисает. 

Эту проблему сложно выявить на начальных стадиях. 

Что предлагаю делать: 

  1. Желательно сразу загружать большой каталог;
  2. Пробовать делать нагрузочное тестирование; 
  3. Быть готовым вносить правки для оптимизации нужных запросов;
  4. Иметь средства диагностики сайта для выявления проблемных мест. 

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

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

В Falcon Space мы собрали все инструменты диагностики базы в одном месте. Эти инструменты позволяют находить проблемные места в проекте: 

  1. медленные запросы;
  2. запросы, создающие нагрузку на CPU;
  3. очень частые запросы;
  4. дубли HTTP запросов для компонентов и их блокировка;
  5. слишком частые запросы; 
  6. долгие ajax запросы;
  7. запросы, которые выдают много строк;
  8. исключения и др.

Главный посыл - эта проблема в любом случае появится при росте проекта, нужно быть готовым решать ее: 

  1. оптимизировать код приложения;
  2. чистка данных;
  3. увеличение аппаратных мощностей;
  4. регулярное обслуживание и диагностика.

Сложность будущей поддержки и развития

Никто об этом не думает на начальной стадии проекта, верно? 

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

Если стоимость изменений в будущем очень высока, то такие изменения будут делаться неохотно, с оговоркой "Бюджет не резиновый", "А может не нужно?". 

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

Мы создали свою учетную систему на своей же платформе. Изменения в нее вносятся по ходу использования. Зачастую новая таблица добавляется в интерфейс прямо по ходу использования (придумали, что нужен такой-то отчет - сразу выводим и используем в течение часа). 

Если же цикл изменения большой, есть dev, prod и test stage, инженеры по тестированию, devops и прочее - любое изменение может занимать рабочий день. Т.е. полезная правка программиста заняла допустим час, но затраты будут часов на 8-10, т.к. требуются разные специалисты для доставки всего этого добра на сервер. 

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

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

Выбраны неверные технологии

Технологии навряд ли как-то вытащат наверх ваш проект, но могут значительно подпортить карму проекту. 

Например, захотели вы сделать IOS приложение для учета финансов (все же пользователи Iphone более платежеспособные, верно?). Долго делали, внедрили, исправили все баги, получили хороший фидбек. А потом платформу IOS просто закрыли для определенных стран (нет, такого не бывает).  

Учитывайте риски определенных технологий и вендоров.

Если ваши данные хранятся у кого-то в облаке - эти данные могут исчезнуть в любой момент. Пример - Google Drive и связанные инструменты.  

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

Прогресс нас тянет использовать различные Dadata, Google сервисы, яндекс сервисы и т.д., но он также повышает наши риски.

Сделайте так, чтобы ключевая технология была надежной и под вашим контролем (желательно на вашем сервере).

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

Ставка на какую-то хрупкую интеграцию типа парсинг

Иногда предлагают делать проекты, где данные собираются по парсингу. 

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

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

Вспомните про простые понятные проекты, которые выстрелили - Excel, 1C, Telegram - в них нет какого-то новомодного тренда. Они просто хорошо выполняют свою основную задачу. 

Хрупкий код на ошибки

Это больше растет от качества кода программы и хрупкой архитектуры. Если ваша система очень критично относится к малейшей ошибки в настройках или коде- это плохо. 

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

Система должна быть построена таким образом, чтобы: 

  1. ошибки были видны админу как на ладони;
  2. ошибки не должны быть фатальными для работы сайта; 
  3. ошибки должны быть просто локализуемы - т.е. находить их должно быть просто - такой-то модуль, такая-то строка;
  4. мелкие ошибки не должны прерывать пользователя и мозолить ему глаза ненужными сообщениями. 

Если вы программист, то у меня для вас только один совет - почаще проверяйте на NULL. 

Безопасность данных

Вы можете сделать хорошее полезное приложение. Но его могут взломать. Необходимо на уровне кода внедрять проверки доступа и защиту от основных типов атак (XSS, SQL injection, DOS и др.)

Чтобы защититься от возможных проблем используйте такие рекомендации: 

  1. не доверяйте пользовательскому вводу. В нем могут быть теги, попытки вставить sql код и многое другое; 
  2. экранируйте введенные данные от неадминистративных ролей. Как следствие предыдущего пункта;
  3. проверяйте всегда доступы к определенным ресурсам или операциям. Не надейтесь на внешний каркас защиты - прямо перед выполнением операции выполняйте проверку доступа;
  4. создавайте эшелонированную защиту. Пусть будет несколько уровней проверки доступа - по роли, по пользователю, по выборке (напр. выбираем только проекты этого пользователя).

Если вы не технарь, то вы можете спросить у программиста "А как мы проверяем доступ для этой функции". Прямо по коду пусть покажет, как проверяет тот или иной доступ или как работает система авторизации на определенное действие.  

Не учтены важные факторы

Представьте, делали-делали сложный каталог. А потом пришел SEOшник и сказал - а почему страницы каталога не статичные? Как их будет считывать поисковик? 

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

Это могут быть особенности API, подпадание под требования внешнего регулятора (государство, поисковик и т.д.), локализация на разные языки. 

Сроки сорваны

Про сроки сказано уже очень много. Есть хорошая книга Цель Голдратта. Читайте, перенимайте опыт заводов по работе с узкими звеньями. 

Почему срываются сроки проектов: 

  1. проектов несколько (а иначе и быть не может для студии, т.к. иначе будет большой риск простоя);
  2. появляются новые требования; 
  3. появляются новые неучтенные ранее проблемы (например, при интеграции какой-либо системы). 

Как можно улучшить ситуацию со сроками: 

  1. собирать команду, сфокусированную на один проект;
  2. уменьшить объем продукта по максимуму, порезать несущественные требования - зачастую это самое правильное решение;
  3. упростить продукт (т.е. реализовать все функции, но с учетом простоты внедрения). Другими словами, убрать сложную кастомизацию;
  4. уменьшить зависимость проекта от внешних поставщиков (они точно подведут и сорвут сроки).

Очень дорого 

Этот пункт идет рука об руку с предыдущим и последующим. 

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

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

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

Много ошибок 

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

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

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

Как снизить риски при разработке сайта 

Здесь мы дадим общие рекомендации по снижению рисков разработки. 

Не ссорьтесь с разработчиками

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

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

Любой обиженный технический специалист - повышение риска для проекта. 

Имейте сильного советника-технаря

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

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

Также у советника не должно быть интереса в проекте - иначе он приведет в проект своего подрядчика, свои продукты и т.д. 

Сразу активно используйте и шлифуйте продукт

Сделали продукт - сразу наполняйте базу и активно внедряйте процессы. Так вы избежите риска, что система просто не будет внедрена вообще. 

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

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

Уменьшите функционал первой версии до минимума

Чем меньше первая версия, тем качественнее она будет сделана, тем меньше проблемных мест в ней, тем лучше вы ее протестируете.

Частая болезнь - пухлый объем первой версии. Малыш, еще не ходит, а его откармливают, откармливают. В итоге он встать на ноги (запуститься в эксплуатацию) уже просто не может. 

Лучше добейтесь реального использования на более узком функционале, и затем расширяйте его по мере получения РЕАЛЬНОЙ обратной связи от пользователей. 

50% создаваемой вами системы вообще никому не нужна. Но какая именно - это ясно будет только после запуска проекта в реальную эксплуатацию. 

Ревизия кода и постоянная диагностика решения

Нужно следить за кодом. Нужно контролировать рабочие характеристики проекта. 

Если мы не смотрим за кодом, то есть риск плохих решений от отдельных разработчиков. Он может принять хорошие, а может плохие решения. 

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

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

Отдельную статью мы посвятили теме Как защитить сайт? 

Документация и знание технических деталей

Если у проекта нет документации - вы в плену у разработчиков. 

Без документации вы не сможете нормально сменить подрядчика по разработке. А также не будет точного понимания как эта программа работает. 

Какая нужна документация: 

  1. руководство программиста, т.е. как сопровождать систему с точки зрения разработки;
  2. руководство администратора, т.е. как управлять системой на уровне администрирования через кабинет администратора. 

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

Проведение аудитов

Проводите различные аудиты, которые улучшают качество вашего продукта. Это могуть быть SEO параметры, быстродействие, нагрузочное тестирование, тесты юзабилити и другое. 

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

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

Заключение

Мы постарались изложить свой анализ рисков разработки - какие подводные камни вы можете встретить при разработке программ или сайтов. 

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

Источник: https://falconspace.ru/blog/analiz-riskov-razrabotki-veb-proektov-i-programm