includezippe24 мар 2016 в 19:49

RestAPI для веб-приложения на PHP или познаем дзен в чистоте

7 мин

12K

Проектирование API * PHP *

Туториал

Recovery Mode

-23

Комментарии 94

MetaDone 24 мар 2016 в 20:03

http://www.php-fig.org/psr/psr-2/
https://getcomposer.org/ — вот это примите как стандарт, 2016 год на дворе
Ну и все это безобразие быстро и просто устанавливается из сторонних компонентов. Не любите фреймворки — библиотек для всего что в голову ударит вагон и маленькая тележка, и все протестированые и четко делают то, зачем они созданы

includezippe 24 мар 2016 в 20:13

Приму на вооружение – спасибо!

MetaDone 24 мар 2016 в 20:16

тогда еще сюда гляньте
http://symfony.com/doc/current/components/index.html
https://github.com/auraphp
каждый из компонентов по отдельности прост, простую апишку собрать будет очень просто

includezippe 25 мар 2016 в 07:33

Воспользуюсь местом повыше дабы ответить на все нижеследующие комментарии разом.

прозрачный для любого Джуниора паттерн

Скажите, сколько джуниоров способны моментально интерпретировать современные лучшие практики в рабочий не забагованный проект?
Безусловно, все в этом мире стоит улучшать. Однако, мой код позволяет любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения. Притом, он будет наглядно понимать что и как в нем работает.
Да и скажите — сколько будут стоить услуги человека, который знаком с этими лучшими практиками не по наслышке.
В итоге — очень полезный для малого бизнеса инструмент позволяющий проверить гипотезу в течении суток.
Я сам не люблю компромиссы, однако, особенно в кризис, я думаю — это уместно.

MetaDone 25 мар 2016 в 07:53

Однако мой код позволяет любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения

Хорошо, но почему не используете пространства имен, psr? Уже 2016 год. Если бы дело происходило до появления всего этого — то да, было бы познавательно. А psr приучит писать новичков понятный для остальных код. Ладно, пусть он один работает, даже так — через полгода глянет и ужаснется всему этому.

Скажите, сколько джуниоров способны моментально интерпретировать современные лучшие практики в рабочий не забагованный проект?

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

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

Дешевле, чем выйдет исправлять баги после проекта, реализованного новичком. Да, обучаться нужно, но чтоб подобное не попадало в боевой проект нужен code review.

Я сам не люблю компромиссы, однако, особенно в кризис, я думаю — это уместно.

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

includezippe 25 мар 2016 в 08:03

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

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

По поводу psr — согласен. Когда писал это в далеком бородатом году знал лишь о camelCase мой косяк.

zelenin 25 мар 2016 в 09:34

в течении пары часов можно прочитать статью "Пишем RestAPI на Slim/Silex/Yii2/Phalcon" итд, в которой вам покажут, что апи поднять можно в течении получаса, предложат хорошое структурирование кода и кодстайл по ПСР, а в конце дадут ссылочку на репозиторий на гитхабе с готовым кодом, чтобы вы тут же развернулись локально.

includezippe 25 мар 2016 в 11:53

В каждом фреймворке есть свои подводные камни. Сильные и слабые стороны. Мы говорим о джуниорах которые не смогут сходу этого понять и в дальнейшем вероятность ошибки будет просто огромна. И в итоге – как показывает опыт. Если в управлении находится джуниор то через како то время он начинает просто путаться в своем же Yii коде и поверьте – после этого в нем не разберется ни один программист. Проще будет переписать с 0. Статья не о том как сделать самое крутое современное приложение на метеоре. Статья о том какой подход для бизнеса будет лучшим по соотношению цена/качество. Подход на простом чистом PHP оправдан так как вы за пару часов найдете PHP программиста который допишет все необходимое за пару тысяч рублей. Если речь идет о приложении на метеоре или подобных разумного уровня разработчиков – я думаю сумма будет начинаться с 200. Если у вас стартап, нет денег а нужно срочно поменять концепцию это будет смерть для проекта. А мой подход даст даже новичку шанс все сделать более менее просто быстро и чисто. И в дальнейшем код будет как минимум логичен.

MetaDone 25 мар 2016 в 12:13

Статья о том какой подход для бизнеса будет лучшим по соотношению цена/качество

} else
                                view::error("Incorrect data type for: " . implode(', ', $wrong_types), 204);
                        } else
                            view::error("Missing parameters: " . implode(', ', $missing_parameters), 204);
                    } else
                        view::error("Method in developing.", 503);
                } else
                    view::error("The method '" . $action . "' does not exist.", 204);
            } else
                view::error("No params received.", 204);
        } else
            view::error("Method was not received.", 204);
    }

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

Если в управлении находится джуниор то через како то время он начинает просто путаться в своем же Yii коде

А кто рулит по этой части в проекте и строит архитектуру ~~или хотя бы на салфетке в баре рисует что и как будет~~? Дайте ему маленький простой кусок, чтоб не путался. Справится — расширяйте круг его деятельности. А в таком коде после пары месяцев добавления функционала будут путаться все.

В каждом фреймворке есть свои подводные камни

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

zelenin 25 мар 2016 в 13:54

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

Fesor 26 мар 2016 в 10:01

Скажите, сколько джуниоров способны моментально интерпретировать современные лучшие практики в рабочий не забагованный проект?

Смотря кого мы называем джуниором. По хорошему это должен быть чувак, который уже знает основы CS и может спокойно без какой либо помощи на каком-либо фреймворке решать типовые задачи.
Тут еще момент… большинство разработчиков-самоучек как-то не сильно пытаются понимать зачем придумали ту или иную штуку. Взять тот же ваш метод orm — вы ясно просто где-то слышали что ORM это для работы с базой данных но понятия не имеете что это такое. Другие же люди путают active record и orm, третьи считают что doctrine это data mapper и не замечают что там помимо этого еще куча всего (orm + unit-of-work + repository + entity manager).

любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения.

Нечего "начинающим программистам" делать в коммерческой разработке. Пусть для начала поучатся.

Притом, он будет наглядно понимать что и как в нем работает.

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

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

Если мы про рейт — то дорого конечно. А если мы про сроки разработки и риски — то дешевле чем джуниор. Намного практичнее взять одного-двух синьеров которые запилят MVP за пару месяцев и потом уже расширять команду джунами/мидлами, чем брать джуниоров, которые за те же пару месяцев напишут MVP, которое потом проще переписать чем расширять новым функционалом.

В итоге — очень полезный для малого бизнеса инструмент позволяющий проверить гипотезу в течении суток.

Silex, Lumen, Slim… Для этого всего есть микрофреймворки. Для чуть более зрелого прототипирования — Symfony 2.8 имеет возможность использовать фичу под названием micro-kernel, где отключено все лишнее. Да и инструменты типа Doctrine хоть и обладают неимоверно высоким уровнем сложности (я реально мало проектов знаю на PHP которые могут сравниться по сложности с доктриной) — но об этой сложности знать не нужно разработчику, он просто накидывает бизнес объекты, логику взаимодействия, а база данных появляется сама по себе. Самое то для MVP. А уже потом можно заниматься оптимизациями и т.д.

Я сам не люблю компромиссы, однако, особенно в кризис, я думаю — это уместно.

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

Fesor 26 мар 2016 в 10:12

Однако, мой код позволяет любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения.

Еще по поводу этого пункта… Как думаете, почему "начинающих врачей" до интернатуры к пациентам не разрешают прикасаться? Или почему надо хотя бы ПТУ окончить для многих других специальностей?
И почему-то именно в программировании, которое обычно связывают именно с интеллектом, люди почему-то думаю что можно прочитать статейку и методом тыка начать делать проекты за деньги. При этом… хоть мы жизнью и не рискуем (хотя отдельные люди, которые работают с микроконтроллерами и пишут софт для автомобилей например и жизнью других людей рискуют), мы обычно рискуем чужими деньгами.
На моей памяти много прикольных стартапов умерло именно потому, что разработчики накосячили и в итоге товый функционал добавлялся ужасно долго. Типа писать чатик на PHP 2-3 месяца (вместо пары недель на ноде) и из-за факапа в архитектуре держать его на серваке который бернит $2К в месяц. А деньги то вложены и их уже не вернуть. Я знаю людей которые настолько верили в свои проекты, что закладывали дома (не в СНГ разумеется) что бы оплатить разработку и маркетинг своего проекта.
А теперь задумайтесь. Вот пишите вы свои фреймворки и т.д. Вопервых ввести нового человека в команду будет теперь дорого. Во вторых уровень технического долга заоблачный. В третьих вместо того что бы фичи реализовывать вы пишите новый роутер, который завтра может уже не соответствовать требованиям бизнеса.

includezippe 26 мар 2016 в 10:42

У меня успешно запущено более 4 проектов по такой схеме и поверьте ни для одного еще не пришлось дописывать новые роутеры :) Нагрузки распределяются веб-сокеты подключаются. Напротив, у меня есть знакомый сделавший без какого либо опыта чат на ноде и теперь его «счастливые» обладатели отдают за хостинг от 50 тыс рублей в месяц вместо того что бы 1 раз заплатить за разумный код. Поверьте, то, что творится в проектах, бюджет которых не превышает миллиона рублей, очень и очень далеко от идеалов. Счастлив уже тот кто умудрился найти честного разработчика который не кинет и не провернет аферы с договором (и такое было.) А дальше – у всех свои монстры в голове. И поверьте, с моим фреймворков разбирается школьник за пару дней и умудряется до самого продакшена не косячить. А вот те школьники что пишут на популярных фреймворках – не понимают что они вообще делают. Думаете такие люди станут вчитываться в документацию? В лучшем случае возьмут основы а дальше пойдут своей мыслью. Попробуйте в россии найти добросовестного разработчика за 50-100 тыс рублей в месяц который будет владеть всем необходимым инструментарием. Адекватные ребята давно сидят на аутсорсе за 5000$ а вот в российских реалиях творится АД. :) Вы тут пафосно рассуждаете о идеальном коде, а сами наверное и не в курсе что творится на биржах разработчиков и что речи не идет о топах. Возможно, в статье стоило более точнее описать в каких именно случаях такой подход будет наиболее выгодным. Но извините, очень мало времени на бездумную полемику которая ни к чему не приведет. Удачи Вам, спасибо за внимание!

lnroma 26 мар 2016 в 21:32

Вы комерсант а не программист, да и Москва не вся Россия.

includezippe 26 мар 2016 в 10:50

Ах да! Спасибо Вам за Ваш безумно ценный вклад в сообщество!
Ваши переводы так безумно полезны и интересны! Что может быть лучше – беспроигрышный вариант перевести статью опытного разработчика и собрать плюсы не понимая даже основы концептов из статьи.
А разбор html шаблонов под ангуляр – Вы явно делитесь с миром чем-то гениальным. Обязательно подписался на Ваш блог, буду держать руку на пульсе. Жду новых статей! Еще раз спасибо, всего Вам доброго.

zelenin 26 мар 2016 в 13:23

какой красивый способ ведения дискуссии.

nowm 26 мар 2016 в 15:02

Это называется: «когда кончаются аргументы, нужно использовать argumentum ad hominem». Если вы решили оценить человека, опираясь на текст, который он публиковал, пожалуйста, прибавьте к статьям на Хабре его аккаунт на Тостере. Он, в общем-то, довольно-таки солидный вклад сделал в сообщество. Вы зря его пытаетесь дискредитировать.

Fesor 24 мар 2016 в 20:04

познаем дзен в чистоте

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

md5(crypt($this->args['password'],SALT)))) {

Ради бога, есть же Password Hashing API. Вопервых и соль для каждого пользователя должна быть своя, во вторых, если не знаете как ее нормально сгенерировать, доверьтесь реализации password_hash. То что у вас — это одна сплошная бесполезная хрень, с таким подходом можно просто plain password хранить.

@session_start();

здорово… что сказать...

elseif (($value === '0') or ($value === 0))
                    $value = 0;

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

public function orm($sql, $array, $type){

Доставило. Почитайте что такое ORM. У вас же просто обертка для работы с SQL. Причем вы даже до Table Data Gateway не доросли судя по всему.
Словом… грусть тоска. Если хотите — могу продолжить.

includezippe 24 мар 2016 в 20:10

Полностью согласен – содержание классов ни в коем случае не пример к использованию в своем проекте. Максимум из того, что может быть интересно: подход к организации рабочих файлов в приложении и распределение задач между ними.

lnroma 24 мар 2016 в 22:38

да половина кода http://php.net/manual/ru/function.spl-autoload-register.php велосипед автолодера. И у вас ошибка в приложение:

    function __construct() {
        try {
            include 'db.config.php';
            $this->_db->exec('SET NAMES utf8mb4');
        } catch (PDOException $e) {

        }
    }

вызов класса два раза

$db = new db();
// some code
$dbTest = new db();

Вызовит fatal error. И экскепшины плохо не обрабатывать. Ибо при возникновение ошибки вы даже не поймете где искать. Ну и @.

includezippe 25 мар 2016 в 07:08

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

Drag0n 24 мар 2016 в 20:15

Мне вырвало глаз эти строки,

$this->db = new db();$this->view = new view();$this->factory = new factory();

Статья потребовало времени, а результат срезан неаккуратным кодом, вам же обидно!

Уважайте разработчиков, пожалуйста, PSR появился затем, чтобы нам было комфортно друг с другом общаться,

includezippe 24 мар 2016 в 20:22

Спасибо за комментарий – строчку подправил :)

kafeman 24 мар 2016 в 20:48

Нет ли тут PHP-inj?

include_once('api/methods/' . $action . '/parameters.inc.php');

includezippe 24 мар 2016 в 21:03

После проверки

if (file_exists('api/methods/'. $action. '/parameters.inc.php')) {

маловероятно наличие посторонних ссылок в переменной.

kafeman 24 мар 2016 в 21:10

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

$action = "../../etc/passwd\0";

includezippe 24 мар 2016 в 21:13

$action = explode('/', $url['path']);

$action не может содержать слэши

torf 24 мар 2016 в 21:50

а кто мешает использовать обратные?)

includezippe 24 мар 2016 в 21:57

А зачем в URL обратные слэши?

torf 24 мар 2016 в 22:28

А зачем вообще программирование… ООП, фабрики всякие. Зачем динамические скрипты для общения с БД? Есть же статика)
P.S. Ну, естественно, это ирония...

kafeman 24 мар 2016 в 22:22

Оказалось, что начиная с 5.3 нулевой символ зачем-то вырезается (на сервере стоит 5.6 — автор отправил мне ссылку). Обратные слэши действительно воспринимаются PHP как разделитель пути, но все портит parameters.inc.php в конце.

В любом случае, через 8 сек. была найдена XSS. Поэтому я так «люблю» самописные движки.

includezippe 25 мар 2016 в 06:56

Подклитесь информацией о уязвимости, пожалуйста.

kafeman 25 мар 2016 в 09:26

Я же еще вчера написал вам в личку. Сейчас уточню еще раз.

torf 24 мар 2016 в 22:24

Предвосхищая минусы. Мой предыдущий коммент рассматривать дословно — как вопрос)

lnroma 24 мар 2016 в 22:41

<?php die('konec') ?>

такое же может содержать.

includezippe 25 мар 2016 в 06:57

Любой текст может такое содержать :)

lnroma 25 мар 2016 в 07:02

так вы инклуд делаете. А это значит что у вас интерпритатор выполнит '<?php die('123') ?>' т.к. вместо
include('/controller/action/params') где action параметер будет что то вроде include('controller/<?php die('123') ?>/params') собственно die('123') должен выполниться.

includezippe 25 мар 2016 в 07:12

Перед инклюдом проверка на существование дирректории с методом

malaf 24 мар 2016 в 21:06

Основная проблема статьи в том, что она не о том, что написано в заголовке:

почитайте разницу между REST и RPC и вы поймете, что у вас совсем не Restfull API
скорее здесь, что-то противоположное чистоте, по крайне мере я такой код чистым и хорошо организованным назвать не могу, чего только стоит конструктор класса api
код далёк от соответствия хорошим практикам разработки на php, думаю ещё во многом причина заключается в вашем стремлении игнорировать уже существующие наработки, которые развиваются большими сообществами, не стоит их бояться
лично мне, ваш код оставляет ощущение, что это больше процедурный код, спрятанный под видом ООП, что может быть не лучшим примером для изучения новичкам

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

includezippe 24 мар 2016 в 21:11

Спасибо, буду знать!

torf 24 мар 2016 в 22:18

Кстати, никогда не понимал, зачем вот после return делают elseif / else. Это для надёжности? sarcasm

if(($var === 'true') || ($var === true))
  return true;
elseif(($var === 'false') || ($var === false))
  return true;
else
  return false;

Fesor 24 мар 2016 в 22:32

Меня в принципе этот кусочек кода смущает.

torf 24 мар 2016 в 22:35

Ну про чудеса вроде… === 'false' Вы уже выше упомянули, поэтому я решил не дублировать)

torf 24 мар 2016 в 22:41

Аналогичная ситуация. Вдруг return не сработает?

case 'smallint':
    return (is_numeric($var) && (strlen($var) == 1)) ? true : false;
    break;

kafeman 24 мар 2016 в 22:43

Настоящая жесть тут — это:

return expression ? true : false;

torf 24 мар 2016 в 22:47

Да, это тоже можно отнести к загадкам мироздания...

includezippe 25 мар 2016 в 07:05

Очевидно, до упразднеия кода там что-то было.

alekciy 25 мар 2016 в 07:38

Не уловил, в чем ошибка в данном куске.

torf 25 мар 2016 в 07:49

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

kafeman 25 мар 2016 в 09:30

В данном случае, получается что-то вроде:

если блаблабла истина то вернуть истина
иначе вернуть ложь

Очевидно, что вместо:

return condition ? true : false;

Любой нормальный человек напишет:

return condition;

VolCh 25 мар 2016 в 11:58

Максимум return (bool)condition, если condition произвольного типа

kafeman 25 мар 2016 в 12:01

В данном случае было достаточно:

return is_numeric($var) && strlen($var) == 1;

alek0585 26 мар 2016 в 09:42

Я джуниором тоже так писал, пока мне не указали я и не заметил. Кстати, одного раза вполне достаточно, чтобы понять идею return

torf 24 мар 2016 в 22:45

Ещё мне не очень понятно как планируется использовать вот эту штуку.

print $query;
die(json_encode(array("Error" => "Syntax error.")));

includezippe 25 мар 2016 в 08:43

Вывод SQL запроса с ошибкой. А далее: очередная защита от дурака. Что бы он не дописал дальше – это не выполнится. В продакшене, конечно, все голые принты должны быть убраны.

НЛО прилетело и опубликовало эту надпись здесь

torf 24 мар 2016 в 23:00

Вы сначала погуглите о компании =). Не стоит сразу хвататься за сердце.

medved6216 25 мар 2016 в 04:41

Если это вот эта "Студия". Мне страшно :( Правда у них в портфолио всего 4 проекта, но учитывая с кем они сотрудничают, мне страшно не за студию, а за эти компании. Надеюсь, что такое качество кода только у их директора и он не участвует в разработке. Пусть это будет так… Пожалуйста :)

BupycNet 25 мар 2016 в 06:40

Кто то уже проверил на них XSS из статьи?

includezippe 25 мар 2016 в 07:02

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

andrewnester 25 мар 2016 в 08:08

Далее, для понимания всей картины, давайте окинем взглядом архитектуру будущего приложения:

и далее вы приводите картинку со структурой папок проекта.
структура директорий не равно архитектура приложения.

Disparity 28 мар 2016 в 15:28

Я бы сказал что этот подход устарел лет на ~10.

Fesor 28 мар 2016 в 15:52

лет на 30. MVC придумали 40 лет назад а тут даже разделения явного нет.

includezippe 25 мар 2016 в 07:03

На сайте под большинством проектов явно обозначена моя роль в разработке :)

zelenin 25 мар 2016 в 06:01

очевидно, что гендиректор когда-то был программистом. А программистом он был, судя по коду, около 10 лет назад.

includezippe 25 мар 2016 в 07:00

Вы не долеки от истины)

zelenin 25 мар 2016 в 09:29

хотя если вам 21, то мое предположение скорее неверно. Просто вы изначально неверно стартовали в профессии, а сейчас уже видимо не хотите переучиваться.

includezippe 25 мар 2016 в 16:50

Не знаю о чем речь, но активно программированием я занимался как раз около 6 лет назад

SiDz 25 мар 2016 в 06:59

Ген. Директор в 22 года?

includezippe 25 мар 2016 в 06:59

В 21 :)

НЛО прилетело и опубликовало эту надпись здесь

dbelka 25 мар 2016 в 07:09

Как теперь это развидеть? Простите.

porozhnyy 25 мар 2016 в 07:44

Отвлекусь от статьи, выше все разложили. Другой вопрос: http://mettle.media/1 в портфолио… Таки правда?

includezippe 25 мар 2016 в 07:56

Признаюсь, клиент был наш через третьих лиц, но. Таки да. Больше горжусь dhl и Axis bank.

alekciy 25 мар 2016 в 08:14

Т.е. если что Avito не признает в вас своего подрядчика? Уверены, что в условиях сотрудничества нет пункта, согласно которому нельзя публично светить себя как субподрядчика? Ситуация вполне может быть серьезной. У коллег была ситуация, когда конечный заказчик (Москва) случайно узнал, что субподрядчик из региона. Несмотря на то, что проект был практически завершен и заказчика устраивал контракт был сразу разорван.

includezippe 25 мар 2016 в 08:19

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

alekciy 25 мар 2016 в 08:06

Куча вложенных условий плохая практика (низкая читабельность — больше вероятность ошибки). Оставляя за рамками вопрос адекватности кода привожу как можно такие конструкции писать "вертикально". Вот эта дикая N вложенность:

if (!empty($action)) {

    if (!empty($_POST) || (substr($action, 0, 4) == 'get_')) {

        ...
    } else
        view::error("No params received.", 204);
} else
    view::error("Method was not received.", 204);

легко сводиться к нулевой сложенности:

// [1- Проверка данных
if ( empty($action) ) {
    view::error('Method was not received.', 204);

    return;
}
if (empty($_POST)
    || (substr($action, 0, 4) != 'get_')
) {
    view::error('No params received.', 204);

    return;
}
// ...и другие if-ы
// -1]

// Отрабатываем логику
$parameters = array();
$missing_parameters = array();
$wrong_types = array();
// ...остальной код бизнес логики

includezippe 25 мар 2016 в 08:08

Полезный комментарий, спасибо! Постараюсь добавить в статью

taliban 25 мар 2016 в 09:17

Вы в курсе что делит и апдейт в sql возвращают довольно таки нужные значения? А вы их игнорируете :) Не надо так.

includezippe 25 мар 2016 в 10:40

Конечно! Там именно для этого выделены кейсы – крайне рекомендую всем заинтересовавшимся дописать все необходимое для проекта.

QuickStudio 25 мар 2016 в 09:51

Вернули мне 2006

НЛО прилетело и опубликовало эту надпись здесь

maghamed 25 мар 2016 в 12:37

Я посмотрел ваш код и у меня с рота сигарета выпала.
Ваш код олицетворение шутки: "A piece of PHP code walks into a bar. The bartender informs it that they don't serve spaghetti there, so it turns around and leaves."
Просто для развлечения рекомендую вам посчитать цикломатическую сложность методов вашего года.
Ну и в целом это набор антипатерном и спагетти-кода, которое вы пафосно называете "идеальным решением". Мне кажется я вернулся в начало нулевых и посмотрел примеры кода на PHP 4.3

robert_ayrapetyan 25 мар 2016 в 15:34

Беги, дядь Мить...

nowm 25 мар 2016 в 16:27

Теперь понятно, почему в некоторых системах возникают проблемы: вроде той, что у Дженифер Нуль (Jennifer Null). Цитирую код из этой статьи:

            case 'boolean':
                if(($var === 'true') || ($var === true))
                    return true;
                elseif(($var === 'false') || ($var === false))
                    return true;
                else
                    return false;
                break;

Кто-нибудь наверное тоже там проверял: if ($var === Null || $var === 'Null').

includezippe 25 мар 2016 в 16:52

Какая разница если они влзвращают в итоге только true. :)

nowm 25 мар 2016 в 16:56

А, ладно, я дополню код, чтобы было понятно, что я имел ввиду:

if ($var === Null || $var === 'Null') {
    return Null;
}

Хотя, я считаю, что и без этого понятно было, о чём речь.

nowm 25 мар 2016 в 17:12

Речь была про отношение к строкам, визуально похожим на данные другого типа, как к значениям этих типов данных. Строку «true» не нужно считать boolean-значением «true». Пользы особенно много такой подход не прибавляет, зато появляется точка непредсказуемости в коде.

kafeman 25 мар 2016 в 17:21

Код, конечно, противно воняет, но не из-за этой проблемы, а из-за другой. Во-первых, бессмысленный if / elseif (если по обоим условиям возвращается один результат, зачем их было разделять?). Во-вторых, совершенно глупый и бессмысленный else return false (else не нужен). В-третьих, break, который никогда не будет выполнен. В-четвертых, автор реализовал функцию из стандартной библиотеки — is_bool.

Andrey2008, посмотрите, сколько потенциальных клиентов у вас среди PHP-шников...

nowm 25 мар 2016 в 17:57

Я сразу после публикации этой статьи хотел своё мнение написать по коду. После того, как у меня комментарий по объёму добрался до объёма статьи, я его просто не стал публиковать. :)

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

А сам код из статьи в целом я не очень хочу обсуждать, потому что у меня есть более продуктивные занятия. С людьми, которых я могу контролировать, я работаю и объясняю, почему в коде лучше делать так или иначе. С писателями статей я не работаю и не критикую их код, потому что по большей части это будет как об стенку горох. В данном конкретном случае я вижу, что автор вообще не нацелен на то, чтобы из критики делать выводы. Так что, я считаю, что все, кто критикует код в данной статье, делают это лично для себя. :)

Опять же, я не совсем понимаю, для чего вы мне объясняете, что «break» никогда не выполнится? Вы по какой-то причине думаете, что я этого не заметил самостоятельно, так? (Если чем-то эти вопросы обидно прозвучали, я искренне извиняюсь — у меня не было мыслей обидеть.)

kafeman 25 мар 2016 в 18:06

Так что, я считаю, что все, кто критикует код в данной статье, делают это лично для себя.

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

Опять же, я не совсем понимаю, для чего вы мне объясняете, что «break» никогда не выполнится?

Простите, что?! :-) Я пишу не вам в личку, а публичный комментарий, который логичнее всего смотрится именно в этом месте.

nowm 25 мар 2016 в 18:15

Я пишу не вам в личку, а публичный комментарий, который логичнее всего смотрится именно в этом месте.

Ну тогда относитесь к моим словам так же, как и к своим. Фраза «я не совсем понимаю, для чего вы мне объясняете, что «break» никогда не выполнится» — это просто публичный комментарий, который логично смотрится в том месте, где он был. Не знаю, с чего вы взяли, что он к вам был обращён. :)

nowm 25 мар 2016 в 18:20

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

nowm 25 мар 2016 в 18:14

del

Зарегистрируйтесь на Хабре, чтобы оставить комментарий