Шпаргалка при разработке software

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

Планирование архитектуры

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

Следующие действия помогают составить правильную архитекруту.

• Нарисовать макеты страниц
• Расписать роли пользователей и разделить доступ (кто что видит)
• Расписать сценарии для каждой роли пользователей с последовательностью страниц, которые нужно пройти для выполнения того или иного сценария
• Утвердить все с заказчиком
• Спроектировать базу данных (нарисовать таблицы, поля и связи)

Процесс разработки

• Выбрать фреймворк, на котором команда или разработчик смогут разрабатывать (желательно, чтобы был опыт у Тех Лида, а лучше у всех команды). Это верно для любого языка программирования, который вы будете использовать;
  • Использовать пакетный менеджер (лучше использовать проверенные кем то библиотеки);
  • Использовать миграции для создания базы данных и внесения изменений. Вариант базы данных выбирается под задачи. Мне обычно хватает реляционных
• Использовать репозиторий для хранения кода: https://bitbucket.org/product Тут можно создать закрытый репозиторий и дать доступ 5-ти до человек. Можно и https://github.com. Создать для кода как минимум две ветки:
  • master – тут должен быть рабочий код, который уже на продакшине
  • dev – ветка в которой разрабатываются новые фичи
• Для кода нужно писать unit-tests:
  • Логика такая, что нужно писать тесты:
    • на все функции моделей, которые работают с базой данных.
    • на все функции, которые отдают данные для фронтенда
    • обязательно на все функции, которые считают деньги.
  • Тесты запускаются на отдельной базе данных, с подготовленными данными. Тесты запускаются после добавления новых фич и перед тем, как запушить все в репозиторий.
  • Разработчик пишет новые тесты на те функции, которые он создает.
• Vagrantup – разрабатывать нужно в Vagrante – это виртуальная машина, которая позволяет хранить конфигурацию в одном файле в проекте в репозитории. Настройка виртуальной машины, должна быть такой же как и настройка живого сервера.
• Сервера
  • Нужно иметь как минимум два сервера
    • staging – сервер идентичный по настройкам и размерам живому, на котором тестируются новый функционал и изменения.
    • live – сервер с живым сайтом.
    • root – управляющий сервер, на котором будет запущен мониторинг и система логирования.
  • Для живого сервера нужно базу держать отдельно от кода, чтобы можно было бекапить базу отдельно и если фронтенд упадет – быстро поднять новый или даже два.
  • Сервис рассылки почты, чтобы можно было хранить и проверить письма которые рассылаются пользователям.
• Логирование и мониторинг – на отдельном сервере  нужно поставить систему, например
  • Senrty – это локальный сервер логов. В коде проекта отдельно прописывается отправка логово в этот серве. Можно разделать логи с живого сервера и логи с сервера разработчиков.
  • NewRelic – онлайн сервер мониторинга. Он считает нагрузку на страницы, на базу данных. Есть бесплатная версия, которая показывает общую картину.

Документация

• Документации должно быть две.
  • Техническая спецификация  – план по разработке системы, где описана главная задача и модули системы
  • Блог разработки – сюда нужно записывать принятые решения, почему решили делать так а не иначе. Должен вести руководитель, который в курсе всех решений. Это очень поможет в дальнейшем.
  • Доступы – желательно завести отдельный документ с доступами ко всему, которые потом нужно передать клиенту. Нужно создать под проект отдельный gmail и потом все регистрировать на него, чтобы можно безболезненно передать клиенту.

Приоритеты разработки

• Проекты, в которых в план закладывается 3 и больше месяцев имеют свойство затягиваться очень надолго. По этому нужно как можно чаще выкачивать новые версии и показывать их клиенту.
• Вполне нормально делать спринты длительностью в 2-е недели. Это означает что мы сначала выбираем функционал, который сделаем за две недели, делаем его и через 2е недели он должен быть на продакшине.
• Приоритет по задачам должен быть таким
  • версия 0.1
    • Создание структуры базы данных
    • Авторизация-регистрация пользователей
    • Добавление системы ролей в архитектуру
    • Редактирование пользователей в админке
  • версия 0.1.1
    • Редактирование всех справочников а админке
  • версия 0.N
    • Добавление по одной user-story в релиз. Это одно действие, которое пользователь может сделать на сайте

На мой взгляд это вполне универсальный набор советов, которые стоит не забыть сделать в начале, чтобы потом небыло “мучительно больно”