Задать вопрос
  • Поддержка релизов в Git, без головной боли. Как?

    igor_shevchenko
    @igor_shevchenko
    Веб-разработчик
    Мы тоже искали решение подобной проблемы и пришли к тому, что меньше всего боли нам доставляет вот такой модифицированный gitflow:

    • Код на продакшн заливается из ветки master.
    • Код на тестовый сервер заливается из ветки develop.
    • Все задачи делаются в отдельных feature-бранчах. Важно, что feature-бранчи ответвляются от master.
    • Разработчик, завершив работу над задачей, мёржит ветку этой задачи в develop.
    • Вмёрженные в develop задачи заливаются на тестовый сервер, где их сможет проверить тестировщик.
    • Когда приходит время релиза, feature-бранчи для всех задач, которые должны быть включены в него и успешно протестированы, мёржатся в master.
    • develop никогда не мёржат в master, потому что там может быть непроверенный код с багами.

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

    Этот workflow подойдет не всем, многое зависит от сложившихся в команде процессов. Но в ситуации, которая описана в вопросе, он должен помочь (возможно, с небольшими изменениями).
    Ответ написан
    Комментировать
  • Как перенять объектно-ориентированное мышление?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.


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

    То есть по сути наше приложение - один объект. У него внутри вообще все. У этого объекта есть один метод - обработай запрос. Когда внешний мир его вызывает, меняются значения каких-то переменных, вызываются какие-то внутренние "приватные" для внешнего мира функции, и делается работа.

    Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

    И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

    А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

    Вообщем писав всё время на процедурке, сложно перейти на ооп.


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

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

    Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.


    Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

    Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

    Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.


    Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.
    Ответ написан
    3 комментария
  • Подкиньте несколько примеров веб приложений?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Из того что стоит посмотреть:

    https://github.com/martinmicunda/employee-scheduling-ui
    Ответ написан
    Комментировать
  • Как разобраться в данном коде и понять его алгоритм?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ответ написан
    Комментировать
  • Зачем тестировать код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.


    вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

    С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

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

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

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

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

    По сути это самое сложное в тестировании. Писать тестируемый и поддерживаемый код, а так же останавливать себя от тестирования "лишних" частей системы или слишком углубляться в тестирование там где этого не нужно.
    Ответ написан
    1 комментарий
  • Как правильно организовать базу данных?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1-ый вариант. Не усложняйте на ровном месте.
    Ответ написан
    2 комментария
  • Как эффективно изучать angular js?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) продолжаем учить "ванильный JS", паралельно почитывая про babel, es2015 и т.д.
    2) когда мы ищем информацию в интернетах - учитываем что сейчас актуальная версия ангуляра - 1.5, второй ангуляр в бете, так что 90% информации устарело. Я даже больше скажу - даже официальная документация устарела, обновленный вариант сможете найти на github проекта в пул реквестах.
    3) https://github.com/gdi2290/ngExam - рекомендую этот список тем того, что вам надо знать про ангуляр (ну и не только).
    4) https://github.com/AngularClass/NG6-todomvc-starter - тут я попытался собрать полезные статьи на тему что надо учить и как + пример маленького современного приложения. Так же в ишусах к NG6-starter обсуждается как лучше его готовить.
    5) https://habrahabr.ru/post/277087/ - про angular 1.5 и то как я готовлю ангуляр.

    Ну и так же не стоит пренебрежительно относиться ко всяким реактам и эмберам - идеология у всех приблизительно схожа, все крутые чуваки юзают компонентный подход (потому что это удобно и логично для проектирования интерфейсов), у всех примерно одинаковое виденье по поводу data-flow в приложениях и т.д. Так что с ними ознакомиться тоже можно, у реакта чуть больше расписано про компоненты например.

    Ну и да - обязательно прочитать документацию к ангуляру. Возможно не всю сразу но базовые понятия что бы раскрыть. И разобраться с тем что значит "декларативное представление".
    Ответ написан
    4 комментария
  • Какой micro framework посоветуете?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Берите Symfony 3 в режиме микроядра. Профит:

    по умолчани - микрофреймворк, если этого будет не хватать - можно быстро перейти на symfony full stack решение. Ну и по качеству кода и тд. у компонентов симфони конкурентов нет (разве что zend может тягаться).

    вот только без ORM.


    Composer же, можно любой взять пакет реализующий ORM. А еще хороший вопрос - нужен ли вам ORM. Это не что-то что дефакто должно присуствовать. Скажем если у вас в качестве базы данных монга - то ORM уже не нужна, так как нет связей между документами (точнее их не должно быть).

    не навязывал свою структуру/архитектуру

    Этому пункту соответствует. Есть общепринятый best-practice но он в принципе только о общих вещах. А структуру вашего кода - это уже сами решайте. Так же нет никаких ограничений по архитектуре вашего приложения, симфони предоставляет вам только адаптеры для UI (HTTP, CLI и т.д.), то есть организация UI приложения. Приложение же само хоть на plain php может быть, просто пользовать инфраструктурой предоставляемой симфони.

    цеплять любые файлы независимо от их "географического" положения.


    Это вы сейчас об автозагрузке или что? Какие файлы? Хватит мыслить файлами, мыслите объектами, нэймспейсами и т.д. А мэппинг этого на файлы один раз прописывается в composer.json.

    p.s. Опять же, фреймворк это всего-лишь набор инструментов. он ничем вас не обязывает. Симфони один из немногих фреймворков который предоставляет свободу. То есть есть по дефолту структура, но вы ее поменять можете как захотите.
    Ответ написан
    1 комментарий
  • Error Number: 1146 Table doesn't exist как решить?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    В отсутствии таблицы `ridehost`.`tbl_user`
    Ваш К.О.
    Ответ написан
    2 комментария