Привет .
Меня зовут Михаил, более 10 лет разрабатываю интернет-проекты: от сайтов до систем автоматизации.

N мини-советов по разработке CRM

Дисклеймер

Статья будет дополняться, вычитываться и пр.

Привет. Меня зовут Михаил, и я создал несколько CRM, да и в принципе лет 5 из 7 занимаюсь автоматизацией различных бизнесов. За это время я набил шишек и превратил их в опыт, которым время от времени делюсь здесь.

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

1 Больше сущностей

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

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

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

2 Сущности вместо перечислений и хардкода

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

3 Фронт отдельно от бэка

Сейчас это не особо актуальный совет, разработчики давно разделяют фронт и бэк. Тем не менее, в начале своей карьеры я делал фронт и бэк достаточно взаимосвязанными: вёрстка собиралась средствами фреймворка и соответствующего шаблонизатора. Этот подход актуален для сайтов, но для различных систем автоматизации — нет.

4 Логирование действий

В любом программном продукте есть и будут ошибки. Нередко сообщения об ошибках приходят от непосредственных пользователей, но не все обладают способностью или желанием ясно рассказать, при каких обстоятельствах произошло некорректное поведение системы. В таких случаях выручает логирование действий. Это может быть простая запись в файл (важно позаботиться о ротации), лишь бы была необходимая информация о действиях пользователей: время, субъект, объект и косвенные обстоятельства.

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

5 Отслеживание ошибок

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

6 Фичи в отдельных ветках

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

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