Только не говорите, что вы таким не были или мой взгляд на обучение

Вам шашечки или ехать?

Заказчику нужно чтобы работник сделал работающую вещь. Что там под капотом его мало волнует.
Работнику нужно чтобы сделал и получил за это деньги. Что там под капотом его мало волнует.

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

Поведаю вам темную сторону вашей статьи
Куча людей при прохождении пути из статьи застревает на стадии

class User {
public function changeUserProfile($userId, array $userData){
        global $db; // ну вы поняли

или даже раньше
и так случится если человека не критиковал и не направлял более опытный и он не сталкивался с задачами которые потребовали бы решения средствами чуток сложнее.
Написание велосипедов полезно в комбинации с использованием грамотного проверенного кода, т.е. на простой работе человек пишет используя Laravel к примеру, а домашний проект — без использования библиотек и фреймворков. В итоге получится что то что написал неопытный будет обернуто в грамотную оболочку, но при этом человек будет постепенно все глубже понимать как это работает изнутри. И в идеале нужно давать на ревью свой велосипед более опытному человеку чтоб он указал на ошибки и почему что-то сделано неправильно.
Если оставить велосипедостроителя одного — в итоге родятся шедевры подобные этим:
habr.com/ru/post/311304
habr.com/ru/post/438762
habr.com/ru/post/283166

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

(Сарказм)

Эта вечная проблема наслаивания абстракций…

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

Ну таки Вы начинали обучение не сейчас и даже не год назад.
PHP 4.2 был выпущен в 2002, 5.2 в 2006. Были в те годы модные фреймворки? Да нет, композер то в 2011-2012 вышел.
Сейчас же на условного школьника выливается огромное количество противоречивой информации и в первую очередь человеку нужно научиться отличать устаревшую информацию от актуальной.
Как раньше — открываешь блокнот, пишешь (копируешь) код, заливаешь на бесплатный хостинг без бд, видишь ошибку с кодировками, ищешь решение, находишь нотпад++, попутно узнаешь что такое денвер и вот уже ты локально имеешь свою дырявую форму авторизации, в которой логин и пароль видны в гет параметрах.

Сейчас же ты узнаешь не об условном нотпад++, а о куче различных IDE. И да, ты можешь написать тот-же код в блокноте, но везде ведь кричат о самом лучшем IDE (и везде о разных). Уже появляется желание пойти на курс или прочитать книгу «Выбери свое IDE за 24 часа». И вот этих наворотов — композеров, фреймворков, апи, лучших практик, ORM, аджакс и прочее прочее прочее, их стало слишком много. И все это нужно, чтобы написать СОВРЕМЕННЫЙ проект состоящий из формы авторизации. А кто хочет начинать не с современного?

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

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

И проблема скорее в том что раньше в ИТ шли в основном те, кому ИТ было интересно само по себе. А теперь в ИТ идёт очень много людей, которым зарабатывать деньги гораздо интереснее чем сам процесс.

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

Можно сделать отличный курс, который подведет к фреймворкам через основы:

• от простых запросов в БД через осознание проблем, с которыми можно столкнуться, к DBAL;
• от if ($_POST['user_id'] == 1) до PSR-7 и примеров реализации в фреймворках;
• от include 'function.php' через spl_autoload к PSR-4
• от index.php?page=contacts до роутера на конкретных примерах.

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

Кажется, что все желающие идут сегодня примерно по такому же пути.

Как будто про меня написано. Спасибо добрым людям, рассказали про mysql_escape_string еще до первого деплоя.

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

Очевидно, что изучение программирования (алгоритмы и структуры данных), парадигмы и синтаксиса языка (core api), его библиотек (library/framework api) — это разные последовательные этапы. Только недобросовестная контора предлагает начинать изучать программирование с фреймворков. То же самое, что изучать, скажем, алгебру не зная арифметики.

Хренак-хренак и в прод. В общем, поэтому вовсю фреймворки и внутрь не лазят.

Да и слава богу.

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

А вот когда он поймёт, что его знаний просто не хватает для реализации чего-то с помощью фреймворка — спросит совета на форуме, и ему более опытные люди подскажут куда копать.
И ссылку на PHP Right Way дадут.

Но он уже в коммьюнити, он более-менее «вдупляет» и может сформировать правильные вопросы, потому что фреймворк провёл его уже через все буреломы — и уже не страшно, и можно уже самому залезть в терновый куст и немного там покопаться.

А то в былые годы ты прямо годами мог продираться к тому, чтобы понять, как сделать рабочий онлайн-магазин, а потом — боже святый — пароли то в плэйн-текст. А как «солить»? «А хз, солить что ли надо?» «А я никогда не солил, и всё работает, уже пять лет мой сайт пчеловодов-любителей нормально живёт.» «А я и строки не эскейплю и ничего».

Всего этого брожения умов, которые проторили себе путь с самого низа и ушли в разных направлениях — спасибо, уже наелись.

Лучше новичок, который готовыми блоками может построить дом через 3 месяца, чем доморощенный профи, который сам обжигает корявый кирпич и складывает кособоко. Первый научится правильно и сможет потом ухватить детали — второму придется переломать себя.

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

Мы вроде бы и обучились, а как оно работает изнутри так и не поняли.

Сам я всего пару лет назад практически случайно с околонулевыми знаниями попал в разработку, сразу в продуктовую команду с yii1/yii2.
На мой взгляд писать на фреймворке и не разбираться как он работает изнутри возможно только в одном случае — если верх сложности для ваших задач это вывести данные из БД на страничку.
Иначе варианта два:
1) Ты пишешь с большим количеством ошибок (ни одни фреймворк не компенсирует отсутствие опыта и профессиональных навыков), наступаешь на одни и те же грабли, начинаешь копаться почему ты на них наступаешь и неизбежно постепенно погружаешься в документацию и понимаешь как же это все там работает под капотом.
2) Ты пишешь с большим количеством ошибок, но процессы в твоя команда достаточно профессиональна и процессы в ней налажены достаточно хорошо и твой код не проходит ревью, а фидбеком ты получаешь ссылки на документацию/статьи/объяснение почему так делать не стоит. В итоге постепенно ты также становишься лучше даже невольно начинаешь понимать как оно там все работает.

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

Проблема тут в том, что любой другой язык изучают сначала отдельно, а потом прикладывают к фреймворку. Тот же Python — никак не получится (ну ладно, получится, но будет малоэффективно) сразу изучать Django, нужно понимать, как язык работает. А курсы по PHP, видимо, пытаются пропустить эту стадию — и преуспевают, потому что язык и фреймворк это поощряют.

Писал это и подумал, что тут ещё роль играет фактор поверхностности подхода. Не хочет клиент писать бэкенд и фронтенд, клиент хочет, чтобы был сайт, и чтобы сайт работал — поэтому ему вполне хватит человека, который не знает, как фреймворк под капотом работает. Сложных задач всё равно не будет, а когда будут, можно нанять более сложного разработчика прикручивать их к тому, что уже есть. Грустно, согласен, но закономерно.

Хм, а вот и обратная сторона:
Я начинал PHP ещё в школе, писал что-то похожее из статьи по книжке. В книге было и как написать простые счётчики и небольшой форум с необходимым функционалом. Также было написано про разные возможные уязвимости (XSS, SQL-inj) и как их избежать. После этого я написал свой сайт полностью с нуля (с файликами sys.php, logout.php и прочим), который до сих пор в таком состоянии и находится вот уже более 10 лет (смотреть в тот код довольно неприятно, но немного его поддерживаю, недавно перевёл на PHP 7 и фиксил основные ошибки).
Так вот, имея такой бэкграунд, я узнал о фреймворках и… они показались мне очень сложными. Я смотрел Yii, его основные концепции MVC, шаблонизации, ORM. Выглядело чересчур усложнённым и вместо того, чтобы взять и просто использовать, я написал свой MVC каркас (ну как же, я же знаю PHP, напишу лучше и проще, думал я тогда). Там были основные модули, подобие шаблонов, но в основном оно не ушло далеко от примеров из той самой книжки, с которой я начинал.
Понимание того, что надо использовать фреймворки для упрощения себе жизни, а не строить каждый раз свои велосипеды, пришло позднее. Да, тот каркас был очень прост и понятен, к нему можно написать расширения и мне повезло, что его архитектура позволяла реализовывать много нужных вещей. Но его сложно поддерживать, расширять и весь базовый функционал логина, работы с базой нужно писать самостоятельно каждый раз.
Но понимание этого пришло не сразу, а когда я уже сменил место работы. А мой MVC каркас так и продолжает жить в старых проектах и мне немного за это стыдно.

Очень спорно! Хотя мой коммент будет не менее спорным

TL;DR Надо доверять абстракциям.

Дальше пойдёт в основном про front, но думаю справедливо и для PHP
Чем дальше углубляешься, тем больше радуешься, что за тебя уже всё продумали и реализовали, осталось только это соединить и решать бизнес задачи.

Конечно углубляешься, натыкаешься, иногда вдохновляешься что-то запилить, но представив себе весь объём, который вот так самому наклипав изучить, понимаешь что и десятка жизней не хватит. Сброщик, фреймворк, ui kit, и каждый состоит из модулей и к нему еще идут плагины, так еще же есть IDE, сам язык, его движок, погоди а браузеры, их особенности, погоди а REST, GraphQL, а WebSockets, Events и т.п. и т.д.

Хорошо — это ваша специализация, а ось, а микросхемы? Ну вы поняли.

Мой первый скрипт — это jQuery без js. Цепочка вызовов, перемещение по дум, навешивание событий и ни каких переменных и функций. Но по живой книге, дальше конечно изучил сам язык, подтянулись фреймворки.

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

Да и я не думаю что новичку надо прям разъяснять с самого начала всю разницу прототипных классов от классического их понимания.

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

Бросил я радиоэлектронику в 2005м. Прошел путь от ламп, транзисторов, логических микросхем. До микроконтроллеров, увы не дошел.
И в 2006м я удивился — как парень, который нифига не знает радиоэлектронику (к слову — никак) — чинит принтеры и компы. Как происходило: включает комп — не грузится. Начинает с малого — память вытащит — другой заменит и пошел по компонентам. Потом повзрослел и по сигналам биоса определял в чем дело. Напомню — радиоэлектронику он и не начал учить. Потом вижу пошел дальше — феном материнки восстанавливал, видеокарты грел — и блин — работал метод.
Второй пример — вместе в радиокружок ходили с челом. Потом он начал чинить телефоны, потом смартфоны. Но я видел что он застрял еще тогда на лампах и чуть позже на выдергивании конденсаторов «КМ» и прочего драгмета. И он чинит смартфоны. Свой небольшой бизнес у него. Как? Я без понятия.

Они пропустили все основы, все азы. И тупо ремонт блочным методом. Так вот и программирование для многих — черный ящик с «подай сюда, то — получишь на выходе это».
А как больно смотреть сейчас как люди сайты на вордпрессе с помощью Elementor «программируют». И это у них на потоке.

p.s. я тоже сейчас учусь на своих костылях и грабли на моем пути — их много. Если кто зайдет и из последних моих работ на гитхабе раскритикует в issue — буду признателен.

svoysredychuzih.livejournal.com/119943.html — вспомнил из прошлого анекдот, я первый раз его в 2004 году увидел. Очень похож подход дельфиста, кстати с тех пор к дельфистам остался стериотип из анекдота…
Ну не суть.
Для меня большая разница между тем, что тогда и тем, что сейчас — интернет, а именно легкость к получению большого кол-ва разностороннего материала.
Уже на старте, и сейчас и тогда, наверное, каждый понимал, что есть проблемы с защитой, с ресурсами, с универсальностью, с производительностью.
И если не брать случаи, когда хотят просто по быстрому срубить и свалить и больше не начинать, то каждый уже сам осознано принимает решение.
«Да, я понимаю, что в моём проекте много дырок, но кому он нужен», «Да, оптимизацией с точки зрения производительности не занимался, но он и так пойдёт, а дальше расти не будет», «Да, проект запуститься только у меня и на таких же кранах, как у меня, ну и больше никому не надо ...» и так далее.
Если же не так, то как минимум будет поиск —
Ddos атаки, как избежать
уязвимости сайтов
java/php/c#/…. best practice
UI/UX/адаптивный дизайн

Хорошо написал. Поддерживаю.
Я больше администратор, чем программист. Несколько недель назад в телеграм-чате зацепился с человеком. По его сообщениям до, человек производил впечатление опытного системного администратора, программиста. Даже, как то стыдно рядом с таким умничать, но я как-то сумничал понеслось, поехало, стал ему писать в личку, а потом в разговоре о Cygwin, он и раскрылся. Этот пацан по верхам нахватался всех этих популярных терминов, покатал чуть docker, может посмотрел обучалки по нему, не знаю, как, но человек реально в базе, в истории развития сред, в операционных системах мало что шарит, но увидишь это не сразу, а по оговоркам. Нет, конечно, может очень крутой админ его сразу бы разобрал, но мне потребовалось время. И в индустрии сейчас очень много петухов такого плана, которые своими яркими перьями и дичайше скоростным результатом, хоть и плохим, вызывают большие симпатии у окружающих и работодателей. Сейчас настало время модных хипстеров. Как всю там работает на низах, все эти протоколы, работа с памятью, ввод-вывод — не нужно, когда есть верхняя надстройка всё это делающее, пусть и не эффективно, пусть и дырявая, пусть даже падучая. У нас есть утилиты, которые будут отслеживать её падение и будет запускать. Да, да и это в прод. Директор всё равно не разбирается. Мы же ему не машину постоянно глохнущую на нейтрали даём, тут он точно не поймёт, где его «набманули»(этот термин придумал мой брат ещё, когда мы были совсем малышами).
Грустно это всё.

А вред от великов именно в корпорациях плохо. Глупо писать свою систему задач, при наличие уже безчисленного множества. Как минимум, можно взять за основу готовую. Но, всречаются и такие велосипедостроители, которые берутся в организации разработывать свой велосипед, собирая для этих целей целый отдел. Да и в целом открытое ПО развивается как-то на месте. Появляются всё более новые изощрённые методы, программы выполняющие известны функции, однако существуют целые прослойки, которые стоят на месте, потому что велосипедить там, где просто — легко, а в сложные дебри лезть не охота, может вообще не получиться.

На мой взгляд, странно, что основами программирования, с которых нужно начинать свой путь новичкам, называются устаревшие подходы к проектированию кода на PHP. При том, что автор сам называет их неправильными. Если я начинаю программировать в 2019, зачем мне допускать такие же ошибки, как те, кто начинал в 2009?

Хорошая статья, мне понравилось. Я преподаю в колледже и думаю, как лучше выстроить курс преподавания JS и PHP. Как не пропустить ничего основного и в то же время научить работать с фреймворком (например Yii2). Статья натолкнула на определенные мысли

Забавно но о всех видах атак я знал за долго до того как смог написать что-то работающее, и мой первый велосипед был непробиваемым и не sql injections не xss там не было. Так что нет, я никогда таким не был, совсем никогда.