alexander7779
@alexander7779
SEO, PHP (разработка на Laravel).

Какие правила включить в регламенты для веб разработчиков?

Добрый день. Столкнулся с темой необходимости регламентов, а то начался зоопарк.
При создании кастом веб сайтов. на Laravel, Vue.

Проблемы
То в в одном проекте на Laravel используется встроенный query builder, то Eloquent то ещё чего. То какие-то самописные разработчиком модули появляются в итоговом проекте, которые в итоге оказываются с багами и дорабатываются в рабочее время в итоге, так как проект на них завязан и.т.д. Сборка для фронта, тоже кто во что горазд.
То у одного линукс, у другого видовс, то докер работает то нет, контейнеры один так делает, другой по другому. То самописные скрипты опять появились, потому-что кому-то так было удобнее\привычнее. и.т.д. Что усложняет дальнейшую поддержку другими людьми.

Вопрос
Так как есть разработчики в штате и иногда привлекаются люди с фриланса и планируется удалёнщик.
Хотелось бы не мудрёный на 10 листов регламент. А для начала свод простых правил. Понятный и простой, для предотвращения основных проблем. А то проходить много лет через все грабли, на которые уже кто-то наступал смысла нет, но нагуглить никак не смог такое.
Как регламентировать, какие сторонние модули можно использовать, а какие нет и.т.д.

начал писать.
1. Максимально используем встроенный в Фреймворк функционал, так же построители SQL запросов. Типа Eloquent или встроенный query builder. Использовать встроенный шаблонизатор.
2. Нельзя использовать в проектах свои самописные модули.

но пока столкнулся с такими проблемами, но я думаю их намного больше, поделитесь пожалуйста.
  • Вопрос задан
  • 754 просмотра
Решения вопроса 3
DevMan
@DevMan Куратор тега Веб-разработка
То в в одном проекте на Laravel используется встроенный query builder, то Eloquent
одно другому никак не мешает. тут надо исходить из задач.

Максимально используем встроенный в Фреймворк функционал, так же построители SQL запросов. Типа Eloquent или встроенный query builder.
это верно.

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

На самом деле весь регламент сводится к двум вещам:
1. общепринятый код-стайл и требования к документации.
2. все что угодно, что команда считает для себя приемлемым.
Ответ написан
Robur
@Robur
Знаю больше чем это необходимо
Регламент будет работать когда есть кто-то кто за ним следит, отвечает за результат, и главное - у него есть право сказать "будем делать вот так". без такого человека будет зоопарк хоть вы тонну бумаг испишите. (если команда не дотягивает уровнем до самоорганизации)
Если у вас такое право есть и вы этот отвественный - начните с общения с людьми, обсуждайте проблемы которые вы видите и как-то приходите к решению. Как договорились до чего-то - фиксируйте.
Постепенно составится ваш "регламент" - в котором будет именно то что важно для вас.
Если вы обсудили проблему, а решения не нашли и не договорились как делать - то регламент не поможет, если люди на вас забили, с чего бы им вашу писанину выполнять?

Вообще так звучит будто у вас команды как таковой нет, а есть пул людей в который закидывают задачи и ждут результат. А там уже все пилят кто во что горазд - главное результат и все проблемы вылезают уже когда результат запилен и начинается его какое-то использование.
Стройте командное взаимодействие - хорошая команда работает хорошо без всяких регламентов и подобного рода вопросы решает самостоятельно либо с минимальными усилиями.
Ответ написан
xmoonlight
@xmoonlight Куратор тега Веб-разработка
https://sitecoder.blogspot.com
1. Регламентируете структуру кода (как и что именовать, оформлять, куда и как подключаться и т.д.), требования при взаимодействии с другим уже готовым функционалом (учётки, бд, пулы, статистика, логирование и т.д.) и общие требования к модулю или к php-классу.
2. Новый функционал - заранее проектируете с помощью нужных классов и методов в виде блок-схемы.
3. Всё документируете (включая взаимодействие блоков на блок-схеме в отдельном разделе) и строго по докам даёте кодерам на реализацию.

После - ревью кода автоматическое и, если успешно - уже вручную человеком.
Потом - тестирование и релиз модуля в dev-среде/лабе.

И только после всего этого - внедрение нового модуля в РАЗРАБАТЫВАЕМЫЙ проект! Т.е., даже не в релиз или в паблик!

Тогда - чихарды не будет!
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@MasterMike
Вам нужны код-ревью и обсуждение предполагаемого решения при постановке задачи.

Регламенты, как правило, никто не читает )
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы