в портфолио на sf2 пару проектов, ну че молодцы за полгода))
Поверьте, это далеко не все.
В любом случае, покажите свои проекты. А там — поговорим о состоятельности наших методологий, «ущербности компонентов Symfony2 для php», их медленности, а так же о «реальных задачах» и фокусе на них.
Мы программисты с годами опыта разработки высоконагруженных проектов, тренингов и консультаций. Использование любой технологии или ее создание обусловлено проектными необходимостями или существующими реальными задачами. Наша любовь к чему бы то ни было тут абсолютно не при чем.
Данные — это данные, а представление — это представление. Эти понятия надо отделять. У одних и тех же данных может быть несколько представлений (html/json/pdf) и каждое из них может иметь свои, форматно-особенные уязвимости. Экранирование конкретных данных для защиты их от уязвимостей отдельного типа представления — это логика представления. Не больше не меньше. Или вы экранируете сразу от всего? А потом разэкранируете где надо??? А что если через пол-года вам надо будет ввести новое представление для существующих данных со своими ограничениями? Будете базу мигрировать?
Несете несусветную чепуху. На крупных проектах узким местом может быть невозможность его поддерживать или развивать, потому что шаблоны испичканы инструкциями. Проблемы же производительности шаблонизатора решаются дополнительными мощностями сервера и кэшированием.
Код пишется для людей, а не для машин. Если вы пытаетесь на php написать приложение, которое будет работать реактивно быстро само по себе, то вы делаете это неверное — вам нужно писать сайты на Assembler или C. А теперь фокус: даже написав свой сайт полностью на Assembler, вы потратите в разы больше денег и ресурсов чем я, пишущий чистый код на php + twig и поставивший дополнительную коробку в серверную. И через полгода я посмотрю на скорость развития вашего проекта по сравнению с чисто написанным моим ;-) Я это к чему — хватит уже экономить на спичках.
Дело не в критичности ошибок для пользователей. Дело в самоощущении разработчиков в рамках проекта. Мне было бы крайне стремно править ошибку в проекте с полным отсутствием тестов. И даже после исправления бага я бы все-равно продолжал себя чувствовать обкакавшимся, потому что нет никаких гарантий, что моя правка ничего не поломала. Вот такие ощущения и приводят к депрессиям, постоянным стрессам и нежелению программистов развивать проект. Каждый программист на таком проекте либо находится в постоянном стрессе либо пофигистичный идиот. Просто задумайтесь!
Вы мешаете BDD, функциональные и спецификационные тесты в одну кучу.
Так же как есть юнит и функциональное тестирование, есть Specificational BDD (http://rspec.info/, www.phpspec.net/) и Scenario BDD (http://cukes.info/, behat.org/).
Спецификационное BDD пришло на замену юнит-тестов и решения проблем технического уровня (описания внутренних спецификаций), а то, о чем говорите вы — Scenario BDD — для замены функциональных тестов и решения проблем бизнесс-уровня (описания поведения приложения).
сравнения процедурного и объектно-ориентированного подхода, я задался простым вопросом — где бы я мог использовать процедурный подход, вместо объектного? Если честно, то я не знаю такие области, в которых ООП явно проигрывало функциональному подходу
Процедурный (императивный) и фнукциональный — совершенно разные подходы к программированию. Не мешайте их в одну кучу, пожалуйста.
Перестаньте смотреть на циферки и вспомните когда в последний раз разрабы фаерфокс добавляли в браузер новые фичи в 6-недельный срок. Никогда! А сейчас каждый шесть недель хоть по немногу, но браузер совершенствуется. Со старой «нумерацией» пришлось бы text-overflow: ellipsis ждать минимум год.
Да, исходные данные верные, но выводы чересчур оптимистичные. «Есть новая платформа, есть 50 старых платформ, разработчики будут выбирать новую». Разработчики де-факто будут выбирать то, с чем им удобнее работать. И если у них уже есть огромное количество наработок на Win32 API — никто их на помойку выкидывать не будет. На выходе получим зоопарк интерфейсов и платформ. Раньше были только MFC и Win32API, сейчас MFC, Win32API, .Net, Metro. Apple было тяжело вытянуть 2 платформы (Carbon, Cocoa), посмотрим как MS справится со своим зоопарком.
Microsoft ничего. Абсолютно ничего не делала с IE на протяжении 5+ лет! Очень глупо с вашей стороны делать предсказания о будущем рыночной доли Google, основываясь на потери «заброшенным» (на очень длительное время) приложением популярности.
Чего требуют? Есть класс искомый (необходимый для выполнения конкретной задачи), у него есть конструктор, в который надо передать зависимости (объекты других классов) попутно заполняя их параметрами. Это один общий подход для всех ООП языков программирования. Нужен класс — инициализируем и используем. Какие «не единые» подходы? О чем вы говорите вообще? О том что человек не знающий ООП или базовых паттернов не сможет в этом разобраться? Так это не программист тогда и никому он такой не нужен, включая нас.
А вы всегда новых сотрудников обучаете вслепую натравливая их на все *.php файлы проекта? Типа распечатываете на принтере и заставляете читать?
Разбираешься с фреймворком, понимаешь как работает фронт-контроллер и роутинг. По роутингу вытаскиваешь класс и метод контроллера, где и смотришь что и как используется. Абсолютно не вижу проблемы.
На крупных проектах тоже не важно. За свою карьеру писал более 10 крупных проектов на php. И нигде! Нигде мы не упирались в перформанс конкатенации строк!
Поверьте, это далеко не все.
В любом случае, покажите свои проекты. А там — поговорим о состоятельности наших методологий, «ущербности компонентов Symfony2 для php», их медленности, а так же о «реальных задачах» и фокусе на них.
Расскажите про «фокус на реальных задачах» нашему портфолио: knplabs.com/en/portfolio.
Код пишется для людей, а не для машин. Если вы пытаетесь на php написать приложение, которое будет работать реактивно быстро само по себе, то вы делаете это неверное — вам нужно писать сайты на Assembler или C. А теперь фокус: даже написав свой сайт полностью на Assembler, вы потратите в разы больше денег и ресурсов чем я, пишущий чистый код на php + twig и поставивший дополнительную коробку в серверную. И через полгода я посмотрю на скорость развития вашего проекта по сравнению с чисто написанным моим ;-) Я это к чему — хватит уже экономить на спичках.
А к вопросу «шаблоны на чистом php такие же читабельные» вам сюда:
habrahabr.ru/blogs/webdev/127906/#comment_4224465
habrahabr.ru/blogs/tdd/129387/#comment_4286799
Так же как есть юнит и функциональное тестирование, есть Specificational BDD (http://rspec.info/, www.phpspec.net/) и Scenario BDD (http://cukes.info/, behat.org/).
Спецификационное BDD пришло на замену юнит-тестов и решения проблем технического уровня (описания внутренних спецификаций), а то, о чем говорите вы — Scenario BDD — для замены функциональных тестов и решения проблем бизнесс-уровня (описания поведения приложения).
Процедурный (императивный) и фнукциональный — совершенно разные подходы к программированию. Не мешайте их в одну кучу, пожалуйста.
Разбираешься с фреймворком, понимаешь как работает фронт-контроллер и роутинг. По роутингу вытаскиваешь класс и метод контроллера, где и смотришь что и как используется. Абсолютно не вижу проблемы.