Интервью с Лонни Эцеллом (Lonnie Ezell) — одним из разработчиков PHP фреймворка CodeIgniter. Вместе с ним мы обсудим темы, касающиеся CodeIgniter и не только.




На заре развития интернета программисты одиночки, группы программистов, компании стали создавать сайты и веб-сервисы. Сначала данный процесс был долгий, требовал больших знаний от разработчиков. Однако, вскоре начали появляться фреймворки — программные платформы, состоящие из комплекса вспомогательных компонентов и библиотек, которые стали значительно облегчать разработку проектов.
И, пожалуй, одним из числа самых известных фреймворков является — CodeIgniter, созданный и развивающийся в компании EllisLab и несомненно занявший определенную нишу.

Как известно, этот фреймворк имел очень большие трудности в процессе своего развития. Однако, как бы странным это не было, он сумел выжить. После долгого застоя в развитии, CodeIgniter был передан новому владельцу Технологическому институту Британской Колумбии (от англ. British Columbia Institute of Technology — ВСІТ).

Разработчик ядра новой версии фреймворка, CodeIgniter 4, Лонни Эцелл согласился дать интервью и пообщаться с ним о CodeIgniter, инструментах разработки, фреймворках и увлечениях.

— Привет, Лонни! Я очень рад, что ты согласился дать интервью. Расскажи нам о себе, где ты работаешь и что ты делаешь.

— Привет, Илья. Благодарю тебя за вопросы для меня! Я был независимым консультантом полный рабочий день с 2009 года, хотя я делал веб-разработки за пределами моей основной работы в течение нескольких лет. Впервые я начал использовать CodeIgniter еще в 2006 году, если я правильно помню! На протяжении многих лет я работал с несколькими большими клиентами и партнерами, создавая разного размера и типа сайты, являясь ведущим разработчиком на некоторых довольно крупных проектах, в том числе:

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

Я также имел умеренный успех в паре проектов с открытым исходным кодом, Bonfire и Sprintf PHP, которые оба были созданы, чтобы обеспечить к использованию набор готовых инструментов для создания приложений на основе CodeIgniter.

— Каким образом ты начал работать над CodeIgniter 4?

— Как и все остальные, я наблюдал за CodeIgniter, проходя через его сухой период, когда EllisLab не обновлял его. Они объявили, что ищут нового владельца, и почти год прошел без каких-либо слов.

Очень не хотелось видеть, как он умирает, поэтому я связался с EllisLab, чтобы увидеть, что они искали в новом владельце, чтобы, если это просто возможно было, что я мог объединить команду и взять на себя право собственности. Вместо этого они только согласились передать новым владельцам, BCIT, хотя они еще не объявили этого.
Мне очень хотелось, помочь с проектом, поэтому я связался с Джеймсом Парри, чтобы увидеть, как я мог помочь. Несколько недель спустя, меня попросили быть частью Совета, который он собирал, чтобы помочь с фреймворком.

Я думаю, вы можете сказать, что я стал таким же активным в CodeIgniter 4, потому как я был слишком нетерпелив, чтобы увидеть этот фреймворк развитым! В то время как особенности обсуждались как на форумах и в Совете, я начал строить идеи, которые CI 4 мог бы использовать. Главной из них являлось размышление об основе Dependency Injection контейнера. Я играл с модифицирующим ядром версии 3, чтобы использовать контейнер, а также библиотекой событий, которую я создал для Sprint. Я знал, что вероятность его использования в конечном продукте была слабой, но я был взволнован о будущем. Поскольку элементы архитектуры проекта стали более устойчивыми, я начал заниматься одной частью за один раз, обсудив детали сначала с группой, затем возвратившись, чтобы сказать, «Эй, у меня есть первый проход в этом в месте. Мысли?». В основном мое рвение и моя способность выкроить больше времени, чтобы работать над ним, чем другие члены команды, закончились со мной взятием на ведущую роль в проекте — что-то, что я никогда не намеревался делать. Это — огромная, сложнейшая задача!

— Расскажи нам о текущей команде CodeIgniter. Сколько людей в команде? Кто несет ответственность за то, что в данном проекте?

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

Джеймс Парри является руководителем фреймворка, как член BCIT, курирующим проект. Он держит нас на пути и организовывает и является одной из главных причин, почему проект все еще жив сегодня.

Андрей работает над CodeIgniter в течение многих лет, прежде чем BCIT принял проект. Он последний оставшийся член того, что было командой реактора EllisLabs некоторое время назад, и был единственным хранителем фреймворка в течение нескольких лет, когда фреймворк был официально вял. Под его руководством, тем не менее, у 3 версии фреймворка было больше обновлений и исправлений ошибок, чем имела какая-либо предыдущая версия. Без его руки я убежден, CodeIgniter никогда не выжил бы. Он до сих пор занимается CI 3 и делает много исправлений безопасности и работы с сообществом на текущей кодовой базе.

Я в настоящее время руковожу над 4-й версией.

Мэт Уитни был удивительным членом сообщества в течение последних 3-4 лет, всегда предоставляя полезные и подробные ответы. Он является самым новым членом команды, и начал работать над слоем базы данных 4-й версии, прежде чем его не затянула немного назад основная работа. Хотелось бы надеяться, что он сможет быть активным снова в ближайшее время.

— CodeIgniter долгое время не развивался. Сможет ли CodeIgniter догнать другие фреймворки?

— Я предполагаю, что мне приходится нелегко с идеей «нагнать» как что-то, что это требуется. У каждого фреймворка имеется различная направленность и методология. Каждый из них удовлетворяет различные потребности для разных программистов, или даже различных приложений. В этом отношении CI 3 все еще имеет это место. Когда люди говорят такие вещи как «наверстывание», я думаю, что это происходит в основном в связи с тем, что чтобы не было отставания от того, что предлагает сам язык. Для меня большими пунктами, чтобы прийти к популярности, в последние годы являются Composer пакеты, Dependency Injection, и легкое тестирование, которые идут рука об руку. Composer был поддержан в CI 3, официально выпущен, и я успешно использовал его во многих проектах. Будет ли версия 4 идти в ногу с языком и многими из лучших практик популярных в настоящее время? Абсолютно. Dependency Injection используется повсеместно в фреймворке. Мы создаем способы упростить тестирование приложений с помощью PHPUnit и встраиванием этой поддержки в фреймворк. Поскольку PHP 7 является обязательным требованием, мы можем воспользоваться рядом новых функциональных возможностей языка без необходимости поддерживать совместимость с более старыми версиями PHP. И больше, конечно :)

— Многие опасаются, что CodeIgniter перестают быть простым, быстрым и гибким. Как сильно фреймворк изменится?

— Это абсолютно понятное беспокойство. Тем более, что вы смотрите на другие фреймворки и видите, насколько сложными они могут быть. И это — что-то, что я пытаюсь всегда иметь в виду. Где возможно, я попытался сохранять опыт разработчика очень похожим на то, к чему они привыкли в версии 3. Вещи не будут идентичны, но хранение простоты, и дружеские отношения были большой целью. Как только вы получаете удобное использование, делая все это по старому, вы обнаружите, что становится все более комфортно с несколькими конструкциями языка, такими как пространства имен, можно действительно расширить гибкость и мощь ваших действий, иметь доступность, которые вы никогда не делали прежде. Модуль, как функциональная возможность, может быть осуществлена с использованием пространства имен и несколько функций помощника, мы предусмотрели погрузку статического содержания, таких как помощники или отображения, от namespaced папок, например. Я думаю, что вы найдете, что большинство из действительно больших изменений находящихся в ядре фреймворка и являющихся вещами, которых вы никогда не должны касаться, если вы не хотите.

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

— Обратная совместимость для старых проектов будет нарушена? Насколько будет легко перенести приложения со старых версий фреймворка?

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

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

— Как долго будет поддерживаться CodeIgniter 3?

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

— Можем ли мы ожидать в будущем появления официального репозитория на GitHub для CI Community Apps?

— Я думаю, что это — прекрасная идея, но та, которая еще не была обсуждена в Совете. Это действительно приносит свои собственные проблемы, все же. Не наименьшее количество — появление, что у BCIT есть некоторая рука в поддержании тех проектов, которые не обязательно имели бы место. У нас в руках есть просто полный фреймворк! Я думаю, что гораздо более вероятно, чтобы увидеть каталог приложений и потенциально специальное пространство на форуме для некоторых приложений сообщества. Об этом действительно пока слишком рано говорить, но, тем не менее.

— С какими трудностями ты столкнулся при разработке архитектуры фреймворка?

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

Во-первых, попытка найти баланс между «чистым» кодом и простотой является постоянной проблемой. Слишком много абстракций в коде может быть проблематичным, но современные концепции SOLID программирования побуждают нас разделять вещи друг от друга везде, что приводит к разным типам сложности, если вы не очень осторожны. Попытка не держать все части в вашем уме во время навигации через 7 или 8 слоев абстракций не лучше, на мой взгляд, чем наличие запутанного кода спагетти. Тогда он просто становится «лазаньей» :). На протяжении всего развития, моя общая практика должна была начаться с единым классом в памяти. Тогда части были бы выделены только по мере необходимости. Часто, массив действительно делает все, что нужно делать, не требуя Коллекции или Сумки быть созданными только для этой цели. Я обнаружил, что знание шаблонов проектирования может быть опасным в разы, и должно быть использовано, чтобы помочь вам реорганизовать вещи, а не проектировать с фронтом. Ничего из этого не предназначено, чтобы колотить SOLID, потому что я думаю, что принципы правильны. Я просто думаю, что они много раз злоупотребляются, и ключ находит тот баланс.

Во-вторых, и это связано с первой частью, является производительность. Большинство шаблонов, которые люди знают сегодня, прибывает из скомпилированных языков, и многие имеют прекрасный смысл в этом отношении, хотя они часто берутся слишком далеко. Чем больше слоев, которые ваше приложение имеет, или больше файлов, определенно, тем хуже фреймворк собирается выступить. По крайней мере, без любых дополнительных слоев в месте, чтобы выручить, как кэширование используемых классов в единый класс, и т.д. Это — постоянная проблема улучшить кодовое качество, не дрейфуя слишком далеко от сырой работы, которой известен CodeIgniter.

— На какой стадии находится CodeIgniter 4?

— В настоящее время мы как раз собираем место, где наш первый этап был поражен. Это означает, что почти все ядро фреймворка, включая то, как все части совмещаются, и системные работы в целом, имеются. Ты можешь взять то, что мы в настоящее время имеем и создать приложение из него. Маршрутизация работает, вид работает, многие меры безопасности уже находятся на месте, протоколирование, обработка ошибок, некоторые дополнительные инструменты отладки, они все на месте. Слой базы данных — последняя часть, прежде чем ядро будет сделано, и готово быть перемещенным в его дом в BCIT и открытым до большего количества помощи извне. И слой базы данных идет приятно, хотя в течение первого этапа он, вероятно, полностью будет поддерживать только одно или два ядра базы данных. Я должен добраться до документации, где мы теперь, и, как всегда, продолжать улучшать нашу тестовую оценку.

— Что ждет CodeIgniter в будущем?

— Я думаю, что CodeIgniter имеет большое будущее впереди. Лично, я готов начать использовать его новую версию! Я думаю, что гибкость и скорость поможет вернуть его популярность в сообществе разработчиков. Я также взволнован, чтобы видеть то, что сообщество делает вокруг него. Ты упомянул Community Apps, и я думаю, что это — прекрасная инициатива, чтобы произойти, хотя я поощрил бы людей сделать это в качестве основы фреймворка, насколько это возможно.

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

— Как обстоят дела с CodeIgniter на фрилансе? Он продолжает быть востребованным? Или на CodeIgniter поддерживают только старые проекты?

— Я думаю, что спрос на CodeIgniter во фрилансе определенно понизился и стал омраченным Laravel, Symfony и Zend. Хотя, это вовсе не значит что новые проекты не разрабатываются с ними. В моем внештатном опыте это действительно сводится к тому, о чем клиент знаком или услышал больше всего. Много раз клиенты, не слишком разбирающиеся в технологиях, и имеющие друзей, которые любят один или другой фреймворк, таким образом, они делают это требованием. В другое время, они будут доверять вам, чтобы знать лучшее и не заботиться.

— Какие инструменты в процессе разработки ты применяешь?

— Я стал огромный поклонник PHP Storm, как моей IDE. Я использую Sequel Pro на моем Mac для работы с базой данных. И, в зависимости от проекта, я буду иметь либо локальные настройки среды разработки через MAMP Pro или через Vagrant Box. В случае CI 4, у меня он работает как под MAMP и Homestead Improved Box, который дает мне легкий доступ к обоим Apache установке и NGINX установке.

Таковы мои основные инструменты, но я нашел более мелкие приложения, чтобы иметь неоценимое значение и использую довольно часто, тоже. Приложение Patterns позволяет легко экспериментировать и получать регулярные выражения. SourceTree для неежедневного использования Git. Iterm (или PhpStorm) для моих потребностей терминала. К Sublime Text еще привыкаю тоже, так как это установлено в качестве приложения по умолчанию в Finder для файлов кода, так как он открывает быстрый и имеет все силы и форматирование мне нужно. Приложение Color Picker получает много использования при преобразовании PSD в HTML / CSS.

— Какие другие фреймворки ты используешь в своей работе и почему?

— В то время как я попробовал много фреймворков, главными двумя, что я использую, является CodeIgniter и Laravel. CodeIgniter — это то, что я считаю «домашним». Он всегда делал 99%-й процентов тех вещей, что мне необходимо, без большого количества волшебства в нем, которое может время от времени мешать. Я использую Laravel, если клиент просит его, что они делают, кажется, все больше и больше. Я надеюсь, что версия 4 CodeIgniter может изменить это. :) Тейлор сделал большую работу с опытом разработчика, таким образом Laravel приятно использовать.

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

— Существует, безусловно, опасность у людей, не учащих основной язык и только изучающих инструменты RAD. Я думаю, что это особенно верно в первых годах карьеры разработчиков, когда они просто пытаются добиться поставленной цели. Это — плохая вещь, правда? Да и нет.

Это — проблема потому, что чем больше инструментов то кто-то должен учиться начинать делать что-то, тем больше препятствий, чтобы видеть, что что-то происходит. Для некоторых я думаю, является препятствием учится X, Y, и Z именно потому, что они могут начать делать A, и это является действительно проблемой, потому что они отступят и сделают что-то еще. Я знаю, что был виновен в этом, когда дело доходит до изучения ReactJS в последнее время.

Это — не плохая вещь, так как, в том смысле, что некоторые из тех инструментов, как фреймворки, помогают им быть более продуктивными, помогая уменьшить вопросы безопасности и надо надеяться обучает хорошим практикам программирования по пути. Если мы сравниваем инструменты RAD, которые начинают распространяться с инструментами, доступными для написания программного обеспечения, установленного на компьютере, я не думаю, что это плохой путь. Создавая программное обеспечение, установленное на компьютере, есть инструменты RAD, которые держат большую часть сложности решения на заднем плане, позволяя вам сосредоточиться на том, что уникально в этом проекте. То же самое относится к пакетам Composer. Мы не должны все знать, как ядру чего-то нравится, пожирать работу, чтобы быть в состоянии использовать его.

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

— Те или иные инструменты чаще всего выбирают из за моды. Все подвержены моде. Что ты думаешь об этом?

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

— Расскажи немного о твоем текущем проекте. Что ты делаешь сейчас?

— Я просто подвигаю вверх сайт, который позволяет людям искать музыкальную аппаратуру, настроение, скорость, и многое другое, и затем лицензировать ту музыку для использования в онлайн-видео, фильмах, рекламе, и т.д.

— Давай отвлечемся от работы и поговорим о твоих увлечениях. Есть ли у тебя хобби? Как ты проводишь свое свободное время?

— В настоящее время, кажется, что все мое свободное время тратится на CodeIgniter! За пределами этого, я люблю играть музыку, или, по крайней мере, пытаюсь. Я нахожусь в Группе Пиратов, где традиционные морские лачуги и более современный мореходный тип музыки, который называется Capt'n. Черные морские псы, что это очень весело. Я играю на гитаре и флейте Вистл в этой группе.

— Насколько я знаю, ты написал несколько книг. Расскажи, что это за книги?

— Я написал две книги до сих пор, одну фантастический вымысел и другая нехудожественная.

Мой роман под названием «Дочь Солнца» (от англ. «Daughter of the Sun») был написан около 5 лет назад и издан независимо. Это роман-фэнтези о женщине, которая вынуждена видеть, как далеко она пойдет, чтобы спасти жизнь ее дочери из лап правителя, который хочет убить ее за волшебство, которым она владеет, взять власть и жить дольше.

Вторая книга, которую я в настоящее время заканчиваю, называется «Приктический CodeIgniter 3» (от англ. «Practical CodeIgniter 3» ) и доступен в leanpub.com/practicalcodeigniter3. Эта книга не претендует на руководство для начинающих по CodeIgniter, или для замены руководства пользователя. Вместо этого он предназначен, чтобы представить примеры и советы о том, как действительно заставить работать фреймворк на вас и вашу команду. Она включает в себя множество идей для настройки рабочего процесса, чтобы лучше подойти вам и описывает не столь распространенные для применения особенности CodeIgniter, с которым вы не можете быть знакомы, или, возможно, не обнаружили. Я решил написать это, когда я осмотрелся и понял, что никто не собирался писать книгу CodeIgniter из установленной прессы.

— Я очень рад, что ты дал интервью и потратил свое драгоценное время. Что бы ты хотел сказать читателям напоследок?

— Есть много хороших фреймворков, которые вы можете использовать. Есть действительно нет «одиного прекрасного» фреймворка среди связки, так попробуйте столько из них, сколько вы можете, даже если это всего лишь просто часть личного проекта. Каждый из них научит вас новым способам работы, и думать о своем приложении, которое вы можете взять с собой. Таким образом, вы не попадете на конкурс популярности, который происходит вокруг фреймворков, но вы можете начинать понимать, какие фреймворки лучше всего работают для Вас и текущего проекта.

И всегда продолжайте учиться и расти.

Спасибо за интервью!

---

Ссылки по теме

Blog Lonnie Ezell: CodeIgniter 4 — Interview with Lonnie Ezell
Практический CodeIgniter 3 (Practical CodeIgniter 3) https://leanpub.com/practicalcodeigniter3
My Blog Interview with Lonnie Ezell
CodeIgniter Wikipedia: ru.wikipedia.org/wiki/CodeIgniter
Официальный сайт CodeIgniter: www.codeigniter.com
Официальный форум CodeIgniter: forum.codeigniter.com
CodeIgniter 4: https://habrahabr.ru/post/275657/
CI Community Apps: https://habrahabr.ru/post/276375/
Requests и Responses в CodeIgniter 4: https://habrahabr.ru/post/278489/
Внедрение зависимостей в CodeIgniter 4: https://habrahabr.ru/post/278641/
Маршрутизация в CodeIgniter 4: https://habrahabr.ru/post/278873/
Модули/HMVC в CodeIgniter 4: https://habrahabr.ru/post/279415/
Слой базы данных CodeIgniter 4: https://habrahabr.ru/post/280850/