Согласшусь. К сожалению, ассинхронность в php ещё сырая, могу судить по опыту использования amphp в продакшене, и будет требовать неоправданно больших усилий в поддержке, так как текущие библиотеки страдают нестабильностью (amphp/mysql, amphp/artax) и постоянно находятся какие-то ошибки, которых в нативных решениях будет сильно меньше.
Не то чтобы что-то реализовать нельзя на php, вопрос, что ряд задач сильно дешевле сделать другим способом.
1. К сожалению, не всё так просто и этого будет недостаточно, результат функции мы хотим использовать как на веб-странице с использованием html, так и в приложении где нет никакого html. Обе функции содержат работы с html.
2. Чем верстальщику это поможет, он хочет span заменить на div, например? Зачем фронтенд-разработчику писать код, который преобразовывает текущий если можно решить вопрос на этапе формирования этого кода?
3. Благо логика простая и здесь действительно сложно допустить ошибку, но если будете писать более сложную логику с такой же организацией кода, то у вас будут большие сложности с тестированием.
4. И потом не забывать везде использовать этот параметр, иначе можно получить сложно отлавливаемый баг.
5. Верно, данные принципы в первую очередь были сформированы в контексте ООП, но их идеи также могут быть применимы и к процедурному коду. Например, функция должна выполнять одну задачу.
6. Думаю, проще и лучше всё переписать.
Какую-то ценность в данной статье представляет, пожалуй, только информация про применение функции Левенштейна для решения такой задачи, но это не тянет на статью и приведенный код ещё больше портит впечатление о ней.
Ничего не буду говорить про качество кода, задам только несколько вопросов:
1. Что делать если результат функции ещё надо будет отдавать в api, например, для приложения?
2. Что делать верстальщику/фронтенд разработчику если надо будет внести какие-то изменения в html-верстку? Лезть в php-код?
3. У вас получится быстро написать unit-тест для вашего кода, ещё чтобы не надо было его изменять при каждом внесении изменений в функцию?
4. Что делать если надо будет использовать разные кодировки?
5. Насколько хорошо ваш код соответствует принципам SOLID?
6. И последний вопрос, как вы считаете, данная наработка нужна кому-то кроме вас, сможет ли человек легко воспользоваться ею в своём проекте?
Интересно услышать ответы на несколько вопросов по процессам:
1. Есть ли у вас правило, что тестировщик закреплен за задачей на всем жизненном цикле или после повторных переоткрытий взять в тестирование задачу может любой другой тестировщик?
2. В описанном процессе тестировщик занимается только ручным тестированием, написание, например, функциональных тестов в рамках проверки задачи не предусматривается?
3. У вас есть отдельная команда, которая занимается только написанием интеграционных тестов и другой автоматизацией?
4. Как у вас обстоят дела с нагрузочным тестированием, есть ли у вас такой тип тестирования и если да, то на каком этапе и кем оно выполняется?
5. Ресурс тестировщиков у вас общий или конкретные тестировщики закреплены за профильными командами?
Основная проблема статьи в том, что она не о том, что написано в заголовке:
почитайте разницу между REST и RPC и вы поймете, что у вас совсем не Restfull API
скорее здесь, что-то противоположное чистоте, по крайне мере я такой код чистым и хорошо организованным назвать не могу, чего только стоит конструктор класса api
код далёк от соответствия хорошим практикам разработки на php, думаю ещё во многом причина заключается в вашем стремлении игнорировать уже существующие наработки, которые развиваются большими сообществами, не стоит их бояться
лично мне, ваш код оставляет ощущение, что это больше процедурный код, спрятанный под видом ООП, что может быть не лучшим примером для изучения новичкам
Мой совет — обратите внимание на советы в комментариях выше по улучшению вашего кода и не избегайте чужой код только потому что он чужой, это сильно поможет как вам в развитии так и вашим проектам.
Про "пузырь" и php, как инструмента на все случаи жизни речи не было, посмотрите на список репозиториев badoo — https://github.com/badoo, там обилие разных языков программирования: PHP, С, Ruby, Python, Go, Lua, Java и другие, никто не ограничен, для разных задач используются более подходящие из ходя из множества требований и условий.
Эти полтора человека стоят 15 пхпыхеров, которые без устали строчат шаблонный код. Есть у меня смутное подозрение, что пресловутые 2 релиза в день — это хотфиксы на хотфиксы.
Оценивать качество и возможности разработки продукта разработчиком по тому на каком языке он пишет — совершенно неправильно, это оценивается его знаниями, опытом, а язык программирования выступает исключительно инструментом, да, язык может обладать своими недостатками, но как раз хороший разработчик часто может нивелировать это. Знания языка D ещё не делает разработчика сильным, он также может написать плохой код, которым потом будет тяжело поддерживать.
Ну а что там хитрого? Я весь во внимании.
Я уверен там очень много различной бизнес логики. Начиная от формирования контента для web/mobile версий со всей своей логикой, до поиска, рекомендаций, email-маркетинга, процессинга, сбора и обработки аналитики и много другого.
Если так рассуждать, то и facebook простой, страничка профиля и связи с другими, вот и всё…
В тему про размер кодовых баз, есть интересная статистика — http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
Согласшусь. К сожалению, ассинхронность в php ещё сырая, могу судить по опыту использования amphp в продакшене, и будет требовать неоправданно больших усилий в поддержке, так как текущие библиотеки страдают нестабильностью (amphp/mysql, amphp/artax) и постоянно находятся какие-то ошибки, которых в нативных решениях будет сильно меньше.
Не то чтобы что-то реализовать нельзя на php, вопрос, что ряд задач сильно дешевле сделать другим способом.
2. Чем верстальщику это поможет, он хочет span заменить на div, например? Зачем фронтенд-разработчику писать код, который преобразовывает текущий если можно решить вопрос на этапе формирования этого кода?
3. Благо логика простая и здесь действительно сложно допустить ошибку, но если будете писать более сложную логику с такой же организацией кода, то у вас будут большие сложности с тестированием.
4. И потом не забывать везде использовать этот параметр, иначе можно получить сложно отлавливаемый баг.
5. Верно, данные принципы в первую очередь были сформированы в контексте ООП, но их идеи также могут быть применимы и к процедурному коду. Например, функция должна выполнять одну задачу.
6. Думаю, проще и лучше всё переписать.
Какую-то ценность в данной статье представляет, пожалуй, только информация про применение функции Левенштейна для решения такой задачи, но это не тянет на статью и приведенный код ещё больше портит впечатление о ней.
1. Что делать если результат функции ещё надо будет отдавать в api, например, для приложения?
2. Что делать верстальщику/фронтенд разработчику если надо будет внести какие-то изменения в html-верстку? Лезть в php-код?
3. У вас получится быстро написать unit-тест для вашего кода, ещё чтобы не надо было его изменять при каждом внесении изменений в функцию?
4. Что делать если надо будет использовать разные кодировки?
5. Насколько хорошо ваш код соответствует принципам SOLID?
6. И последний вопрос, как вы считаете, данная наработка нужна кому-то кроме вас, сможет ли человек легко воспользоваться ею в своём проекте?
Интересно услышать ответы на несколько вопросов по процессам:
1. Есть ли у вас правило, что тестировщик закреплен за задачей на всем жизненном цикле или после повторных переоткрытий взять в тестирование задачу может любой другой тестировщик?
2. В описанном процессе тестировщик занимается только ручным тестированием, написание, например, функциональных тестов в рамках проверки задачи не предусматривается?
3. У вас есть отдельная команда, которая занимается только написанием интеграционных тестов и другой автоматизацией?
4. Как у вас обстоят дела с нагрузочным тестированием, есть ли у вас такой тип тестирования и если да, то на каком этапе и кем оно выполняется?
5. Ресурс тестировщиков у вас общий или конкретные тестировщики закреплены за профильными командами?
А чем обусловлен выбор тарантула, почему, например, не redis? Или там больше чем только хранение?
Мой совет — обратите внимание на советы в комментариях выше по улучшению вашего кода и не избегайте чужой код только потому что он чужой, это сильно поможет как вам в развитии так и вашим проектам.
Оценивать качество и возможности разработки продукта разработчиком по тому на каком языке он пишет — совершенно неправильно, это оценивается его знаниями, опытом, а язык программирования выступает исключительно инструментом, да, язык может обладать своими недостатками, но как раз хороший разработчик часто может нивелировать это. Знания языка D ещё не делает разработчика сильным, он также может написать плохой код, которым потом будет тяжело поддерживать.
Я уверен там очень много различной бизнес логики. Начиная от формирования контента для web/mobile версий со всей своей логикой, до поиска, рекомендаций, email-маркетинга, процессинга, сбора и обработки аналитики и много другого.
Если так рассуждать, то и facebook простой, страничка профиля и связи с другими, вот и всё…
В тему про размер кодовых баз, есть интересная статистика — http://www.informationisbeautiful.net/visualizations/million-lines-of-code/