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

🔥 Рассказываем в нашей новой статье на Хабре, как с помощью Attribute-Driven Design создать архитектурное решение, выбрать инструменты под проект, а также снизить затраты на разработку.

https://s.simbirsoft.com/2N4f

🔥 Подготовили новую статью на vc.ru про основные SEO-требования, которые нужно учесть на этапе аналитики и разработки ТЗ для проекта: https://s.simbirsoft.com/m1Gf

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

#SimbirSoft

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

1) Конструкторы сайтов
Предоставляют набор функций для создания и размещения простых проектов. На их основе можно сделать веб-ресурс с несложной логикой работы.

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

📌 Для какого бизнеса подойдет:
С помощью конструктора удобно быстро создавать лендинги для рекламных акции, простой сайт для представительства компании в интернете.

👇👇👇

2) CMS (Content Management System)

CMS – это система управления контентом сайта. Существует множество различных CMS, которые зачастую предназначены для конкретного направления бизнеса: интернет-магазин, блог, учебный центр и прочее.

➕ Плюсы:
Высокая скорость разработки полноценного сайта.
➖ Минусы:
Сложность добавления логики, не предусмотренной конкретной CMS.

📌 Для какого бизнеса подойдет:
CMS удобен, если бизнесу нужно создать интернет-магазин, иметь возможность выкладывать документы на сайте или заложить большую функциональность, чем предоставляет конструктор.

👇👇👇

3) PHP-фреймворки

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

➕ Плюсы:
Универсальность и возможность разработки проекта любой сложности.

➖ Минусы:
Для создания сайта с помощью PHP-фреймворков бизнесу понадобится команда квалифицированных специалистов: аналитики, backend- и frontend-разработчики, тестировщики, DevOps-инженеры и т.д.

📌 Для какого бизнеса подойдет:
PHP-фреймворки позволяют настроить более сложные процессы, специфичные для конкретного бизнеса, и решить важные задачи в интернете или интранете, для которых не подходят стандартные бизнес-процессы сайта-каталога или интернет-магазина. Стоит отметить, что различные CMS уже используют компоненты фреймворков (например, Drupal) или основаны на них (например, October CMS).

👇👇👇

Среди множества PHP-фреймворков, на наш взгляд, стоит выделить следующие:

✔️ Laravel – один из наиболее популярных фреймворков на сегодняшний день. Это обусловлено относительно невысоким порогом вхождения (если сравнить с Symfony), универсальностью, мощным набором встроенных компонентов и инструментов для разработки (например, почтовые сервисы, простое добавление авторизации и аутентификации пользователей, обеспечение безопасности). Кроме того, наличие подробной документации и многочисленного сообщества разработчиков позволяет оперативно находить оптимальные решения задач. Laravel отлично подходит, если вам нужно быстро создать проект, внутри которого будут реализованы бизнес-процессы разного уровня.

✔️ Symfony – один из самых сложных, надежных и высокопроизводительных фреймворков. Представляет собой множество модулей для реализации любой функциональности, подходит для крупных проектов, в том числе уровня enterprise. Порог вхождения для разработчиков несколько выше, чем у других фреймворков, поэтому скорость разработки может быть ниже, но код более предсказуем. У Symfony также есть подробная документация на разных языках и большое сообщество разработчиков. Фреймворк активно развивается и поддерживается на протяжении многих лет. Symfony – хороший выбор, если у вас в приоритете надёжность и возможность лёгкого масштабирования.

✔️ Yii 2 – один из самых быстрых и не требовательных к ресурсам фреймворков. Также входит в число наиболее популярных и имеет активное сообщество. Порог вхождения довольно низкий, что позволяет быстро начать работу над проектом специалисту, не знакомому с этим фреймворком. Это ускоряет и в конечном итоге уменьшает стоимость разработки. Если у вас в приоритете скорость и простота работы сайта, то выбирайте Yii2.

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

#SimbirSoft

Как лучше выстроить процессы в ситуации, если в качестве исходных данных есть только код — без описания продукта и прочей технической документации (ТД)? Делимся нашим чек-листом👇
✔️ Первое. Общаемся с клиентом и узнаем больше о продукте, его целях, аудитории и функционале. Это достаточно очевидный пункт, но мы хотим подробно рассказать о процессе, поэтому оставляем его в нашем списке.
✔️ Второе. Получаем доступ ко всей имеющейся информации — техническому заданию, доске разработки, тестовым стендам и т.д. Анализируем её и определяем пул необходимых доработок. Для этого:
🔹 Изучаем логи запросов к серверу, базу данных в realtime.
🔹 Находим нужный для изменения код и исследуем его.
🔹 Проверяем, чтобы функционал приложения совпадал с указанным в технической документации. Если мы обнаружили расхождения, то отмечаем и передаем информацию владельцу.
↓↓↓↓

✔️ Третье. В случае, если у проекта нет описания, то мы формируем его самостоятельно. Основные его составляющие — это информация о функционале, список запросов к серверу и их последовательность (от запуска приложения до завершения сценария), данные о состоянии продукта до и после выполнения какого-либо действия.
✔️ Четвертое. Согласовываем с клиентом изменения и приступаем к разработке.
✔️ Пятое. Выпускаем релиз и тестируем продукт.
✔️ Шестое. Вместе с заказчиком составляем план дальнейшего развития системы.
Отсутствие четкого описания функционала и логики работы приложения может привести к тому, что реализованный продукт не будет соответствовать ожиданиям заказчика. Все пункты нашего чек-листа созданы для того, чтобы избежать этой проблемы и выполнить работу качественно.

Узнать больше про наши реализованные проекты вы можете по ссылке: https://s.simbirsoft.com/fQP7

#SimbirSoft

Сегодня в центре нашего внимания автоматизированное тестирование, которое проводят SDET-специалисты.

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

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

✔️ Стратегия

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

→ Своевременная корректировка планов

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

Чтобы такого не происходило, в документацию мы рекомендуем добавлять версионирование, соответствующее проекту. Рассмотрим на примере приложения заказа пиццы.
1. В первой версии в магазине доступна только пицца навынос.
2. Во второй версии добавлена доставка. Это необходимо отразить в документах, так как в заказе появляется новая функция, которую нужно покрыть тестами. Будут ли пользователю доступны обе опции при заказе, будет ли в этом поле корректный адрес, когда магазин получит заказ?
3. В третьей версии поменялась форма заказа: добавили онлайн-отслеживание, при этом исключили одну из невостребованных ранних фич. Все изменения должны войти в документацию 3.0, чтобы SDET-специалисты скорректировали стратегию тестирования с учетом новых планов развития продукта.

✔️ Модернизация и расширение системы тестирования

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

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

✔️ Атмосфера и процессы в команде

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

Для быстрого и комфортного погружения нашей команды в проект мы используем несколько лайфхаков, которые могут быть вам полезны:

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

Узнайте, когда стоит подключать автотесты на проекте, в нашем материале по ссылке: https://s.simbirsoft.com/jZDd