Дисклеймер
Статья будет дополняться, вычитываться и пр.
Привет. Меня зовут Михаил, и я создал несколько CRM, да и в принципе лет 5 из 7 занимаюсь автоматизацией различных бизнесов. За это время я набил шишек и превратил их в опыт, которым время от времени делюсь здесь.
В этой статье я хочу собрать некоторые советы, которые вынес из своей деятельности.
1 Больше сущностей
На старте проекта сложно предсказать, что с ним будет дальше: как изменятся требования, какими они будут и так далее. Но некоторые моменты иногда проще сделать сразу, чем потом проводить миграцию со старого решения на новое. Это касается, к примеру, структуры хранения различных сущностей.
Самый простой пример: статусы. Статусы могут быть у чего угодно: у заказов, клиентов, задач и пр. На старте проекта, когда много неизвестных переменных, хочется захардкодить такие статусы. И действительно, набор статусов меняется крайне редко. Но когда это происходит, приходится перекраивать много кода. Изменение набора статусов — довольно скучное занятие, поэтому лучше реализовать это сразу отдельной сущностью.
Ещё пример: номера телефонов пользователей. Сначала есть соблазн сделать это в виде массива строк, а потом начинается: один телефон нужно пометить основным, а для другого оставить комментарий. И вместо того, чтобы городить костыли, достаточно было завести отдельную таблицу с номерами телефонов.
2 Сущности вместо перечислений и хардкода
Этот пункт вытекает из предыдущего пункта про сущности. Проще хранить, к примеру, статусы, в отдельной таблице в базе данных, а не размазывать по кодовой базе: в коде бэка, в коде фронта, в миграциях, в структуре таблицы сущности, имеющей статус.
3 Фронт отдельно от бэка
Сейчас это не особо актуальный совет, разработчики давно разделяют фронт и бэк. Тем не менее, в начале своей карьеры я делал фронт и бэк достаточно взаимосвязанными: вёрстка собиралась средствами фреймворка и соответствующего шаблонизатора. Этот подход актуален для сайтов, но для различных систем автоматизации — нет.
4 Логирование действий
В любом программном продукте есть и будут ошибки. Нередко сообщения об ошибках приходят от непосредственных пользователей, но не все обладают способностью или желанием ясно рассказать, при каких обстоятельствах произошло некорректное поведение системы. В таких случаях выручает логирование действий. Это может быть простая запись в файл (важно позаботиться о ротации), лишь бы была необходимая информация о действиях пользователей: время, субъект, объект и косвенные обстоятельства.
В дальнейшем журнал можно адаптировать для начальства, чтобы то имело ещё один инструмент контроля.
5 Отслеживание ошибок
Есть молчаливые пользователи, которым нетрудно обновить страничку в случае возникновения какой-то технической ошибки из разряда «вызвал несуществующую функцию». Мало какой пользователь попробует воспроизвести ошибку и пришлёт скриншот консоли, а лог ошибок сервера тем более. Тогда будет полезно собирать сообщения об ошибках автоматически. Я использую Sentry на фронте и на бэке.
6 Фичи в отдельных ветках
Бывает, возьмёшься за разработку нескольких фич одновременно, а потом выясняется, что одну из фич нужно прям срочно-срочно. И тут становится понятно, что даже если нужную фичу сделать вовремя, то недоделанные фичи делают продукт непригодным.
Такое обычно не случается при налаженном процессе, но я таким грешу на небольших проектиках, где нет чёткого расписания релизов.