• Как повысить скорость разработки?

    0. Используем систему версий, делаем ветки. Перед началом работы переключаемся на нужную ветку, а не лезем в код. Таким образом мы сразу выделяем нужный кусок задачи для изменений.
    1. Разбиваем задачи на максимально понятные куски действий. Если в требуемом есть хоть что-то не понятное, не пройденное и вызывающее неуверенность, то работать будет трудно. По этому планируем задачу по изучению.
    2. С непонятным разбираемся через эксперименты и тестовый код минимального размера. Пусть эти шаги кажутся примитивными, но они легко воспринимаются мозгом. Иногда эксперименты с новым проще делать вне кодовой базы проекта на минимально необходимом коде.
    3. Чужой гадкий код форматируем для лучшего чтения. Про свой и упоминания не должно быть в этом плане. Чем хуже читается код, тем быстрее устаёт мозг его воспринимать.
    4. Стараемся код разбить на минимально понятные куски и из них автоматом собирать то что нужно.
    5. Выполненные задачи в списке отмечаем. Хорошо видеть свой прогресс.
    6. В коде оставляем тудушки (TODO), но если их список поддерживает IDE. Иначе выносим в отдельный список.
    7. Стараемся формировать свой "поток действий". Например для страницы отображения: добавить роут; добавить, если нужно, контроллер; добавить метод; добавить пустой шаблон отображения; записать в нём, что должно отображаться; добавляем в него передачу одного из нужных данных; делаем отображение или проверку его наличия; повторяем со всеми нужными данными и т.д.
    8. Перемежаем рутинное написание кода с изучением непонятного и разбором задач. При этом пишем вопросы и конспекты. Потом при новом обращении перечитываем. Не боимся быть капитаном очевидность. Находясь в контексте мы много считаем само собой разумеющимся, но при новом включении в задачу через некоторое время что-то выпадает.
    9. В выходные отдыхаем.
    Ответ написан
    Комментировать
  • Код в парадигме ООП PHP?

    try {
        $db_connection = new DbConnection();
        $user_repository = new UserDbRepository($db_connection);
        $owner = $user_repository->findById($user_id);
        if (!$owner) {
            throw new UserNotFoundException("Автор с идентификатором \"{$user_id}\" не найден");
        }
        $article_repository = new ArticleDbRepository($db_connection);
        $articles = $article_repository->findByOwnerId($owner->id);
    
    } catch(UserNotFoundException $e) {
        // ...
    } catch(\Exception $e) {
        // ...
    }
    Ответ написан
    Комментировать
  • Хорошая ли практика создавать свои классы Exception для отлавливания разных ошибок?

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

    Cisco 7513
    Ответ написан
    Комментировать
  • Как отделить бизнес-логику?

    Ни Yii, ни Laravel не следуют DDD. Не заморачивайтесь. Делайте или в рамках фреймвока, или если знаете DDD, то в рамках него. Только вас погонят "лопатой по спине".

    Сейчас в издательстве Питер вышла жёлтая книжка с пчёлкой. Она хорошая. Это не реклама. Достаточно придерживаться её.
    Ответ написан
    3 комментария
  • Где найти примеры больших хороших проектов на PHP?

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

    Тоже понятие "сложный проект" - это не всегда про архитектуру. Чаще наследие по коду и не умение организовать производственный процесс.
    Ответ написан
    Комментировать
  • Как использовать ооп на практике?

    Нужно переписать кучу своего и чужого кода, что бы понять как делать правильно.
    Философия бесполезна. Всё начинается с момента, когда наконец понимаешь, как не стоит делать.
    Пока силы есть, можно много кода "лопатой накидывать". Плюс ещё IDE помогают быть беспечным.
    Ответ написан
    Комментировать
  • Куда двигаться дальше, какие паттерны проектирования используют сегодня?

    Паттерны это не ООП.
    Паттерны могут быть и в ООП.
    Паттерны сегодня - завтра анти паттерны.
    Ответ написан
    Комментировать
  • Куда писать sql запросы при реализации репозиториев (DDD)?

    Очевидно вопрос связан с современными фреймвоками типа Yii или Laravel. В них реализация упрощённая и смешанная. Совсем не DDD.

    Классические модели из DDD ничего не знают о хранении и получении "объектов". Репозитории поставляющие "объекты" для модели и сохраняющие их никакого не имеют отношения к модели. Они из окружения приложения. Описываются через интерфейсы.
    Ответ написан
    Комментировать
  • Как въехать в программирование (ООП, паттерны)?

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

    Если вы не знаете, то ничто не поможет.

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

    На уровне настройки приложения всё не так просто. Здесь большой опыт нужен.
    На уровне разработки - нужно поучаствовать в нескольких проектах с несколькими разработчиками и несколькими ушедшими. Тогда острые углы сразу начнут вырисовываться.

    Ну и читать классиков, например на предмет "запаха кода", поддержки чужого кода и хорошего кода.

    Если код читаемый - то его легко поправить даже при наличии грубых ошибок. Именно правка кода - основа разработки. Отсутствие знаний и опыта приводит к плохом коду. Отсутствие дисциплины написания кода приводит к бесполезному коду. Плохой код можно улучшить. Бесполезный - выкинуть (переписать).

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

    Если что-то меняется редко, а нужно удобно, то вполне себе оно. Ещё копировать/переносить удобно в оперативном плане.

    Какой-нибудь скрипт синхронизации с веб интерфейсом для настройки.
    Какой-нибудь калькулятор с веб интерфейсом настройки.
    Ответ написан
    Комментировать
  • Стоит ли новичку начинать с фреймворка или лучше учиться на чистом php?

    Всё зависит от того, насколько вы готовы думать и развиваться.
    1. Если исходить из закона общности, то любой код "мусор". Значит можно работать и со своим и с чужим кодом.
    2. Если исходить из закона относительности, то один код лучше другого в данной ситуации. Значит проблема связана с пониманием этой относительности и использования её.
    3. Если исходить из закона развития, то нужно преодолевать как ограниченность своего эга, так и авторитеты окружающих. Значит что в любом случаем придётся научиться осознавать глупость как своего кода, так и чужого.

    Но это если всё строится на принципе личного развития через широкий опыт.

    Если исходить из дохода, то это всё не имеет значение. Там принцип: заниматься тем, за что платят.
    Ответ написан
    4 комментария
  • Есть какие-нибудь сайты, где люди с идеей объединяются/ищут "за бесплатно" людей для реализации проекта?

    fl.ru Объединяются халявщики и владельцы сервиса для окучивания дураков мечтающих заработать.
    Ваше мнение может не совпадать с моим.
    Ответ написан
    Комментировать
  • Нужна помощь с архитектурой в MVC?

    Принцип единственной ответственности. Нельзя связывать отображение формы, очистку данных, валидацию и обработку ошибок валидации.
    Формы создаются хелперами в шаблоне и используют объект ошибок, для их отображения.
    Настроенный запрос использует стандартный запрос, чистильщик данных из запроса (на самом деле сомнительно) и валидатор.
    Валидатор использует запрос и объект ошибок.
    Объект ошибок использует сессионный объект.
    Далее есть объекты доступа к хранилищу данных и самих данных.
    И нет никакой универсальной всё выполняющей формы.
    Ответ написан
    Комментировать
  • Как разобраться в большом чужом коде?

    Возможно прозвучит странно, но используйте кроме дебага форматирование кода, расстановку комментариев с вопросами и общее описание вашего понимания с вопросами. Разгружайте голову.

    Если же есть возможность пообщаться с предыдущим разработчиком, то следует выслушать начальника транспортного цеха его. Хотя бы в общих чертах узнать логику.

    И ещё сразу совет в контексте. Если будет много копипаста и смесь грузина с чемоданом php html js и css, то требуйте до перехода к внесению нового функционала времени на рефакторинг кода. Иначе отказывайтесь.
    Ответ написан
    Комментировать
  • Каким должен быть правильный контроллер?

    На самом деле контроллер связующее звено.
    Он должен быть тонким, но не более чем нужно.

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

    И вот от сложности самой модели и её обёртки зависит тонкость контроллера.
    Чем проще реализация модели, тем толще контроллер.
    Ответ написан
    Комментировать
  • Как использовать laravel passport для restfull api?

    Как-то переводил для себя по правам доступа в passport https://docs.google.com/document/d/1Agg8WbiAKP8vfm...
    Техническая сторона в документации описана достаточно хорошо.

    Главное определится, будет ли иметь доступ только ваше приложение или ещё сторонние.
    Ответ написан
    2 комментария
  • Как правильно спроектировать Laravel приложение с уклоном в enterprise?

    Используйте Laravel и не беспокойтесь. Он построен на Symfony. Если понадобится, то использование Doctrine вместо/вместе с Eloquent возможно.

    Вы дольше будете изучать Symfony и набирать команду с его поддержкой. Проще использовать его части, а не строить из себя умного сноба, оправдывающего высокую зарплату.

    Laravel позволит быстро построить прототип. Изменить какие-то критичные части всё одно придётся. И это не отменит использование частей от Symfony.
    Ответ написан
    Комментировать
  • Какой опыт Git нужен веб-разработчику для работы в команде в компании?

    Есть основные команды. Их указали выше.
    Можно и через GUI работать, но всё же понимать, какая команда вызывается.

    И есть поток разработки. Его то же не плохо понимать.
    Вот старая, но не устаревшая статья https://habrahabr.ru/post/106912/

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