Становимся профессиональными PHP разработчиками. Часть 1: Недостающее звено

[Biblusha]

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

[Fesor]

Используйте ООП как можно чаще – пишите классы

Проблема в том что если начинающие разработчики будут просто «писать классы» то это еще не значит что они будут использовать ООП. Вы собственно в предыдущем абзаце это и говорите.

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

я могу искренне посоветовать вам Phalcon для знакомства с фрэймворками

Phalcon в качестве первого фреймворка? Серьезно? Нет, как фреймворк он конечно неплохой, но… надо брать фреймворки с большим комьюнити (нынче это laravel или symfony, как фреймворки с самым большим комьюнити). Фалькон — я бы сказал что это чуть другой уровень потребностей.

Мое мнение.

Начинающим надо давать «бандаж», те средства разработки которые буду оооочень сильно ограничивать его полет фантазии. То есть это строгие фреймворки и строгие инструменты которые заставляют думать что ты делаешь. Проблема с этим только в том, что брать фреймворки типа Zend или Symfony без какого-то менторинга со стороны более опытных разработчиков весьма сложно.

Так же новичкам было бы неплохо практиковать TDD. В контексте PHP можно взять PhpSpec, вооружиться принципом «если тебе неудобно писать тесты значит что-то надо делать с твоим кодом» и вперед. PhpSpec сильно ограничивает возможности того, что человек может тестировать (только публичный интерфейс по сути), удобный мокинг зависимостей (нет большой ментальной нагрузки) и легко определить когда мы сломали инкапсуляцию или там зависимостей много, стало быть мы скорее всего нарушили принцип единой ответственности. Короче надо следовать старому доброму «трехфазному» обучению (сю-ха-ри)

Проблема PHP в том что слова типа «пишем тесты» или «рефакторинг» среди PHP разработчиков не сильно то встречаются.

p.s. оффтопик на тему: What Killed Smalltalk Could Kill Ruby, Too, прикольная лекция Дяди Боба (2009-ый) на тему качества кода и как это вообще влияет.

tl;dw Smalltack умер потому что на нем можно было легко написать плохо.

[dMarley]

Phalcon в качестве первого фреймворка? Серьезно? Нет, как фреймворк он конечно неплохой, но… надо брать фреймворки с большим комьюнити (нынче это laravel или symfony, как фреймворки с самым большим комьюнити). Фалькон — я бы сказал что это чуть другой уровень потребностей.

Мое мнение.

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

[MetaDone]

мне кажется проблема не в комьюнити, а в том, что если новичек захочет разобраться как это работает, он не сможет прощелкать по классам в IDE и глянуть как же это реализовано. Если уж новичка загонять в рамки работы с фреймворками — то вначале дать глянуть какой-нибудь микро-фреймворк, типа Silex или Slim — они элементарно проще.

[Fesor]

Согласен. На примере silex например удобно разбираться как устроен Symfony (потому что на любом хоть сколько нибудь серьезном проекте из silex-а вырастает symfony).

[dMarley]

Ещё относительно недавно вышел Lumen. Тоже прост в освоении, как, собственно, и Laravel.

[Fesor]

всё сущее объявлять приватным и расширять доступ по мере необходимости.

скажите это людям, которые делают все приватным и потом просят IDE сгенерить геттеры и сеттеры для всего.

[VolCh]

Это лучшая инкапсуляция, чем объявлять всё публичным. Пускай публичный интерфейс у нас излишен и слишком детализирован, но, главное, остаётся куда бОльшая свобода манёвра в изменении внутренней реализации вплоть до проксирования, адаптирования и прочего делегирования.

[Fesor]

$entity->getEntityDetail()->breakEncapsulation(); // инкапсуляция курильщика
$entity->encapsulatedBehaviour(); // инкапсуляция нормального человека.

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

[VolCh]

Основной недостаток Фалькона в качестве первого фреймворка является таким же прямым следствием как и его главного преимущества — он написан на Си, а значит начинающий разработчик не сможет толком понять как он работает. Истинная инкапсуляция :)

[toxicmt]

По-скольку на хекслете мы обучаем php разработчиков, то постоянно сталкиваемся с вопросами роста, последовательности обучения, направлений развития. В итоге родилась «карта знаний», что учить в каком порядке и почему это важно: map.hexlet.io/stacks/php.

А если говорить про фреймворки, то много лет назад синатра, основатель жанра микрофреймворков, задала тон и движение в сторону простых каркасов. И изучать mvc лучше всего именно с них. В каждом языке минимум по три своих синатры. В php это slim, lumen и другие.

[Fesor]

Неплохая карта, эх если бы PHP разработчики учились по примерно такому плану…

[ghost404]

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

[Fesor]

Профессионалом не стать без прочения хотя бы GoF.

без понимания принципов SOLID и GRASP (да банально понимать что такое инкапсуляция) толку от GoF паттернов не много.

[ghost404]

Толку не много потому что это только каталог шаблонов, не все из которых имеют смысл в php, но без понимания что такое «шаблоны проектирования» и например чем Singleton отличается от Lazy Load, далеко не уедешь.

Можно конечно про шаблоны и в вики прочитать, но на мой взгляд в книге это лучше разжованно. А закрепив материал из книги можно почитать про другие шаблоны не описанные в книге, тот же MVC, DI, Front Controller.

Ну и про GRASP тоже книжка есть.