Ответы пользователя по тегу PHP
  • Как хранить подключение к БД для удобного обращения из других классов без глобальной переменной?

    @0x131315
    Пора освоить внедрение зависимостей.
    https://m.habr.com/ru/post/350708/comments/#commen...
    Это такие штуки, которые сами подставляют в конструктор класса требуемые ему зависимости.
    Например можно взять php-di пакет в composer.
    Ответ написан
    7 комментариев
  • Знание middle backend developer PHP?

    @0x131315
    База: ООП, базовые алгоритмы и структуры данных, умение гуглить.
    База для работы в команде: коммуникабельность, неконфликность, стрессоустойчивость.
    База по беку: php7, mysql, git, http, ssh, linux, phpstorm.
    База по фронту: html/css/js/ajax/jquery, работа с панелью разработчика в браузере.
    То, что отличает мидла от джуна, опыт: 2-3 года коммерческой разработки - основные проблемы с серверами, БД, сервисами, архитектурой, основные способы их решения, боль, примеры как не нужно делать, умение писать лаконичный, понятный, поддерживаемый код, библиотека готовых удачных решений (можно в голове, главное понимать, почему лучше сделать так, а не иначе), решительность. Умение рассказать об этом опыте, о встреченных проблемах и найденных решениях - без этого оффера, само собой, не будет.
    Это то, что требуется почти везде.

    Бонусом будет gitlab, postgres, docker, unit-тесты, curl, rest, elastic, regexp, операции над множествами (для фильтрации/поиска/пересечений массивов данных). Всё это можно добрать по необходимости, но работу упростит и время сэкономит.

    Конкретный бек и фронт фреймворк не проблема добрать во время работы, под конкретный проект - документация есть.
    Но как минимум по одному нужно пощупать на беке и фронте, чтобы понимать общий принцип. Я бы рекомендовал symfony и vue, но это, конечно, не принципиально.

    На некоторых позициях фронта нет совсем, или заявляется, что нет фронта. Но как правило он там есть, и база по фронту лишней не будет.
    Фронта нет только на узких api-проектах, там только работа с curl и БД. Но если проект предоставляет личный кабинет, настройки - этот личный кабинет и формы настроек придется писать и поддерживать, а это фронт.
    В общем php без html почти не бывает, а html без css/js/ajax и подавно.

    Верстка скорее не нужна, чем нужна.
    На большинстве позиций в IT-компании базы по фронту достаточно, т.к. основную работу по вёрстке будут отдавать конкретно верстальщикам или фронту, от тебя максимум, что потребуется - точечно поправить какие-то мелкие баги верстки(поправить размер/цвет/текст), внедрить ajax, натянуть вёрстку, вывести данные, подключить стили/скрипты. База по фронту позволит серьезно сэкономить время, понимая 80% происходящего на фронте, выполнять работу быстрее за счёт намного более редкого обращения к вёртальщикам/фронтендерам, т.к. правки минутные, а бюрократия может занять дни.
    В непрофильных конторах заинтересованы в человеке-оркестре, чтобы за одну зарплату купить целый IT отдел. Но и зарплаты там намного меньше, чем в IT-компаниях, т.к. IT в непрофильных конторах не является основным источником дохода, а скорее идёт как довесок, без которого нельзя, но от которого хотелось бы избавиться. Так что требований будет больше: админ-фуллстек-дизайнер-менеджер за 30к.
    Ответ написан
    Комментировать
  • Как эффективно выучить PHP?

    @0x131315
    ИМХО ключевое в php, когда имеешь базу - это не сам язык, а понимание того, какую роль он выполняет, и какое место в архитектуре эта роль занимает.
    Что касается php, то это в первую очередь скриптовый язык, созданный специально для связи Фронта с Беком, т.е. основная его функция - предоставление доступа к БД сервиса для html и js-кода, работающих на фронте.

    На сегодняшний день php решает следующие задачи:
    -доступ к БД
    -вспомогательные вычисления
    -шаблонизация
    -связь с внешними сервисами
    -предварительное кеширование

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

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

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

    Очень важно изучить php.net
    Не обязательно штудировать всё, но стоит как минимум взглянуть что там вообще есть.
    Этот сайт - нечто вроде документации по STDLIB языка, в ходе практики ты к нему будешь возвращаться ещё тысячи раз.
    Многие задачи, которые ты планируешь решить велосипедом, уже решены за тебя, и входят в язык - нужно просто знать про то, что язык умеет из коробки, а что нет.

    Очень важно поработать с фреймворками и репозиторием composer: большинство из задач, которые встанут перед тобой, уже кем-то решены, и существует либо готовая библиотека, либо как минимум публичный интерфейс, который ты можешь реализовать, чтобы не натворить архитектурных ошибок.
    Посмотри на symfony, почитай стандарты PSR.
    Большинство задач решается декомпозицией алгоритма, и сборкой приложения из готовых библиотек или PSR-интерфейсов. Остаётся только это всё сконфигурировать, и дописать немного кода для склейки всего этого в единое приложение.

    Т.к. php - это прокладка между html и БД, обязательно нужны основы html, SQL, и практика по развертыванию, проектированию, и управлению какой-либо СУБД.
    Наиболее популярная и простая СУБД - MySQL, на ней и сконцентрируйся. Намного позже, когда будет опыт, обязательно попробуй postgres - это намного более совершенная СУБД, но она сложнее MySQL, и новичкам с неё начинать не стоит.
    Особо углубляться в sql не стоит, т.к. в чистом виде с ним будешь работать мало, по большей части взаимодействие с БД сведётся к установке ORM-библиотеки, например doctrine2. Вот ORM стоит изучить плотнее, они предоставят тебе простой и приятный доступ к данным в БД, и обеспечат лёгкие миграции состояния БД.

    Что касается курсов - они очень ценные, особенно для новичка. Быстро вводят в строй.
    Но на практике все это выливается в год-два кодинга ради кодинга, что не особо эффективно.
    Обязательно нужна практика, желательно боевая.
    Советую либо посетить фриланс-биржу, и начать выполнять чьи-то хотелки, либо попробовать устроится, можно на удаленку, в какое-нибудь агентство, которое клепает сайты, и начать выполнять самые простые боевые задачи.
    Такая практика прокачает тебя намного быстрее, и не позволит забыть то, что выучил. Но без курсов она будет однонаправленна: в реальной работе разработчики используют лишь малую часть из того, что может php, но знать нужно все - это сделает тебя профессионалом.
    Поэтому нужно комбинировать практику с курсами.

    Очень сильно поможет хороший редактор кода, например phpstorm - он будет подсвечивать твои ошибки, предоставит интерактивные подсказки по коду, и позволит быстро инспектировать код большого проекта, параллельно работая с ФС сервера, БД и docker-контейнерами. Серьезно ускоряет и упрощает работу.
    Ответ написан
    4 комментария
  • MySQL+PHP и компилируемый язык?

    @0x131315
    Исходя из описания, будет большая БД и простенький клиент для неё.
    Основные требования - именно к БД: распределенность, отказоустойчивость, расширяемость.
    С первыми двумя всё просто: кластер.
    А вот расширяемость напрямую зависит от архитектуры БД - над ней стоит поработать как следует, потом что-то исправить здесь будет очень сложно и дорого.
    С кривой архитектурой не поможет ни кластер, ни оптимальный код клиента - БД будет тормозить всегда, проект придется свернуть.
    Так что всё правильно сказали - язык не столь важен, как БД. Клиентов можно наделать сколько угодно, и на любых языках - клиенты примитивные.
    А вот бизнес-логика, если она есть - её поддерживать на нескольких языках дорого. Если она есть - нужно под неё выбрать один язык, и писать всё на нем.
    Сейчас для такого в ходу go, python и php. Выбирать лучше то, что знаешь - масштабировать под нагрузку всё это можно легко.
    Для клиентов на этом языке делается api, за которым скрывается бизнес-логика.
    В таком варианте код клиентов простой и дешёвый, логика поддерживается в одном варианте, и всегда согласованна со всеми клиентами.
    Ответ написан