• Простой проект Symfony плюс DDD?

    @dzubchik
    Недавно столкнулся из похожей проблемой, сейчас пробуем применять практики DDD в проекте на symfony. Советую посмотреть на репозитории:

    https://github.com/codeliner/php-ddd-cargo-sample
    https://github.com/dddinphp/blog-cqrs
    https://github.com/TheBigBrainsCompany/symfony-cqr...

    А также почитать статьи и книги:
    Ответ написан
    Комментировать
  • Как правильно добавить метаданные к сущности Symfony?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вариант первый (тупой) - docs.doctrine-project.org/projects/doctrine-orm/en...

    Вариант второй (чуть более сложный и возможно более правильный) - страницы, категории и т.д. ничего не знают о метаданных. Метаданных знают за каким ресурсом они закреплены (урл, идентификатор сущности + сущность) и т.д. Мэпится все это сервисами и т.д. Так как нам в любой момент времени нужно всегда только один набор метаданных - нагрузку это не добавит, а вы сможете расширять это дело как хотите, и все изменения относящиеся к метаданным будут изолированы.
    Ответ написан
    5 комментариев
  • Что почитать по архитектуре приложения?

    Читай DDD от Эрика Эванса и паттерны корпоративные от Мартина Фаулера.

    Переходи с Yii на ZF2 или SF2 чтобы писать реально что-то сложное.
    Ответ написан
    Комментировать
  • MVC, правильно ли таким образом инклюдить модель и view в контроллер?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Дайте ссылку на "канонический" образец MVC


    MVC образца 1979-ого года (канонический) подразумевает то, что контроллер ничегошеньки не знает о view. Он ловит события с инпутов и конвертит асинхронные действия пользователей в вызовы методов модели. Имеется в виду модель нашей логики, модель приложения, не обязательно один класс но целая иерархия которая сама может включать сколько угодно слоев и иметь сколь угодно большую сложность. Контроллер детали реализации модели вообще не парит, инкапсуляцию для этого придумали.

    Так вот, View же напрямую подключается к модели и через обсервер подписывается на обновления состояния модели, и в случае оного актуализирует себя под текущее состояние.

    Ну это если мы говорим про олдскульный MVC который в чистом виде никто не применяет уже лет 15-20. Ну и на бэкэнде в этом нет особо смысла так как модель в рамках одного запроса-ответа поменяться дважды у нас не должна. Просто пробрасываем все необходимое текущее состояние во view и все хорошо.

    В целом у нас всеравно есть зависимость view от модели, что не ок. Потому чуваки придумали Model View Adapter (можно считать это вариацией MVP но есть нюансы).

    Суть такая. В качестве адаптера сделаем контроллер, который будет получать данные формата UI (HTTP запрос в нашем случае) и будет генерировать данные для UI (HTTP ответ опять же). То есть задача контроллера сводится всего-лишь к тому что бы получить запрос, дернуть метод модели (один в идеале) и сформировать ответ.

    Итог - полная независимость представления от модели и модели от представления. Конвертацией форматов орудует адаптер (в нашем случае это GRASP контроллер). Причем мы можем выстраивать целую цепочку адаптеров (концепция мидлвэров на этом строится), которую потом можно свести к одному главному фронт-контроллеру. Ну и подходит это не только для HTTP но и для всяких там MQ/CLI и других вариантов интерфейсов которые могут пригодиться в будущем (а могут и не пригодиться).

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

    Ну и про буферизацию вывода не забываем.

    p.s. хватит писать велосипеды, вы всеравно из этого усвоите мало чего. Возьмите какой-нибудь микрофреймворк, что бы можно было и в нутрах покопаться, и бойлерплейт пописать, и на основе уже готового подумать почему там так сделано.
    Ответ написан
    Комментировать
  • Какие существуют нотации(правила именования) в программировании?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    с переменными вида obj_jlabName вы код ревью не пройдете у подавляющего большинства разработчиков. Именуйте переменные адекватно, что бы можно было определить что в них. Завязывать имена переменных на модификаторы доступа (вообще все стоит делать приватным), или тип. Вы и так явно задаете тип, просто не пишите код так, что это бы вызывало двусмысленность. Ну и определение переменных должно быть рядом с их использованием, никаких методов на 100+ строк, если хотите добавить комментарий перед блоком кода - лучше вынести это добро в отдельный метод...

    Словом, называйте все своими именами, и будет вам счастье.
    Ответ написан
    5 комментариев
  • Идея сервиса и приложения для удобства населения. Как реализовать?

    @abcyu
    Разработчик
    Грусть нашего мира для людей подобных вам выглядит так:

    ВАМ НУЖЕН ПРОГРАММИСТ.
    ВЫ ПРОГРАММИСТУ НЕ НУЖНЫ. От слова НИКАК. СОВСЕМ. Вообще совсем никак не нужны.


    Попробуйте начать с помощью конструктора сайтов - с помощью Юкоза или Викса. Они как раз предназначены для людей без специальных ИТ-навыков.

    Или вот пример подхода:
    Человек заинтересовывает других Идея: оффлайн аналог игры EVE Online с полной генерацией всего. Что скажете?

    и где искать ЧЕСТНЫХ!!! единомышленников, которые помимо тупо прибыли и как бы увести идею


    Проблема вообще НЕ В ЭТОМ. Вы почему-то думаете, что главное - это идея. Что все мечтают её украсть. Ну и сидите на ворохе своих идей годами.

    Но же вовсе нет. Главное - ДОВЕСТИ ИДЕЮ до ума и вторая большая проблема - выйти на ОКУПАЕМОСТЬ.

    На практике все совсем по другому:

    1. Если вы так УВЕРЕНЫ в своей идее - возьмите кредит, продайте машину, заложите квартиру. Вложитесь сами. Отчего вы ожидаете, что кто-то должен загорится НЕ СВОЕЙ идеей и потратит кучу своего времени бесплатно на ее реализацию.

    2. Таких предложений - работать на халяву, вложить ОГРОМНОЕ количество своего времени в гениальную идею, которая в будущем обязательно круто выстрелит - средний программист получает каждый месяц по нескольку.

    3. У хороших программистов сейчас очень много ХОРОШО ОПЛАЧИВАЕМОЙ работы и без этого.

    4. На Хабре/Гике/Мозге и на VC есть куча грустных историй основателей стартапов: они с удивлением рассказывают, что оказывается бесплатно работать никто не хочет. Если кто и загорается идеей, то погасает через неделю или оказывается неопытным человеком и такое программирует, что лучше бы его не было.

    5. Статьи эти интересны. Почитайте. Там много подводных камней, которые вас ожидают, уже описаны.

    6. В конце всех этих статей приводится лучший путь, который основатели стартапов поняли из свой практики: или НАЙТИ деньги или НАУЧИТЬСЯ самому.

    7. Без денег интересно только тому, кто только начал этому учиться. Надо ли объяснять вероятность довести проект до завершения? Надо ли объяснять как будет выглядеть такой проект? И вероятность его работоспособности?

    8. Любой человек как только научается - сразу становится все более и более занят для вас. Он находит себе работы за деньги, а так как редкий стартап выстреливает за несколько месяцев, обычно раскрутка занимает больше года - то интерес закономерно теряется.

    9. Опытные программисты да и рады были бы. В конце концов это интересно. Но кушать хочется. А до выхода на прибыль проходит, как я уже писал - очень много времени. Нужно ВКАЛЫВАТЬ для достижения хоть какого-то результата.

    10. Ну и большая часть стартапов не выгорает. То есть БОЛЬШАЯ часть стартапов ПРОВАЛИВАЕТСЯ. Опытные программисты - как правило и постарше, и прекрасно это понимают. Зачем им ваш стартап, если кругом толпы людей предлагают им живые деньги уже прямо сейчас.

    Ну и сколько в этих 10 пунктах встретилось то, что идея ценна? Что идея главна? Что идея нужна?

    Конечно можно найти единомышленников:

    0. Харизма. Способность делать так, чтобы люди загорались. Неуверенность и вопросы - как сделать чтобы люди пошли за собой - это не часть харизмы, а даже совсем наоборот.

    1. Люди, которые еще не занимались ничем серьезным (читай: не умеют) с удовольствием включаться, может быть даже и окажутся талантливыми и работоспособными и не перегорят.

    2. Найти финансирование. Кредит, продай машину, заложи квартиру.

    3. Начни делать сам, когда проект более-менее проработан, найти компаньонов гораздо проще. Правда они тебе тогда уже не особо нужны )))

    4. Готовьтесь к тому, что единомышленники как находятся так и теряются. Иногда и за пару недель теряется очень вроде заинтересовавшийся )))

    P.S.: чтобы было ну уж совсем понятно:

    У меня своих идей штук пять. Из них как минимум 2 гениальных. )))
    Более того, мне даже никто не нужен - я сам умею.
    Нужно просто сесть и сделать.

    Вы кого хотите найти? Разработчика без собственных идей?
    Да нет таких.

    Людей без идей мало. А полно как раз таких людей, кто по какой-то причине не начинает свой проект.

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

    Мотивировать людей можно собственной уверенностью, харизматично увлекая их за собой.
    Только не забывайте, что еще людям и нужно кушать. И заработать на покушать занимает много времени.
    А реализация стоящей идеи - это ВКАЛЫВАТЬ, времени на заработать на покушать не хватает.

    И это если даже не учитывать весьма не гипотетическую, а вполне реальную высокую вероятность прогореть.
    Поэтому как только вы организуете финансирование, то люди к вам потянутся.

    P.P.S.:
    Гораздо более реалистичный вариант вы берете на себя хотя бы 50% финансирование. Остальное на энтузиазме.
    Ответ написан
    2 комментария
  • Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

    * Организация кода:
    - Никаких глобальных функций.
    - Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

    * Тестируемость (в смысле простота тестирования) кода должна быть высокая.
    - Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

    * Принцип DRY разрешено нарушать в случаях:
    - Явного разделения обязанностей
    - В тестах (каждый тест должен быть независимым, на сколько это возможно)

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

    Это далеко не полный список требований, очень много зависит от проекта в целом и от принципов, заложенных в нем. Для больших мредж реквестов 200 комментариев к коду - это ок. Дерзайте.

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    56 комментариев
  • Правильно ли я понял работу фреймворков?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Фреймворки это набор готовых решений для стандартных задач. Воспринимайте их как кучу отдельных библиотек. Скажем нет смысла раз от раза писать снова и снова маршрутизацию запросов и т.д.

    В контроллере использую готовые функции например работа с БД.

    Основная задача контроллера - быть посредником между представлением данных (HTTP например, или web интерфейс, или CLI) и логикой их обработки. То есть работать с базой данных в контроллере вы можете, но не рекомендуется (только если вы знаете к чему может это привести и чем плохи толстые контроллеры).

    Остальная логика приложения, бизнес логика - это чистый и красивый PHP. Для удобства иногда можно чуть чуть увеличить связанность кода приложения и библиотек которые вы используете но это опять же это не очень хорошо и вы должны понимать к чему это может привести.

    Но если я хочу написать например обрезание фото квадратом, то я должен реализовывать свой велик?

    Подобный функционал, обрезка картинок, работа с графикой и т.д. уже реализованы до вас. Обычно все что нужно сделать разработчику - обернуть это дело красивым интерфейсом, который будет скрывать все детали того, как происходит обработка картинок.

    Тоесть половина функционала это функции фреймворка, половина это мои велики...

    Не велики, а бизнес логика. Фреймворк предоставляет вам каркас, решение типичных задач. В случае простого CRUD соотношение вашего кода к коду фреймворка библиотек может быть 1/10. В случае сложной бизнес логики и специфичной инфраструктуры - 10/1.
    Ответ написан
    Комментировать
  • PHP+Symfony или Ruby+RoR?

    amerov
    @amerov
    Web Developer
    Symfony сложнее.
    Рекомендую начать именно с Rails, так как для начинающих много обучающих материалов.
    Symfony не для новичков.
    Ответ написан
    Комментировать
  • Как разобраться в философии symfony2?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

    Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

    Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

    | - app
    | - var
    | - src
      | - Controller
      | - Entity
      | - Bundle/
        | - MyAuthBundle/
    | - web


    ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

    Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.
    <div id="sidebar">
        {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
            'max': 3
        })) }}
    </div>


    Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.
    Ответ написан
    8 комментариев
  • Что представляет собой тестирование ?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вообще вики можно для начала, а потом уже углубляться в литературу. Вот вам кратенькое описание, цель которого больше предоставить ключевые слова для поиска.

    Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

    Сразу хочу отметить что юнит тесты это хорошо, но вот только рядовой разработчик на PHP редко пишет что-то, что стоит покрывать юнит тестами. Времени на их поддержку нужно не мало, а требования у заказчиков частенько меняются. В итоге тесты начинают комментить и толку от них становится ноль. А вот если вы пишите компонент/библиотеку, то тут юнит тесты обязательны (ну... не то что бы, но желательны). Так что я бы на вашем месте сконцентрировал внимание на первом этапе на интеграционных и приемочных тестах.

    Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

    Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

    Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

    Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

    Ну и есть еще всякие термины типа пирамида тестов и т.д. Мол лучше много юнит тестов, чуть поменьше интеграционных и мало функциональных. Тогда тесты выполняются быстрее, а покрывать все и вся функциональными тестами обычно перебор.

    Ну и опять же, есть такая вещь как здравый смысл. Некоторые вещи скажем можно вообще забить и не покрывать тестами, некоторые стоит покрыть. Некоторые не полностью, некоторые с как можно большим покрытием.... Скажем тестить UI (именно как выглядит, где какой элемент) вообще бессмысленно. На это нужно куча ресурсов. Хотя может и есть проекты где это оправдано.

    Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.
    Ответ написан
    Комментировать
  • Что почитать для php senior developer?

    @ikeagold
    Знаю только одну очень хорошую книгу: Мэтт Зандстра - PHP. Объекты, шаблоны и методики программирования (издание №3 2013 год).
    Мне подарили в 2015ом, очень крутая книга для любого языка: Э. Гамма Р. Хелм Р. Джонсон Дж. Влиссидес - Приемы Объектно Ориентированного Проектирования
    Ответ написан
    2 комментария
  • Выбор фреймворка?

    chetzof
    @chetzof
    Опыт работы:
    Zend Framework 1 — c 2010, но редко
    Kohana — c 2011, часто, проекты маленькой сложности
    YII — с 2011, пока два проекта средней сложности
    Symfony — 2011, с выхода стабильной версии, в марте запущен в продакшн первый релиз долгосрочного проекта

    Сейчас, заканчивая проект на symfony2, могу с уверенностью сказать что хоть мне Yii понравился, но возвращаться на него с Symfony2 не буду, я считаю что в ближайшем будущем темп будут задавать именно Symfony2 и Zend Framework 2, ну а остальные будут их догонять.

    Отдельные моменты которые мне особенно понравились в sf2:
    — Связка Symfony2 и Doctrine2, работа с базой данных никогда не доставляла такого удовольствия
    — Шаблонизатор Twig. Раньше я был приверженцем сторонников высказывания что PHP и сам отличный шаблонизатор, но теперь я понял насколько ошибался
    — ОЧЕНЬ гибкий и продвинутый генератор форм. К нему прилагается отличная интеграция с Doctrine2, буквально за пару строчек кода можно все сохранить в базу данных с надлежащей валидацией.
    — Очень гибкая архитектура, благодаря DIC можно поменять ну просто все что угодно. Модульность! Можно отключить что угодно, и подключить что угодно. По сути это набор компонентов, их можно использовать даже по отдельности.
    — Работает быстро. Меня этот аспект по началу беспокоил, так как не понимал как такая махина может работать быстро, но оказалось что в пакет включены production настройки, которые впечатляюще разгоняют систему. Symfony1 в данном случае и есть причина мнения что Symfony медленный, Symfony2 это совсем другой framework, надежный и быстрый.
    — PHP 5.3. и скорый переход на PHP 5.4
    — Исходники модулей и ядро расположено на github. Все разработка идет там. Очень удобно следить за изменениями. Я как пользователь git-а очень одобряют использование именно этой VCS
    — Дофига модулей (бандлов) от сообщества, это всего за пол года с момента релиза! Простой но удобный package manager который обновляет ядро и модули автоматический.
    — Хорошая документация
    — Очень продуманная структуризация проекта
    — Level up в плане поднятия опыта, много новый решений

    Также замечу что, код очень понятный и чистый, вровень с ZF, лучше и понятнее код только у Kohana. Хуже из всех код из четверки с которыми я работал у Yii… ну как, не хуже, просто своеобразный, не совсем по стандартам, я так и не смог привыкнуть к нему.

    Что не очень хорошо:
    — Порог вхождение выше среднего, «чувствовать» систему я начал только через месяц
    — Документация могла бы быть более подробной, сейчас кстати трудится сообщество над этим
    Ответ написан
    Комментировать