Шпаргалка при разработке 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 в релиз. Это одно действие, которое пользователь может сделать на сайте

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

Published by

Serhii Kholin

CEO at Onix-Systems.com