Какие правила включить в регламенты для веб разработчиков?
Добрый день. Столкнулся с темой необходимости регламентов, а то начался зоопарк.
При создании кастом веб сайтов. на Laravel, Vue.
Проблемы
То в в одном проекте на Laravel используется встроенный query builder, то Eloquent то ещё чего. То какие-то самописные разработчиком модули появляются в итоговом проекте, которые в итоге оказываются с багами и дорабатываются в рабочее время в итоге, так как проект на них завязан и.т.д. Сборка для фронта, тоже кто во что горазд.
То у одного линукс, у другого видовс, то докер работает то нет, контейнеры один так делает, другой по другому. То самописные скрипты опять появились, потому-что кому-то так было удобнее\привычнее. и.т.д. Что усложняет дальнейшую поддержку другими людьми.
Вопрос
Так как есть разработчики в штате и иногда привлекаются люди с фриланса и планируется удалёнщик.
Хотелось бы не мудрёный на 10 листов регламент. А для начала свод простых правил. Понятный и простой, для предотвращения основных проблем. А то проходить много лет через все грабли, на которые уже кто-то наступал смысла нет, но нагуглить никак не смог такое.
Как регламентировать, какие сторонние модули можно использовать, а какие нет и.т.д.
начал писать.
1. Максимально используем встроенный в Фреймворк функционал, так же построители SQL запросов. Типа Eloquent или встроенный query builder. Использовать встроенный шаблонизатор.
2. Нельзя использовать в проектах свои самописные модули.
но пока столкнулся с такими проблемами, но я думаю их намного больше, поделитесь пожалуйста.
То в в одном проекте на Laravel используется встроенный query builder, то Eloquent
одно другому никак не мешает. тут надо исходить из задач.
Максимально используем встроенный в Фреймворк функционал, так же построители SQL запросов. Типа Eloquent или встроенный query builder.
это верно.
Использовать встроенный шаблонизатор.
это не понятно.
Нельзя использовать в проектах свои самописные модули.
это тоже не понятно.
На самом деле весь регламент сводится к двум вещам:
1. общепринятый код-стайл и требования к документации.
2. все что угодно, что команда считает для себя приемлемым.
под самописными имею ввиду: Программист запилил на досуге, какойнить wysiwyg редактор или обработчик или пакет какой-то. чтобы получить какой-то доп.функционал от фреймворка. оформил в пакет на packagist ну и молча использовал его в проекте. а когда это заметили, уже куча работы завязано на этот пакет. А в конце оказывается что-то глючит, и эту его личную поделку приходится допиливать в рабочее время. Хотя она как бы так и остаётся его личной разработкой, да и другим коллегам вникать в какую-то одноразовую штуку сложнее, чем в популярный пакет с документацией.
Использовать встроенный шаблонизатор.
так же в Laravel фреймворке есть шаблонизатор Blade. но кто-то может захотеть поставить Twig к примеру, потому-что так удобнее\привычнее. Но у следующего разработчика вызовет ступор.
На самом деле весь регламент сводится к двум вещам:
1. общепринятый код-стайл и требования к документации.
2. все что угодно, что команда считает для себя приемлемым.
я может не совсем понимаю, что понимается под код стайлом. я это понимаю, как стандарты для PHP к примеру PSR-4 и.т.д Но это не отменят того, что они там могут огород нагородить, что потом никто не разберёт, путь и будет красиво и доступно выглядеть.
Alexander M, когда не хватает функционала фреймворка, у вас есть два пути:
1. размазывать его по коду.
2. оформить пакет, который можно будет использовать и в других проектах.
лично я предпочитаю второй способ. разумеется, нормально оформленный и согласованный.
я может не совсем понимаю, что понимается под код стайлом. я это понимаю, как стандарты для PHP к примеру PSR-4 и.т.д
пср - вовсе не стандарты высеченные в граните. вы можете использовать их, вы можете использовать то, что больше подходит вам.
это не отменят того, что они там могут огород нагородить, что потом никто не разберёт, путь и будет красиво и доступно выглядеть
эммм... список пунктов на бумаге как-то решает эту проблему?
DevMan, Сложно сказать решит он её или нет, время покажет.
Ну обычно для этого и есть регламенты) чтобы закрыть вопросы общие на которые у каждого свой ответ.
Alexander M, так я же вам об этом и говорю: "все что угодно, что команда считает для себя приемлемым".
на примере:
так же в Laravel фреймворке есть шаблонизатор Blade. но кто-то может захотеть поставить Twig к примеру, потому-что так удобнее\привычнее. Но у следующего разработчика вызовет ступор.
и пусть. только не один пишет на блэйде, а другой на твиге, а они сами должны решить что использовать и использовать только это.
другими словами регламент вы должны придумывать не из головы (своей или нашей), а общаясь со своими сотрудниками/коллегами.
Регламент будет работать когда есть кто-то кто за ним следит, отвечает за результат, и главное - у него есть право сказать "будем делать вот так". без такого человека будет зоопарк хоть вы тонну бумаг испишите. (если команда не дотягивает уровнем до самоорганизации)
Если у вас такое право есть и вы этот отвественный - начните с общения с людьми, обсуждайте проблемы которые вы видите и как-то приходите к решению. Как договорились до чего-то - фиксируйте.
Постепенно составится ваш "регламент" - в котором будет именно то что важно для вас.
Если вы обсудили проблему, а решения не нашли и не договорились как делать - то регламент не поможет, если люди на вас забили, с чего бы им вашу писанину выполнять?
Вообще так звучит будто у вас команды как таковой нет, а есть пул людей в который закидывают задачи и ждут результат. А там уже все пилят кто во что горазд - главное результат и все проблемы вылезают уже когда результат запилен и начинается его какое-то использование.
Стройте командное взаимодействие - хорошая команда работает хорошо без всяких регламентов и подобного рода вопросы решает самостоятельно либо с минимальными усилиями.
Вообще так звучит будто у вас команды как таковой нет, а есть пул людей в который закидывают задачи и ждут результат. А там уже все пилят кто во что горазд - главное результат и все проблемы вылезают уже когда результат запилен и начинается его какое-то использование.
Примерно так. Относительно недавно всё ушло в сторону кастом разработки и ещё не отладили процессы. Делали для себя. сейчас для клиентов начали ещё.
Alexander M, тогда стройте внутрикомандные коммуникации в первую очередь. И на их основе уже регламент, в бардаке он работать все равно не будет - даже если примете, его засаботируют напрочь.
1. Регламентируете структуру кода (как и что именовать, оформлять, куда и как подключаться и т.д.), требования при взаимодействии с другим уже готовым функционалом (учётки, бд, пулы, статистика, логирование и т.д.) и общие требования к модулю или к php-классу.
2. Новый функционал - заранее проектируете с помощью нужных классов и методов в виде блок-схемы.
3. Всё документируете (включая взаимодействие блоков на блок-схеме в отдельном разделе) и строго по докам даёте кодерам на реализацию.
После - ревью кода автоматическое и, если успешно - уже вручную человеком.
Потом - тестирование и релиз модуля в dev-среде/лабе.
И только после всего этого - внедрение нового модуля в РАЗРАБАТЫВАЕМЫЙ проект! Т.е., даже не в релиз или в паблик!
Ну всё же доводить до сведения, что это нужно читать.
код ревью возможно бы и решило. но отдельного человека под это пока нет.
про код-ревью. нет возможности проводить код ревью у нескольких человек раз в день, не тот уровень проектов. у нас на проект в среднем уходит 2-3 человеко месяца. т.е. довольно не большие.
И как-то оградить от типичных проблем. Какой-то общий стиль работы, я так думал это и должен быть какой-то свод правил или регламент не сложный.
Alexander M, никто не любит читать "много букв", тем более сухие требования. Должна быть коммуникация между разработчиками, чтобы они говорили друг другу как и что делать.
Alexander M, Если проекты мелкие и однотипные - то просто соберитесь все, обсудите на примере последних 4-5 проектов какие технологии и как использовать, какую архитектуру строить, общие правила выработайте - и то что получится то и зафиксируйте.
Средний
