Комментарии 8
Удобство разработки — странная штука. Развесистый IDE позволяет чрезмерно усложнять структуру проекта. Как я плевался от WebStorm после Atom. И как я ныне счастлив на VSCode после WebStorm.
Добавлю пару мыслей, будучи разработчиком PHP с 10-летнем опытом работы.
Тестирование. Если вы еще не пишете юнит-тесты — начинайте. Всего полгода опыта написания юниттестов дадут понимание таких важных вещей, как зацепление и связанность на интуитивном уровне. Я сомневаюсь, что многие об этом догадываются, но тесты в первую очередь нужны не для тестирования кода, а для тестирования разработчика, что пишет этот код.
IDE — палка о двух концах. От IDE программисты тупеют. Зачастую это вырождается в небрежное структурирование проекта и ощущение, что если IDE не может дать подсказку про код — его не существует. В общем случае мне кажется, что разработчик вместо того, чтобы изучать код, и язык, изучает среду разработки. Ладно бы, если бы это был один из используемых инструментов, но зачастую IDE становится единственным инструментом, сводя к нулю полезность инфраструктуры. В особенно вырожденном случае это выглядит как «IDE этого не поддерживает, значит мне это не нужно».
Версионирование. Здесь все просто. Курить git, git-flow, git-book, semver. Примерно в такой очередности, сдабривая костылями в зависимости от проекта. Но этот базис позволит успешно интегрировать свой проект в крупную инфраструктуру разработки.
Сборка очень полезная штука. Автоматическая сборка — еще и приятная. Если это дополнить автоматическим тестированием — можно быть уверенным в том, что текущая сборка прошла или не прошла тесты и найти виноватого. Но если вы вдруг начитаетесь статей про CI — не пытайтесь сразу внедрить его у себя. Полноценный CI очень трудозатратен и не факт что он окупится. лучше начинайте с малого и последовательно двигайтесь в сторону CI:
— Сначала стоит сделать девстенд, на котором будет крутится текущая версия проекта из дев-ветки
— Написать скрипт по деплою его туда. rocketeer или magelanus вполне подойдут. По первости такой монстр как дженкинс не особо и нужен.
— Автоматизировать этот скрипт, чтобы он исполнялся автоматически.
— Прикрутить к нему обратную связь.
— Начать писать юниттесты.
— Прикрутить к скрипту деплоя скрипт тестирования.
— Прикрутить к автотестам обратную связь.
На этом этапе можно будет считать, что у вас есть треть от CI. Остается всего ничего — начать писать приемочные (acceptance) тесты, начать выпускать стабильные версии кода в собранном виде и размещать их в хранилище в удобном для деплоя формате(deb, rpm, tar), вместе с картой совместимости версий, обеспечить возможность конфигурирования проекта по окружениям, независимо от версии кодовой базы, начать автоматически выгружать стабильные версии на тестовый стенд (с учетом зависимостей), начать их доставлять на продовские серваки и сделать кнопку деплоя на прод с поддержкой отката миграций. Где-то тут это будет уже боле-менее полноценный CI. Работы года на три в меру крупном проекте, если не отрываться от разработки.
И хочу добавить еще один пункт от себя — старайтесь получать обратную связь от системы.
То, что вы написали и протестировали, еще ничего не значит. Неизвестно как поведет себя система в проде. Какие полезут в ней ошибки, и какие проблемы могут возникнуть. Любое отхождение от позитивного сценария должно логгироваться и сообщаться разработчикам как минимум только для того, чтобы они были в курсе. Без обратной связи от системы можно никогда не узнать об ошибках или о проблемах — логи и метрики — это значительно более надежный (и быстрый) канал получения информации о системы, нежели пользователи и даже тестировщики. В идеальном мире разработчик должен узнавать о 80% проблем в тот момент, пока тестировщик еще только думает, заводить баг или нет.
Тестирование. Если вы еще не пишете юнит-тесты — начинайте. Всего полгода опыта написания юниттестов дадут понимание таких важных вещей, как зацепление и связанность на интуитивном уровне. Я сомневаюсь, что многие об этом догадываются, но тесты в первую очередь нужны не для тестирования кода, а для тестирования разработчика, что пишет этот код.
IDE — палка о двух концах. От IDE программисты тупеют. Зачастую это вырождается в небрежное структурирование проекта и ощущение, что если IDE не может дать подсказку про код — его не существует. В общем случае мне кажется, что разработчик вместо того, чтобы изучать код, и язык, изучает среду разработки. Ладно бы, если бы это был один из используемых инструментов, но зачастую IDE становится единственным инструментом, сводя к нулю полезность инфраструктуры. В особенно вырожденном случае это выглядит как «IDE этого не поддерживает, значит мне это не нужно».
Версионирование. Здесь все просто. Курить git, git-flow, git-book, semver. Примерно в такой очередности, сдабривая костылями в зависимости от проекта. Но этот базис позволит успешно интегрировать свой проект в крупную инфраструктуру разработки.
Сборка очень полезная штука. Автоматическая сборка — еще и приятная. Если это дополнить автоматическим тестированием — можно быть уверенным в том, что текущая сборка прошла или не прошла тесты и найти виноватого. Но если вы вдруг начитаетесь статей про CI — не пытайтесь сразу внедрить его у себя. Полноценный CI очень трудозатратен и не факт что он окупится. лучше начинайте с малого и последовательно двигайтесь в сторону CI:
— Сначала стоит сделать девстенд, на котором будет крутится текущая версия проекта из дев-ветки
— Написать скрипт по деплою его туда. rocketeer или magelanus вполне подойдут. По первости такой монстр как дженкинс не особо и нужен.
— Автоматизировать этот скрипт, чтобы он исполнялся автоматически.
— Прикрутить к нему обратную связь.
— Начать писать юниттесты.
— Прикрутить к скрипту деплоя скрипт тестирования.
— Прикрутить к автотестам обратную связь.
На этом этапе можно будет считать, что у вас есть треть от CI. Остается всего ничего — начать писать приемочные (acceptance) тесты, начать выпускать стабильные версии кода в собранном виде и размещать их в хранилище в удобном для деплоя формате(deb, rpm, tar), вместе с картой совместимости версий, обеспечить возможность конфигурирования проекта по окружениям, независимо от версии кодовой базы, начать автоматически выгружать стабильные версии на тестовый стенд (с учетом зависимостей), начать их доставлять на продовские серваки и сделать кнопку деплоя на прод с поддержкой отката миграций. Где-то тут это будет уже боле-менее полноценный CI. Работы года на три в меру крупном проекте, если не отрываться от разработки.
И хочу добавить еще один пункт от себя — старайтесь получать обратную связь от системы.
То, что вы написали и протестировали, еще ничего не значит. Неизвестно как поведет себя система в проде. Какие полезут в ней ошибки, и какие проблемы могут возникнуть. Любое отхождение от позитивного сценария должно логгироваться и сообщаться разработчикам как минимум только для того, чтобы они были в курсе. Без обратной связи от системы можно никогда не узнать об ошибках или о проблемах — логи и метрики — это значительно более надежный (и быстрый) канал получения информации о системы, нежели пользователи и даже тестировщики. В идеальном мире разработчик должен узнавать о 80% проблем в тот момент, пока тестировщик еще только думает, заводить баг или нет.
Насчёт IDE — во всем нужен баланс, от экономии времени до зацикливания один шаг, но в целом, реально экономит время, особенно на этапе исследования чужого кода (и вендоров). В остальном — согласен, спасибо за развернутый комментарий.
Насчёт сборки, деплоя и прочего CI: начинать бы я советовал c автоматизации разворачивания и деплоя препродакшен среды (из мастер-ветки), аналогичной проду. Хоть на bash/cmd, если что-то типа ansible выглядит непонятным и(или) ненужным. Тупо поднять голый сервер(а) для препрода и начинать писать скрипт, который сделает его в итоге неотличимым от прода (кроме разве что доступных ресурсов), а потом использовать его для прода.
Да уж, написание юнит тестов круто заряжает дофамином.
Для статического анализа кода в PHP можно использовать следующие продукты — phplint, phploc, phpcs, phpcpd, phpmd.
а как же phpstan/phan? Еще есть phpmetrics, php dependency analyzer и куча других...
Спасибо. имхо структурно и по делу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В поисках дофамина в разработке или избавляем себя от рутины