Контакты

Наибольший вклад в теги

Все теги (57)

Лучшие ответы пользователя

Все ответы (69)
  • Из чего состоит окружение продвинутого php разработчика?

    nonlux
    @nonlux
    Поправил ответ, так будет логичнее.
    Ниже приведены инструменты, которые использую лично я и причины почему.

    1. docker-окружение
    (в 90% случаев для веб-разработки достаточно php -S 0.0.0.0:8000)
    виртуальные машину становятся нужны:
    - когда надоест переустанавливать хост-систему из-за обилия хлама
    - когда работаешь с несколькими проектами имеющие специфические (разные) настройки окружения(php, web-сервер, база)
    - когда надоест решать проблемы в команде из-за того что по разному настроено окружение

    2. git - система контроля версий
    Помнить что ты и когда изменял, должен не человек, а машина.
    Это необходимо:
    - чтобы не испортить всю работы за прошедший год нажав del
    - чтобы определить кто из команды злодей и все испортил
    - чтобы не думать как перенести свежую версию проекта с одной машины на другую

    3. composer - пакетный менеджер для php
    Нужно, когда лениво помнить все ссылки на все php библиотеки, самому качать их, подключать в автозагрузку

    4. behat + phpspec
    Тесты нужны:
    - когда хочется почувствовать себя безопасности и для сладко спать ночь, забыв о кошмарах о сломанном коде
    - когда в production все снова сломалось
    - когда ты написал одну новую фичу, а сломал три

    5. zsh
    Хорошей консолью приятно пользоваться, работа идет быстрее.
    Консоль есть жизнь, жизнь есть shell.

    6. tmux
    Мало одно окошка в консоли, тогда tmux идет к вам.
    В качестве бонуса получите возможность парного программирования совершенно бесплатно

    7. tmuxinator
    Надоело каждый раз открывать кучу окон для tmux, попробуйте его )
    8. vim
    - Потянуло на что-нибудь необычное?
    - Хочется эффективнее писать код ?
    Ну что открыли vim? В первый раз? Поздравляю закрыть вы его не сможете )
    Вызывает зависимость при частом потреблении


    9. continuous integration сервер
    Вообще ci сервер это одушевленная машина. Это твой тамагочи, ты кормишь его хорошим кодом, он радуется и ты видишь приятный зеленый огонек. Если ты дал с код от скажет что не вкусно. Ну а если ты ему, что гнилое он будет долго на тебя орать плохими словами. Со временем он растет и учится делать более серьезные вещи, и начнет помогать тебе:
    Его скилы:
    - он может сам выполнить 10 минутные тесты
    - подготовить и опубликовать проект
    - рассказать о твоем коде, даже то что ты не знаешь
    Он легко обучается и ты легко сможешь научить его удивительным вещам.

    10. куча линтеров на pre commit hook
    Чтобы ci не кормить плохими продуктами, хорошо бы проверять что ты сделал до отправки на сервер. Что бы не забыть это сделать git сам работу.

    11. gulp
    gulp - это еще один твой помощник.
    как если использовать, как watcher файлов + livepreview, можно забыть о F5 в браузере

    12. bower
    Тоже что и composer но для управления ассетами. Это я о всяких jQuery и Bootstrap

    666. Линукс
    Даже если не хочется ставить как хост-систему, его все равно надо знать. Ваш код будет работать на нем )
    Ответ написан
  • Какой workflow front-end разработки у вас?

    nonlux
    @nonlux
    Расклад такой:

    1. Возьми docker контейнер с настроенным окружением для разработки.
    Это удобно если вдруг разработчик станет не один, слетит система, поменяешь рабочее место. Один раз настроил и забыл )
    docker запускает:
    - веб-сервер (можно nginx, можно внутри gulp, все зависит о задачи)
    - livereload сервер, через gulp ( f5 нажимать каждые 3 секунды - это больно
    - gulp watchers ( в ручную компилить всякую хню, запускать тесты скучно )

    2. Запусти vim ( или любой твой любимый редактор)
    3. пиши, бл@#ь, код:
    - less, sass и прочее по мне гораздо удобнее чистого css, меньше пишешь больше кода получаешь.
    - не пиши голый html, используй шаблонизатор любой какой удобнее, я пользуюсь twig, но и простой {{mustache }} подойдет
    4. пользуйся git. И пользуйся им часто.
    - для приветных проектов поставь gitlab
    - используй gitworkflow, ну или сделай хотя бы 2 ветки: например master и prodaction (об этом позже)
    5. CI
    - работая ты все равно допустить кучу ошибок. Проверка синтаксиса, валидация по стандартам, тесты - это все поможет тебе не облажаться.
    - если ты будешь это делать сам потеряешь кучу времени просто на то что бы запускать и проверять всю свою работу. ci сервер поможет тебе убрать эту рутину из свое жизни.
    6. Кроссбраузенрость
    - используй browserstack ( или аналоги) для просмотра результатов своей работы
    - ну уж если нашел ошибку бери реальный браузер ( или в виртуалке) занимайся отладкой
    - получение скриншотов легко подключается к ci
    - а так же из коробки работает и с локальными серверами
    7. Обратная связь с заказчиком
    - для ветки master (да и вообще для любой другой ветки) в git ты легко с помощью ci сервера + docker можешь поднимать сайт c последними обновлениями кода
    - делай это у себя и можешь не боятся, что заказчик сможет забрать твою работы и забыть заплатить
    8. Деплой
    - я просто использую на нужном сервере gitlab-ci-worker и получаю все аналично п.7
    - но для этого использую только ветку prodaction, в которую выкладываю стабильные изменения по готовности
    - просто хостинг - все, что угодно ( shell, ansilbe + ssh ) через ci server
    - И да не забудь что для prodaction надо бы все ассеты по сжимать ( да, да я про ci)
    9 Be happy
    Выкинь рутину, и делай то что тебе нравится. Пиши код))

    P.S.
    Это не наставление как надо работать, не реклама инструментов. Это описание моего workflow.
    Ответ написан
  • У кого из вас есть TDD или BDD в разработке, что конкретно вы делаете, когда, как к этому пришли?

    nonlux
    @nonlux
    Книгу не читал, по этому аналогий привести не смогу
    Пишу на php для веб c bdd

    1. Пишу bdd story.
    ( в моем случае это сценарии behat)
    Для меня bdd story это как функциональные и интеграционные тесты, в которых я проверяю работу всего моего продукта в целом.

    Тут вынес несколько правил для себя:
    1.1. Обязательно формулировать цель (название) сценария
    - Я вхожу в личный кабинет
    - Я создаю новую статью блога
    Это поможет отстраниться от лишнего и не превратить сценарий в кашу

    1.2. Писать на нативном языке без технических подробностей
    Я поначалу долго сопротивлялся писать, что либо кроме файлов трансляции на русском. Но потом вкурил фишку. По сути сценарии у меня превратились не просто в тесты, а мини todo list. Всегда четкий и понятный.
    А избегание технических подробностей помогает забыть о проектирование архитектуры системы на этапе написания сценария.
    И мне гораздо понятнее:
    - Я должен видеть "Отказано в доступе"
    чем
    - Статус код страницы должен быть 403

    1.3. Я(Исполнитель) сценария дурак )
    Сценарий не должен быть замудреным. От должен быть простой и не держать какие-либо данные "в голове".

    -
    2. Далее я начинаю реализовывать шаги сценария
    (писать тесты)
    - Если я имею на руках желтый (не реализованный) сценарий, то начинаю уже задумываться о технических подробностях которые лежат на поверхности:
    Например (приведенный код это псевдокод для понятности

    Я должен быть на странице "Новости"
    assert( $uri, '/news');

    Я вижу заголовок статьи "Эта прекрасная статья"
    assertTextInElement('#newsTitle", $title);

    - Если я имею на руках красный тест, то пришло время для кода..

    3. Написание практически всего кода предшествует у меня BDDSpec
    (в моем случае phpspec)

    И так, я получил ошибку от bahat. Я специально настроил утилиту так что бы она ругалась ошибками разрабатываемой системы.
    В итоге я получаю такую ошибку:
    - uri '/new' not exist

    Это для меня прямое указание к действию. т.е я должен создать новую страницу.
    В рамках моей системы уже существуют правила:
    - новая страница - это новое action у контролера.
    - action должен вернуть массив значений для шаблона
    Опираясь на это я создаю спецификацию для контроллера
    class ControllerSpec  {
      public function it_should_show_news ()
      {
        $this->newsAction()->shouldBeArray();
      }
    }


    И далее код, который пройдет этот тест:
    class Controller {
      public function newsAction() 
      {
         return [];
      }
    }


    4. После этого запустив phpspec я получил зеленый bddspec
    5. После этого cнова возвращаюсь к bddstory
    Получаю зеленый шаг
    6. Возвращаюсь на шаг 2.

    Так начинает расти система и обрастать новым протестированным функционалом.

    До bdd использовал tdd c PHPUnit и был очень доволен, пока не подсел на behat + phpspec
    Ответ написан
  • Как писать тесты?

    nonlux
    @nonlux
    Ну тесты бываю разными: и зелеными и красными. ))

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

    Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

    Итак, features. Берем Behat и херачем кучу тестов по типу:
    Зашел на главную,
    Потыкал чего-то в форме регистрации
    Зашел в профиль и увидел свое имя и фотку на странице
    Profit!

    Вот в целом и получили: "Непосредственно регистрация с занесением в БД", только в этой ситуации нам абсолютно не важно что там в БД. Нам важно чтобы пользователь зарегистрировался и попал в закрытый раздел сайта.

    Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
    Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
    Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

    Следующий уровень абстракции spec:

    Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
    Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

    Главное при том и другом подходе нам без разницы, что у нас в кишках мы всегда тестируем публичные свойства системы. В первом случае это реакция на пользователя, во втором публичное API класса.

    Вот как то так!

    P.S тесты надо бы писать до кода.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (11)