Не мамонт ли Вы? (пятничный тест; который ложь, да в ней намек)

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

    Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

    И это здорово!

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

    image

    Попробуйте пройти несложный тест и определить — не мамонт ли Вы в мире PHP? Не грозит ли Вам, как специалисту, вымирание в ближайшее время?

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

    Вы пишете на современных версиях языка


    Основная версия 5.6? Отлично, начислите себе 10 баллов. Уже собирали PHP 7 и тестировали свой код под ним? Прекрасно, добавьте еще 5 баллов.

    До сих пор пишете «array()»? Пугаетесь слова «трейт»? Ничего не знаете о генераторах? Используете md5 для хэширования паролей? Пора просыпаться, версия 5.4 вышла три года назад! Где вы были эти три года? Спали в хрустальном гробу? Вот только не нужно ничего говорить про тонны legacy-кода и про хостинги. Первая проблема это не проблема кода, а проблема вашей лени, а вторая вообще не существует в условиях, когда можно взять свой сервер всего за 250 рублей в месяц и организовать свой собственный хостинг.

    Вы используете современные системы контроля версий


    Что, вы не используете VCS в повседневной работе? Закройте эту страницу. Я серьёзно — вам не нужно дальше проходить тест, вам нужно немедленно позвонить ближайшему франчайзи «1С» и устроиться к нему внештатным разработчиком на побегушках.

    Если же вы не мыслите своей работы без Git (или Hg, например) — начисляйте себе 20 баллов

    Вы правильно используете современные системы контроля версий


    Начислите себе по 5 баллов за каждое утверждение, которое соответствует вам и вашему стилю работы:
    (слово «git» можно заменять на другую VCS)
    • Всё должно быть в git-е
    • Всё — это значит всё! И даже конфиги приложения
    • Crontab должен быть в git-e
    • Инъекции в конфиги php или веб-сервера берутся откуда? Правильно, из вашего репозитория!
    • Все изменения в структуре и системных данных в БД — только через Git, используем миграции или иной механизм
    • Ну сколько раз повторять — ВСЁ ДОЛЖНО БЫТЬ В GIT-Е!


    Вы используете современные системы контроля версий в соответствии с чётким workflow


    Если вы работаете по git flow — сразу добавьте себе 25 баллов, пожалуйста. В противном случае добавляйте по 5 баллов за каждое утверждение, которое относится к вам:
    • Всегда есть стабильная ветка, чьё состояние точно соответствует состоянию продакшна
    • Каждой задаче — своя ветка
    • Исключений из этого правила не бывает
    • Ветки могут быть разных типов, в зависимости от типа задачи
    • Любая ветка рано или поздно будет влита в стабильную (тем или иным путём) и/или удалена


    Вы не вносите изменения в БД руками, для этого есть миграции, которые можно накатывать и откатывать


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

    Хотите поспорить? Знаете, что такое ловчая яма? Вы — мамонт, вы сидите в этой яме и пытаетесь спорить с охотниками, раздумывающими, как вас оттуда вытащить — целиком или всё-таки предварительно порубив на куски. Удачи!

    Вы используете сценарии сборки


    Дружите с phing? Или знакомы с Capistrano? А может быть используете Ant? 15 баллов в студию!
    И да, вы же помните — сценарии сборки у вас лежат где, где? Правильно, в доме, где резной палисад в git-е!

    Не знаете, что такое сценарии сборки? Не понимаете, зачем они нужны? Ааа, мамонт, еда для всего племени!!! Слышите, как уже бежит толпа охотников выбросить вас за борт?

    Автоматический деплой


    Teamcity? Или Jenkins? Или, может быть, Bamboo? Поздравляю, вы на шаг ближе к билету на Ноев ковчег и заодно получаете бонус — 10 баллов. Первый раз слышите эти слова? Или считаете себя умнее всех и написали свой велосипед для выкладки релизов? У меня для вас плохие новости. Тут одно из двух — или вымирать, или эволюционировать, — выбирайте!

    PHPStorm?


    • Да? 10 баллов
    • Vi(m)? 5 баллов. Просто из уважения к динозаврам. Они переживут всех мамонтов, поверьте.
    • Что-то другое? 0 баллов


    Фреймворки


    Zend? Symfony? Laravel? Yii, прости господи? Прекрасно. Добавьте себе 20 баллов, если для вас это не пустые слова, а каждодневная работа.

    Приплюсуйте еще 10, если вы постоянно работаете более, чем с одним современным фреймворком. Впрочем, ровно столько же можете себе добавить, если для конкретного проекта вы собираете набор нужных вам пакетов с помощью composer.

    Плюс еще 5, если вас хотя бы однажды посещала мысль «До чего же криво в этом фреймворке реализовано X, я бы переделал» или плюс 15 баллов, если вы взяли и переделали.

    Спрашиваете, зачем нужны PHP-фреймворки? Хотите узнать, не стоит ли изучить CodeIgniter? Не понимаете, зачем управлять зависимостями в коде, ведь можно просто скачать к себе в проект нужную библиотеку? ОК, как только построят машину времени, я отправлю вас на 15 лет назад, где вы сможете в полной мере блеснуть своими талантами, а пока можете прибегнуть к криоконсервации, ведь вам всё равно будет нечем заняться в ближайшие годы.

    Вы — немного DBA


    Вы знаете, что на MySQL мир реляционных баз данных не заканчивается. Вы хотя бы раз в жизни выбирали сервер БД исходя из бизнес-требований к будущему приложению (и остановились на Postgres, не так ли?). Вы отчетливо понимаете, что в общем случае каждый JOIN — это вложенный цикл, прекрасно знаете, что правильные индексы и некривые запросы дадут для производительности гораздо больше, чем шардинг и балансировка нагрузки, не считаете NoSQL панацеей и смеетесь над идеей применять MongoDB в качестве основного хранилища реляционных по своей природе данных. А еще вы без фанатизма используете ORM тогда, когда это нужно, «голые» запросы, когда это оправдано и не боитесь переносить логику во внешние ключи, триггеры и процедуры.

    Да? Возьмите с полки 20 баллов, вы готовы к будущему. Остальным — всё тот же выбор. Не задерживаем очередь, выбираем — вымирать или развиваться? Следующий!

    Подведём итоги


    200 баллов


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

    От 100 до 200 баллов


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

    Менее 100 баллов


    Много вкусного мяса! «Мням-мням-мням» — слышите, как щелкают челюсти ваших конкурентов? Сожрут-с, однако.

    P.S. Не воспринимайте тест всерьёз, всё-таки пятница!
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 245
    • –1
      Используете md5 для хэширования паролей

      Объясните, в чем проблема? Как надо правильно делать?
      PHPStorm?

      wtf?
      Zend? Symfony? Laravel? Yii, прости господи?

      А, просто, папочка Vendor?
      • +9
        • +17
          Вы вкусный наверное, надо попробовать!
          • +4
            Как бы живот не заболел от такого давнишнего мяса.
          • +1
            Объясните, в чем проблема?

            Для md5 легко подобрать коллизию. Лучше использовать bcrypt (хотя уже говорят что и это не ок, и нужно юзать scrypt но и bcrypt для большинства систем достаточно). Ну и можно погуглить почему медленные алгоритмы хэширования паролей лучше в контексте безопасности.

            Как надо правильно делать?

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

            wtf?


            Вот тут солидарен. PhpStorm няшка, но я знаю массу разработчиков которые перешли на vim, как раз для того что бы умный ide, в котором есть масса удобных штук, не подначивал делать плохо. Ну и да, vim многие настраивают под себя, и есть в принципе неплохие проекты реализующие сервер для автокомплита. VIM это круто. Хотя я еще не дорос… Для меня пока только phpstorm, netbeans и тд.

            А, просто, папочка Vendor?

            Не просто. Тут больше акцент внимания стоит выделить на том, что люди понимают зачем нужно использовать готовые решения типичных задач. То есть просто папочка vendor значит что вы используете composer. Круто. Но вот если вы, к примеру, используете какой-то пакет реализующий PSR-7 как слой абстракций над HTTP, то это уже круче.
            • –4
              Для md5 легко подобрать коллизию.

              это вы где такое услышали?
              • +1
                Под «легко подобрать коллизию» я имею в виду возможность взять GPU и очень очень быстро считать хэши, если сравнивать с медленными bcrypt или scrypt.
          • +4
            Объясните, в чем проблема? Как надо правильно делать?

            php.net/manual/ru/function.password-hash.php
            php.net/manual/ru/function.password-verify.php
            • 0
              Это все хорошо, и это мы знаем, но PHP 5 >= 5.5.0
              По собственному опыту php 5.5 стоит только у 30% пользователей, да вот такой парадокс.
              До сих пор часто встречаю php 5.2 у пользователей, на хостинге.
              Расскажите как тогда пользоваться функциями php 5.5 и выше, если у более 50% стоит 5.2, 5.3, 5.4
              Как отправлять продакшн модули, с функциями 5.5 и выше?
              По опыту тех. поддержки модулей с требованиями php 5.3 и выше, частенько встречаю «глупые» вопросы, «а почему у меня белый экран» и ничего не показывает
                • 0
                  Ну, в этом случае 10% «пользователей» php 5.2 можно по… ть :)
                  Хотя если честно 5.2 это уж вообще деградация хостеров.
                  И пришлось в конце концов установить требования php 5.3 и выше к своим продуктам.
                • +1
                  Мне, например, наплевать на существование шаред хостингов, а код я в последний раз продавал 16 лет назад и вообще не понимаю этого бизнеса. Клиентам нужно решение задач их бизнеса, а не какой-то там код, хостинг и прочая ерунда.
                  • 0
                    :)
                    E-commerce системы не решение задач для бизнеса?
                    Что «вы» все зацикливаетесь на обычных сайтах и совсем забываете о e-commerce бизнесе.
                    16 лет назад не было того, что сейчас. Сейчас очень бурно развивается направления «интернет-магазинов» обычными «домохозяйками». Где они хостятся? ;) Правильно на шаред хостингах. И хорошие модули (код) очень востребованы.
                    • +2
                      Непонятно, зачем домохозяйке такие сложные технические манипуляции — для них есть shopify и подобные сервисы.
                      • 0
                        Серьезно? shopify? Для «домохозяек»?
                        Вы к примеру пробовали opencart? Я смотрю вы не особо в «теме» ИМ -в (без обид). Я понимаю у каждого своя специализация
                        • 0
                          Если пользоваться готовыми темами — вполне для домохозяек. Еще ecwid есть. Ну или всякие там wix.com (вроде там был примитивный e-commerce?), если уж для совсем-совсем домохозяек.

                          У opencart я видел исходный код, после чего все свои усилия сосредоточил на том, чтобы развидеть. :-)
                          • 0
                            Идеального кода не бывает, но есть еще такое понятие как архитектура. По моему мнению она тоже не идеальна у opencart (мне очень многое не нравиться именно в архитектуре), но получше чем у существующих php e-commerce систем.
                            И как показатель, рост сообщества (очень не маловажный фактор для домохозяек), модулей, тем, сайтов на opencart. Здесь была статья, так вот, пару лет назад было в ру нете всего 5000 интернет-магазинов на opencart, а полгода назад уже насчитали 150`000.
                            • 0
                              Архитектура opencart лучше, чем magento, SRSLY?

                              Впрочем, если он так популярен, дарю бизнес-идею — сделайте opencart SAAS. Если вы правы — неплохо можно заработать.
                              • 0
                                лучше, чем magento, SRSLY?

                                В целом да. Возможно за последние 2 года в магенту что-то поменялось но…
                                • 0
                                  github.com/opencart/opencart/blob/master/upload/system/library/request.php

                                  Архитектура, да.
                                  • 0
                                    Это не opencart, это codeigniter, и он убог, да. Зато все просто. Можно без подготовки взять и перепилить под себя. А магенту… это только ради конвеерного производства, когда ты штампуешь интернет магазины пачками.

                                    • 0
                                      Вордпресс или там phpbb тоже можно без подготовки взять и перепилить, но назвать это архитектурой я бы постеснялся. В Magento много странностей, но там хотя бы видны признаки дизайна, а не «опа-опа и в продакшен».

                                      В codeigniter тоже прогоняют входные данные через htmlspecialchars? Бред какой.
                                • 0
                                  Лучше, потому что проще.
                                  Поэтому и такая популярность у opencart — он прост (при очень большом функционале) для обычных пользователей и очень прост для разработчиков (читаем модули дешевле в 5 раз (это лучшие, которые must have, а простые так вообще раз в 10 дешевле) чем для magento)
                                  И opencart в умелых руках — очень гибкий framework (да, не ослышались именно можно трактовать как fw, потому что уже имеет архитектуру а не просто куча кода)
                • +1
                  А что сейчас используют НЕ мамонты для того что бы следить за изменениями в базе данных?
                  • +8
                    А откуда могут взяться изменения в базе данных (речь про структуру БД) кроме тех, что внесли вы сами, как разработчик? У вас есть некий Нафаня, который по ночам залезает в БД и нещадно добавляет поля и индексы?
                    • 0
                      Есть команда, которая может удалять/добавлять поля/индексы итп. Всё это под контролем версий понятное дело. Разработчики всегда в курсе что твориться со структурой базы во время разработки, посредством конечно-же до боли знакомым всем — миграциям.

                      Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.
                      • +7
                        Что угодно. От файлов типа 0001_up.sql и 0001_down.sql и баш-скрипта, который умеет их скормить БД, до систем миграции, встроенных в используемый фреймворк. Особой разницы нет.

                        Смысл лишь в том, что все изменения в БД должны быть под контролем системы контроля версий. Как конкретно это реализовано — не так уж и важно, идеальной реализации еще не написано.
                        • 0
                          Тоже озаботился этим вопросом для legacy проекта на днях. И вот, разрешите вам представить — phinx.

                          В Symfony проектах это doctrine migrations, куда же без них.
                          • 0
                            Кажется, Вы тот кто понял мой вопрос. Огромное спасибо!
                            Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.
                            • 0
                              А какие у вас проблемы с миграциями доктрины?
                              • 0
                                Возможно такие, что я неправильно их готовлю… Не особо в этом разбирался, миграции достались в наследство вместе с проектом. Попросту говоря, сейчас, это простой phar который всем управляет… Но что мне не нравится, так это то что достукаться до модулей приложения я не могу. Использовать такой же сахар, как скажем, в phinx тоже нет… Да и постоянные проблемы вылазят во время этих же миграций… То оно примененную миграцию в свою же таблицу записать не может, то ещё что-то…

                                Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.
                                • +1
                                  Честно говоря подобных проблем не испытывал все время использования миграций. Да, у них есть ограничения, но не все они именно доктриновские. В MySQL, к примеру, если миграция рушится на изменении схемы (во время отладки, положим), то схема останется в полуразобранном состоянии. Это особенность MySQL (и MS SQL Server тоже). Postgres же корректно откатывает все изменения.

                                  Что касается доступа к модулям — есть ContainerAwareMigration которая по-идее как раз эту проблему и решает (если я правильно понял).

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

                                  Я бы рекомендовал все-таки попробовать разобраться, провести рефакторинг и научиться готовить. Phinx конечно интересен, но он прежде всего ориентирован на проекты без ORM.
                                  • 0
                                    В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций

                                    Спасибо за наводку на ContainerAwareMigration. Обязательно посмотрю что это за зверь.

                                    А ORM и нет :) Всё что от доктрины — миграции. По-этому phinx тут как раз кстати.
                                    • 0
                                      As you wish =)
                                      • 0
                                        Oracle?
                                        • 0
                                          PostgreSQL?
                                          • 0
                                            MySQL?
                                          • 0
                                            Вопрос был поставлен из-за особенностей реализации взаимодействия с Oracle в современном php-мире. Откройте как-нибудь драйвер oci8 в Doctrine 2.
                                            • 0
                                              Ммм… я увы не работал с ораклами, вы о том что нет реализации под PDO стабильной?
                                        • 0
                                          В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций

                                          ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.

                                          Спасибо за наводку на ContainerAwareMigration.

                                          Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.
                                          • 0
                                            ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.


                                            Отработала на половину, значит делаем полный rollback и сообщаем о эксепшене. Соответственно ничего и не мигрируем до момента пока не исправим.

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


                                            У меня как раз тот случай когда надо. Сервисы содержат методы со сложными выборками. Переписывать эти выборки или дублировать код ради этих целей — как-то не очень.
                                            • 0
                                              Отработала на половину, значит делаем полный rollback

                                              c MySQL не прокатит.

                        • –4
                          Согласен с подходом автора примерно на 95%. Спасибо, порадовали и дали дополнительный повод подумать, а не сожрут ли меня завтра...?
                          • +13
                            > и не боитесь переносить логику во внешние ключи, триггеры и процедуры.
                            а если я не боюсь, но и не переношу?
                            ммм, как у вас организованы миграции для триггеров и для процедур?

                            а вообще слишком агрессивно
                            • +1
                              Согласен, слишком агрессивно. Все зависит от проекта, еще больше зависит от заказчика и уж почти все зависит от денег которые заказчик вам платит. Если мне друг вася дает бутылку за то, чтобы я ему сделал лендинг, я естественно не буду делать под это репозиторий. Если большой проект который подразумевает рост то безусловно все в git.
                              • 0
                                git репозиторий я бы все равно создал, тк это не сложно и скорее облегчит процесс разработки даже однодневного проекта. А вот CI, авто-деплой и прочее разворачивать смысла точно нет.
                                • +1
                                  А что там «разворачивать»-то?

                                  Сценарий вида «скопируй конфиги, накати миграции, переключи симлинк» пишется за 15 минут. И сам по себе является документацией для процесса выкладки.
                                  Шаг сборки в TeamCity вида «выполни этот сценарий при изменении в master» — еще 5 минут.

                                  Итого 20 минут, а в результате — отсутствие каких-либо проблем с деплоем.
                              • 0
                                а если я не боюсь, но и не переношу?

                                Возможно, Вам это не нужно? ОК, не вопрос. Главное — понимать как это делать, если вдруг понадобится.

                                ммм, как у вас организованы миграции для триггеров и для процедур?

                                Вы не поверите!

                                $this->execute('CREATE PROCEDURE ...');
                                


                                Можете предложить более красивый вариант — с удовольствием поучусь.
                                • +1
                                  я к этому и спрашивал, что процедура и триггер не атомарные объекты и для них нужны отдельные способы миграции (например хранить полные тексты, тогда изменения не должны потеряться).
                                  но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это зло
                                  • +1
                                    бизнес логика размазанная на 2 уровня (приложение и базу) это зло

                                    Позвольте не согласиться. Что же злого, к примеру, во view, которая нами сделана, чтобы агрегировать статистику по какому-то параметру и разрезу? А это бизнес-логика, на минуточку. Или вы предлагаете в таких случаях вытаскивать все данные в приложение и обрабатывать? Зачем? База данных по определению лучше справится с данными.
                                    • 0
                                      Это зло, если система миграций не позволяет отслеживать, что и где (и какого черта) поменялось в базе и сравнивать с продакшеном то, что должно в итоге получиться. И добро (относительное) в некоторых проектах при условии, что ваша система миграции не допускает потери изменений или рассинхронизаций ни при каких обстоятельствах.
                                      • 0
                                        если система миграций не позволяет отслеживать, что и где (и какого черта) поменялось в базе

                                        Разумеется. Это хреновая система миграций.
                                      • +1
                                        вообще странный у вас какой-то выбор, сделать VIEW или вытащить все данные, а что SQL запросы уже отменили?
                                        обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать

                                        > База данных по определению лучше справится с данными.
                                        не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.

                                        ну и изначально разговор был про триггеры и хранимки
                                        • 0
                                          Товарищ прав про то, что view — это гадость, кстати. Потому что во view жестко зашит список колонок. Когда нужно добавить новую колонку в ту или иную таблицу, приходится альтерить и все (или многие) view, которые таблицу используют — по крайней мере, при активной разработке и и развитии проекта именно так и происходит подчас.
                                • +37
                                  А когда-то на Хабре были и сиськи по пятницам…
                                  • 0
                                    Они ушли на автокадабру.
                                  • +5
                                    legacy-код — это не проблема кода, а проблема вашей лени


                                    Имеется в виду лень уволиться с сытного, но «технологически отсталого» места? Или всё таки это намёк, что нужно изучать технологии без реальных задач?
                                    • –2
                                      Имеется в виду, что проверка совместимости кода со следующей версией PHP достаточно тривиальна. А адаптация — незатратна.

                                      Нет ни одной причины работать на 5.3 или старше даже в случае легаси. Создайте тестовый стенд. Ловите каждую ошибку и отправляйте в свой любимый таск-трекер через его API. День на автоанализатор кода, благо все несовместимости тщательно задокументированы. Неделю потратьте на ручное тестирование сомнительных мест или написание тестов — смотря что Вам ближе. Не торопясь исправляйте найденные ошибки.

                                      Лень? А получить фактически бесплатный прирост производительности в 2-3 раза не лень?
                                      • +2
                                        на самом деле бывает дешевле держать отдельное окружение под legacy проекты чем их переписывать
                                        • +2
                                          Скорее проще — если есть понимание, что некий кусок кода/сайт/whatever будет списан в утиль как целое по мере готовности полностью нового — тогда, да, более-менее осмысленно.
                                    • +2
                                      VCS, миграции, сборки… Все так, но причем тут PHP?

                                      А вообще «тест Джоэля» о том же, только лучше. Хоть и был создан 15 лет назад.
                                      • +7
                                        VCS, миграции, сборки… Все так, но причем тут PHP?

                                        В целом неплохому языку не повезло. Неверное позиционирование, лишняя консервативность, низкая планка входа.
                                        Отсюда низкий в среднем (!) уровень разработчиков, выражающийся в незнании современных инструментов разработки и пренебрежении ими.

                                        Поэтому для многих именно PHP-программистов некоторые слова и термины из теста станут открытием.
                                      • 0
                                        Господа, а поясните пожалуйста что не так с array()?
                                        • +1
                                          Ну по-моему
                                          $a=[];
                                          лучше смотрится :)
                                          • +8
                                            И все?
                                            • +1
                                              2 символа вместо 7. К тому же скобки () пишутся с шифтом, а в случае [] без шифта. Какие преимущества у array()?
                                              • –5
                                                Подсветка. Не заметно, один параметр передается в функцию или несколько.

                                                $this->someMethod($foo, $bar);
                                                

                                                $this->someMethod([$foo, $bar]);
                                                

                                                $this->someMethod(array($foo, $bar));
                                                
                                                • +3
                                                  public function someMethod(array $a) { ... }
                                                  
                                                • 0
                                                  Я не сказал что у array() есть преимущества. Мне действительно интересно, может я чего-то не знаю.
                                                  • +3
                                                    не обращайте внимания, это для товарищей, которые под программированием подразумевают 8-ми часовое ежедневное печатание на клавиатуре.
                                                    • 0
                                                      Отсутствие преимуществ уже есть недостаток. Ну и потом, именование массива тоже может попасть под код-стайлы, у вашего array() шансов никаких против [] в этом случае.
                                                    • –1
                                                      Преимущества array() — поддержка большим числом версий PHP, включая все еще распространную версию 5.3.
                                                      Например, если вы делаете приложение, предполагающее установку на серверах клиентов, то лучше иметь в требованиях инсталляции как можно более широкий диапазон версий.
                                                      • +2
                                                        Вы были бы безусловно правы, если бы различия между 5.3 и 5.6 на array() и заканчивались. Но так как это не так, то это не очень-то и преимущество.
                                                        • 0
                                                          php5.3 увы больше не поддерживается, да и суппорт 5.4 скоро дропнут. Лучше стимулировать спрос хостингов с более новыми версиями php.

                                                          p.s. Лично я не пользуюсь услугами шаредов, как по мне VDS намного лучше и удобнее.
                                                          • 0
                                                            Как пользователь шаредов хочу добавить, что даже отечественные второсортные хостинги уже давно имеют на борту хоть и не 5.6, но 5.5 точно. Так что «популярные 5.3» — это лишь отговорка. А если и нет, то стоит побыстрее бежать оттуда, всё же «фиксы безопасности», коих нет в 5.3 (и скоро не будет в 5.4) — это не пустой звук.
                                                      • 0
                                                        а меня-то за что минусуете? xD
                                                  • +75
                                                    Каждый раз, когда я вижу такие тесты, моя рука как-то сама тянется к пистолету.

                                                    Как известно, нет более рьяных фанатиков, нежели новообращённые. Вычитал священную истину? Срочно вызубри её и понеси дальше. Задумываться при этом необязательно, от Священных постулатов исходит самоочевидный ореол непререкаемой мудрости.

                                                    Дорогой топикстартер! Пожалуйста, запомни одну простую вещь: использование любого инструмента в первую очередь должно быть адекватно задаче. И во вторую тоже. А не тому, что написали в очередной умной книжке.

                                                    Ну вот из самого очевидного:

                                                    > Ну сколько раз повторять — ВСЁ ДОЛЖНО БЫТЬ В GIT-Е!

                                                    Очевидно, всегда можно придумать множество примеров того, что не должно быть в гите. Зачем повторять капсом?
                                                    Приватные ключи разработчиков не должны быть в гите, например.

                                                    > Каждой задаче — своя ветка

                                                    Зачем? Средство должно быть адекватно задаче, не наоборот. Если стоит задача поправить документацию — зачем ей своя ветка? Чтобы что?

                                                    > Любая ветка рано или поздно будет влита в стабильную (тем или иным путём) и/или удалена

                                                    Например, дев-ветка с кастомными настройками проекта никогда не будет влита в стабильную и/или удалена.

                                                    > Или считаете себя умнее всех и написали свой велосипед для выкладки релизов?

                                                    Надо же, куда не посмотри — везде свой велосипед для выкладки релизов:
                                                    cloud.google.com/appengine/docs/python/tools/uploadinganapp
                                                    devcenter.heroku.com/articles/deploying-php
                                                    developers.openshift.com/en/managing-deployments.html

                                                    С нетерпением жду, когда Гугл, Хероку и Редхат вымрут, как мамонты.

                                                    > если вы постоянно работаете более, чем с одним современным фреймворком

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

                                                    > Плюс еще 5, если вас хотя бы однажды посещала мысль «До чего же криво в этом фреймворке реализовано X, я бы переделал» или плюс 15 баллов, если вы взяли и переделали.

                                                    Картинка «Situation: we have 15 competing standards».jpg

                                                    > Вы хотя бы раз в жизни выбирали сервер БД исходя из бизнес-требований к будущему приложению (и остановились на Postgres, не так ли?). Вы отчетливо понимаете, что в общем случае каждый JOIN — это вложенный цикл, прекрасно знаете, что правильные индексы и некривые запросы дадут для производительности гораздо больше, чем шардинг и балансировка нагрузки, не считаете NoSQL панацеей и смеетесь над идеей применять MongoDB в качестве основного хранилища реляционных по своей природе данных.

                                                    Отличный пример двоемыслия в одном абзаце. «Исходя из бизнес-требований к приложению», но «прекрасно знаете» и «смеётесь над идеей». Оооок.

                                                    > Много вкусного мяса! «Мням-мням-мням» — слышите, как щелкают челюсти ваших конкурентов? Сожрут-с, однако.

                                                    Я не стал считать свои баллы. Подожду, пока меня сожрут.
                                                    • +28
                                                      Помимо приватных ключиков я бы ещё вытащил из гита продакшн конфиги и вендорные папочки, плюс всякие бинарники (например редис, тарантул, сфинкс, которые бывают хранятся локально вместе с проектом), плюс конфиги иде (.idea, .iml, etc.) тоже не стоит отправлять в гит. Всякий кеш тоже однозначно в игнор, включая tmp папочку с сессиями.

                                                      Этот список можно продолжать ещё долго, но результат один — автору статьи стоит вычесть у себя 5 баллов. =)
                                                      • –4
                                                        на счет .idea я бы поспорил. .idea/workspace.xml стоит игнорить, а все остальные настройки скорее всего понадобятся и остальным разработчикам.
                                                        • 0
                                                          Вполне возможно, только там зархардкожены пути так, что проще перенастроить, начиная с Command Line Tools плагина, заканчивая композером и старт-командами. Полезную информацию можно выдрать разве что о каталогах (что скрыто, что ресурсы, что сырцы, что ещё что-либо).

                                                          Больше я не представляю чего там полезного может быть, что прописано не в виде абсолютного пути.
                                                        • 0
                                                          Не, продакшн-конфиги должны лежать в отдельном git-е.
                                                          • +2
                                                            в принципе конфиги должны лежать в отдельной репе + какой нить ансибл/шеф для развертывания дев/продакшен нод, как и конфигов из гита нужных.
                                                            На сложных проектах быстро получить прод/дев окружение на физике или виртуалке достаточно сложно — слишком много иногда зависимостей — сервер бд, редис, кафки, кассандры, а развернуть какойнить pyenv с тремя разными версиями питона потому что кусок купленного сто лет назад продукта — легаси еще вполне живет на питон 2.6, и будет жить еще с полгода пока пилится next-gen version приложения.
                                                        • –19
                                                          Как известно, нет более рьяных фанатиков, нежели новообращённые.

                                                          Если вы это в мой адрес, Вы слегка ошиблись. Я первый коммит кода, написанного на PHP, сделал лет 10 назад, еще на PHP 4.

                                                          А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)
                                                          • +13
                                                            > А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)

                                                            Разве я пишу на Хабр статьи про то, что всё должно быть в гите?
                                                            • –1
                                                              Разве Вам кто-то запрещает?

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

                                                              Общее правило — «Всё в гите». Правило вводится в теории, но не ввести его нельзя.

                                                              Удачно подмеченные Вами исключения — это служебные файлы IDE, приватные ключи (собственно, а кому пришла такая идея в голову?), пароли в открытом виде, папка vendor (это бессмысленно, достаточно хранить composer.json, всё равно при сборке всё будет тянуться заново), папки ресурсов и прочее, что в .gitignore и так далее. Исключения постигаются на практике.

                                                              Не вижу противоречия между шуточно-серьёзным тестом и вашим комментарием. Они прекрасно дополняют друг друга, за что мы и любим Хабр.
                                                              • 0
                                                                Желательно помимо composer.json таскать composer.lock, даже не желательно, а более чем рекомендательно. И ставить всё через composer install.
                                                                • 0
                                                                  Тоже верно. Впрочем, на тестовых стендах можно и composer update запустить. Лишним не будет.
                                                                  • +5
                                                                    На тестовых нельзя. Только на девовских. Тестовые стенды должны быть идентичны продакшену.
                                                                  • +1
                                                                    А еще лучше делать composer install на билд-машине, а на серверы притаскивать готовый tarball со всеми зависимостями.

                                                                    Composer install на продакшене допустимым считаю, только если поднят свой packagist, и все зависимости лежат на своем сервере. Иначе может и github прилечь, и packagist — всякое случается (вон, недавно китайцы github ддосили), такие вещи не должны останавливать деплой.
                                                            • 0
                                                              Приватные ключи разработчиков не должны быть в гите, например.

                                                              ну я к примеру храню их в git (зашифрованными в gpg), и доступ к содержимому архива есть только у меня. На каждый сервер генерируется свой ключ и что бы не потерять оный, и легко было заменить, лучше хранить в git. По поводу приватных штук (креды к внешним api и т.д.) — так же есть варианты, в зависимости от того что используется для деплоймента.
                                                            • +56
                                                              Вы копаете ямы обычной лопатой, а не лопатой с супер черенком 7.0?
                                                              Вы используете лопату нажимая ногой, а не втыкая с разворота?
                                                              Вы не используете в работе 2-3 инновационные лопаты одновременно?
                                                              Вы не делаете тестовых ям, чтобы потом накатить на основную яму?
                                                              У вас все еще нет автоматических тестов устойчивости для вашей ямы?

                                                              Вы обречены… другие ямы поглотят вас!
                                                              • +3
                                                                Интересно было бы увидеть список успешных бизнесов, победивших конкурентов за счет немамонтовости в разработке.
                                                                • –3
                                                                  Ну там Гугл например?
                                                                  • +2
                                                                    победивших конкурентов за счет немамонтовости в разработке.

                                                                    немамонтовость разработки дает несколько другие вещи:

                                                                    — предсказуемость (git-flow, continuous delivery)
                                                                    — уменьшение затрат на поддержку (популярные готовые решения, пусть они и не идеальны, всегда лучше чем самописный велосипед)
                                                                    — уменьшение затрат на изменение/внедрение нового функионала

                                                                    Все это позволяет более гибко упровлять релизами и добавлять плюшки, доставлять пользователям больше ценности и за счет этого уже побеждать. На и да, можно просто жахнуть денег в маркетинг.
                                                                    • 0
                                                                      Вопрос немного в другом, стоит ли гнаться за всеми немамонтовыми фишками, новыми версиями языков и т.д. Ведь это деньги на переобучение, перестроение процессов или найм людей. Ведь с другой стороны, старые бизнес-процессы разработки тоже работали. Т.е. для крупных компаний окупаемость в несколько лет имеет смысл (или нет?), но всем поголовно?
                                                                      Вот и хотелось бы увидеть сравнение нескольких компаний с конкурентами, ключевым фактором победы у которых было бы следование всем новым лучшим практикам.
                                                                      • 0
                                                                        Ведь это деньги на переобучение

                                                                        Деньги на переобучение — возможно, как долгосрочная инвестиция, но проще найти новых разработчиков если все так уж плохо. Здравый смысл никто не отменял, нужно менять все постепенно. Обычно вводится одна плюшка, которая тянет за собой другую, потом третью. continuous improvement и все такое.
                                                                  • +9
                                                                    PHPStorm холивара ради?
                                                                    • +5
                                                                      Проплачено же.
                                                                    • +3
                                                                      «Неважно какой фреймворк вы используете, простейший механизм миграций в состоянии написать даже Junior за пару часов.»

                                                                      1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?

                                                                      2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?

                                                                      3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.
                                                                      • 0
                                                                        Есть ровно два подхода.

                                                                        1. Вы запрещаете откат такой миграции (что сводит на нет всю систему миграций, как истории изменений)
                                                                        2. Вы не запрещаете откат, но он не производит никаких действий.

                                                                        Третий вариант, когда откат поднимает прежние данные из бэкапа, не имеет смысла на боевой базе и может применяться разве что для отладки.
                                                                        • +1
                                                                          1. Нет, не сводит на нет. Лучше иметь возможность отката для большинства миграций, чем вообще её не иметь.
                                                                          2. Отличный способ получить напрочь сломанный проект в результате отката.
                                                                          3. Восстановление из бэкапа не так страшно для продакшна, как Вы расписываете. Во-первых бэкап нужно делать автоматически перед миграцией на новую версию. Таким образом, если с новой версией обнаружатся проблемы, то скорее всего это случится в течении минут, максимум часов после обновления, и восстановление из бэкапа приведёт к потере минимума данных. Во-вторых если только это не реально большой проект с HA и избыточными серверами то он в любом случае будет восстанавливаться из бэкапов если умрёт винт. Так что если это будет происходить не раз в 3-5 лет, а раз в год-два из-за ошибок девелоперов при выкатывании новой версии — никакой трагедии в этом нет.
                                                                          • +1
                                                                            > Во-первых бэкап нужно делать автоматически перед миграцией на новую версию
                                                                            ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.

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

                                                                            • 0
                                                                              он будет сутки делаться и пока он будет делать там ещё данных набежит
                                                                              Ну дык бэкапы тоже нужно правильно делать.

                                                                              Данные нужно организовывать так, чтобы те таблицы, которые реально большие и которые полностью бэкапить слишком долго, были инкрементальными — т.е. чтобы в них делался только INSERT, без UPDATE/REPLACE/DELETE (на самом деле DELETE тоже можно для компактификации, но это делается отдельно). Это позволит сделать полный бэкап только для небольших таблиц, а для больших сделать инкрементальный бэкап только новых записей (более того, если эта миграция не будет делать ALTER этим большим таблицам то можно вообще просто запомнить id последней строки и реально бэкапить интервал нужных строк этих таблиц уже после завершения миграции на новую версию).

                                                                              При таком подходе бэкап большинства даже весьма крупных проектов будет занимать секунды.
                                                                              • 0
                                                                                эм, а вы такой инкрементальный бекап сами настраивали? и если вдруг да, то восстановится потом пробовали?
                                                                                это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
                                                                                большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.
                                                                                • 0
                                                                                  Не только настраивал и использовал в продакшне годами, есть готовый фреймворк Narada для разработки и деплоя таких проектов — с поддержкой бэкапов, миграций, etc… Он сам написан на Perl+sh (устанавливается как обычный Perl-модуль), но разрабатывать проекты используя этот фреймворк можно на любом языке.
                                                                                  • +1
                                                                                    это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят
                                                                                    Нет, дело не в кейсе и не в данных, а в способе их организации. Это аналогично тому, что для удобства тестирования требуется немного иначе писать код — в данном случае для удобства бэкапов требуется немного иначе работать с данными.

                                                                                    Типичный приём — колонки в таблице A, которые содержат большие объёмы данных (текстовый контент, json, блобы) выносятся в отдельную инкрементальную таблицу B, а в таблице A эти колонки заменяются колонками с id записей в таблице B. Это позволяет значительно уменьшить размер таблицы A и ускорить её (полный) бэкап. Любое изменение данных вынесенных в таблицу B реализуется добавлением новой записи в таблицу B и изменением её id в таблице A. Для уменьшения размера базы можно периодически удалять все записи в B на которые больше нет ссылок в A и делать полный бэкап B.

                                                                                    Это несколько усложняет код и добавляет лишний (но очень быстрый т.к. работает по primary key) JOIN в некоторые запросы, но зато даёт возможность бэкапить проект в течении пары секунд. Что в свою очередь даёт возможность блокировать проект на время бэкапа фактически незаметным для пользователей образом (задержка ответа на пару секунд мало заметна). Что даёт возможность атомарно делать консистентные бэкапы включающие файлы/логи/настройки/базы проекта. Плюс такие блокировки дают возможность так же атомарно обновлять проект. В общем, если взвесить все недостатки и преимущества такого подхода незначительное усложнение при работе с некоторыми колонками в базе оказывается вполне приемлемым.
                                                                              • +1
                                                                                из-за ошибок девелоперов при выкатывании новой версии

                                                                                Это невозможно при грамотно построенном воркфлоу. Например в моем текущем случае без визы QA и человека от бизнеса на препродакшне никакая выкатка на прод невозможна физически. И более того — девелоперы вообще не имеют доступа к процессам деплоя.

                                                                                Задача проходит три стенда — изолированный, интеграционный и предпродакшн. Во всех случаях деплой полностью автоматический и ручное вмешательство крайне нежелательно. Право же нажать кнопочку Run на продакшне есть только у специально обученного человека, а сама кнопка не появится без получения двух виз, о которых я говорил выше.
                                                                                • +1
                                                                                  Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн. И в этом случае количество виз и специально обученные люди которые имеют право на выкатывание — хоть и уменьшают вероятность ошибки, но не сводят её к нулю.

                                                                                  Ну и кстати опыт показывает, что когда деплой делается несколько раз в день (разумеется, автоматизированно!), пусть даже по инициативе одного девелопера, это ведёт к меньшему количеству ошибок, чем когда он делается редко (т.е. с большим количеством изменений) но с участием виз и специально обученных людей.
                                                                                  • 0
                                                                                    Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн


                                                                                    Так ровно на это пост и намекает. Зачем держать код задачи в отдельной ветке? Зачем писать сценарии сборки? Для того, чтобы отдельно тестировать!
                                                                                    Поверьте, для этого есть очень дешевые (и по деньгам и по времени) технологии и приёмы. Те, кто их не применяет — те сами себе злобные буратины и мамонты.

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

                                                                                    Подписываюсь. За исключением возможности девелоперу инициировать выкладку. Для меня это звучит абсолютным абсурдом.
                                                                          • 0
                                                                            со всеми пунктами согласен, но почему PHPStorm? Чем netbeans не угодил? Или просто скажите мне, что не может netbeans по сравнению со штормом и я скажу как это сделать.
                                                                            • +7
                                                                              Вызов принят!

                                                                              1) Простенькое: Множественное выделение кода
                                                                              2) Средненькое: Переименовывание класса, включая все зависимости от него
                                                                              3) Чуть посложнее: Поиск по классам, так, например «So\An» найдёт класс «namespace Some; class Any» из всех сырцов (исключая скрытые)
                                                                              4) Ещё более круто: Анализ composer.json с указанием установленной версии зависимости (из lock файла) прямо в коде composer.json?
                                                                              5) Вообще верх крутости: Интеллектуальный поиск с автодополнением по Dependency Injection контейнерам, включая анализ аннотаций
                                                                              • 0
                                                                                расскажите про пятый пункт поподробнее, потому как DI контейнер только по аннотациям работает, сам PhpStorm конфиги не понимает. Вы каким-то плагино пользуетесь? В рамках какого-то фреймворка?
                                                                                • 0
                                                                                  Не только с аннотациями, можно же ещё напрямую вытаскивать, например так: Container::get(Some::class)->…

                                                                                  Плагин, если не путаю — Symfony2 Plugin этим занимается. Совместим с Laravel (4,5), PHP-DI и наверняка с какими-нибудь плюшками симфони (доктриной, например).
                                                                                  • 0
                                                                                    PHP Annotations + Symfony Plugin (при открытии или в проекте надо выбрать фреймворк) + Symfony Clickable Views
                                                                                • +2
                                                                                  А еще в netbeans не завезли нормальный интерфейс (имхо), и он жутко тормозит (объективно, сравнивал на одной машине).
                                                                                • +11
                                                                                  Взгляд неандертальца. :-)
                                                                                  Мамонтов вы, конечно, сожрете, но совсем недалеко стоянка кроманьонцев с docker, heroku, devops, lean-kanban и macbook-ом с красивыми наклеечками.
                                                                                  • –17
                                                                                    docker на макбуке с наклеечкой превращается в VirtualBox, хотя конечно если снести предустановленную фигню на макбуке и поставить операционную систему
                                                                                    • +1
                                                                                      Да хотя бы таким неандертальцем стать.

                                                                                      Сейчас приходится работать с проектами, где:

                                                                                      1. PHP 5.2 (а в особо глубоких местах и PHP4)
                                                                                      2. Один репозиторий SVN на всё, без веток. Поэтому, когда надо что-то быстро поменять, идём ручками по серверам и меняем, потому что в SVN лежит коммит, который пока ещё нельзя выкладывать
                                                                                      3. База данных — зачем? Пусть всё хранится в json-файликах, которые другой PHP через system('rsync..') разливает по серверам.
                                                                                      3.1 Ну и никто не знает, как чинить этот другой PHP в случаях, если он не работает.
                                                                                      4. А даже если и есть база, то зачем миграции? Давайте просто отправлять SQL-ки админу, а он их выполнит
                                                                                      5. Автоматические тесты — что это вообще?
                                                                                      6. Во вьюхе в зенде открыть json файлик, распарсить и вывести — это ок.
                                                                                      7.…
                                                                                      8. PROFIT

                                                                                      Извините, накипело.
                                                                                      • +2
                                                                                        Сейчас приходится

                                                                                        Под дулом пистолета приходится?
                                                                                        Если вы понимаете, почему плохо то, о чём пишете — почему Вас нет на HH?
                                                                                        • +1
                                                                                          А за что вам минус поставили? Оо
                                                                                          Просто работаю в другой стране с маленьким выбором вакансий, комментарием ниже подробнее написал.
                                                                                        • +2
                                                                                          Присоединяюсь к вышевысказавшемуся.
                                                                                          Копошась (другого слова не подберу) в таких вот условиях, вы теряете время и отстаете от современных технологий. Если нет каких-то особенных связей с текущим местом (угроза расправы, з/п намного выше рынка, единственный работодатель в окрестностях, обет), то надо уходить. Хорошего опыта вы там не получите, о новых подходах не узнаете, потеряете инициативность и просто деградируете как специалист.
                                                                                          Не нужно, думаю, объяснять, что современный прикладной программист — это не только технологии непосредственно программирования, но и современный тулстэк, методологии работы с задачами и заказчиками и т.п.
                                                                                          Тем более с вакансиями положение неплохое.
                                                                                          • +4
                                                                                            Как раз есть особенные связи. Работаю системным администратором в Колумбии (которая не штат, а страна), тут всё тяжело в IT. А на этом месте работы и зарплата выше рыночной, и такую работу, где могут организовать визу, проблемно найти. В принципе, постепенно всё и тут двигается, стараюсь, внедряю и оптимизирую что могу. Но разруха — она в головах.
                                                                                            Зато остаётся время на фриланс и свои проекты, где всё более радужно:)
                                                                                          • –1
                                                                                            Нужны интересные вакансии (современный PHP, современные средства разработки, не сайтики) — стучитесь в личку. Думаю, договоримся.
                                                                                        • 0
                                                                                          Давайте лучше приколимся результатами, у меня 115 набралось ) больше из за git и велосипеда с deploy
                                                                                          • +16
                                                                                            Молодые мамонтята читают такие посты, подрастают и потом мы видим кучу бесполезного УГ, но с очень правильным и красивым бэкэндом. Странно что не упомянули о какой-нибудь модной методологии типа аджайла. Наверное, после постов типа «почему аджайл не работает» это уже не так модно? Видимо, надо написать ещё десяток статей а-ля «почему мой проект плох, ведь я хранил весь код в гите» или «почему товар в моём магазине не покупают, ведь его сайт написан на php версии over 9000».
                                                                                            • +4
                                                                                              Автор случаем не перепутал в тесте слова «знаете» и «используете»?
                                                                                              Знать все это перечисленное барахло — надо, использовать — только при необходимости.
                                                                                              Прошедшие тест люди нас будут изрядно пугать, потому что у них тупо отсутствует гибкость.
                                                                                              Основное качество адекватного разработчика.

                                                                                              Вброс с phpstorm особенно доставил, zend studio что, никто не использует из модных ребят?
                                                                                              • 0
                                                                                                Пробовал разок Zend. Заткнулся на попытке создать проект из существующей папки, так до сих пор и висит одиноко ярлычок, даже опробовать не получилось. Готов с удовольствием выслушать как это сделать, попробовать то хочется, можно даже в личке, дабы не оффтопить.
                                                                                                • 0
                                                                                                  Честно говоря, не поняли даже в чем именно у Вас затык.
                                                                                                  Проект создается по старому принципу «создать проект — далее — далее — готово»:)
                                                                                                  Правда у нас 8-ка, обновляться жаба душит, а ее вполне хватает.
                                                                                                  Зенд не очень добр к ресурсам (тут да, жесть, при чем издревле, видимо из-за явы), поэтому перешли на него только с 8 версии (когда обзавелись достойным железом, до этого использовали nushpere phped), но на сейчас никаких проблем не испытываем.

                                                                                                  p.s.: Если есть вопросы — пишите в личку, чем сможем поможем, но скорость не обещаем. Или можно на почту. admin@наш_ник_здесь.ru
                                                                                              • +4
                                                                                                Я вот несколько лет назад на DEVConf слушал выступление одного мальчика, который что-то там придумал со своими друзьями, а потом встал мужичек в зале и сказал примерно следующее — «Пока вы делали все по правилам и стандартам, писали доки и комментили код фирма [какая-то-фирма] выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим». Так вот если у вас команда, есть готовый продукт и вы делаете рефакторинг для того чтобы клиенты не падали в обморок, то да, всё что писал ТС верно, но если вы реализуете идею то можно и спагетти-код и ничего в этом нет плохого.
                                                                                                • +4
                                                                                                  Такая проблема чаще всего возникает из-за того, что разработчики сосредоточены на «красоте» проекта. Код ради кода, а не ради бизнеса. Насколько я понимаю, то «мамонт» в посте — это опытный разработчик, который не использует новые инструменты. Думаю, что у опытного разработчика, который использует эти инструменты и подходы, время на выполнение проекта не сильно увеличится. Я бы даже сказал, что многие инструменты больше помогают в дальнейшей поддержке проекта. Проблемы будут лишь у тех, кто про эти вещи узнал, но не правильно их применил. Так что эта история больше относится к людям, принимающим неоправданные решения с точки зрения бизнеса (обычно это лиды и ПМы).
                                                                                                  • +1
                                                                                                    время на выполнение проекта не сильно увеличится

                                                                                                    Позвольте уточнить — оно радикально сократится. Хороший инструмент это тот, который снижает себестоимость (то есть уменьшает затраченное время). Поверьте, всё, что я перечислил в пятничном тесте, работает на снижение себестоимости. Если правильно применять.
                                                                                                    • +2
                                                                                                      Опять-таки надо разделять время на создание проекта и его дальнейшую поддержку. Часто решения «в лоб» по скорости разработки с нуля не сильно уступают некоторым подходам, которые вы описали. Зато на этапе поддержки (изменения функциональности) это может вылится в дикие трудозатраты и бессоные ночи(не всегда, но зачастую).
                                                                                                      Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
                                                                                                  • +1
                                                                                                    Хорошая стратегия — говнокод → рефакторинг → поддержка. Говнокод позволяет быстро запуститься и, если проект оказался востребованным, можно уже рефакторить, чтобы дальнейшая поддержка не превратилась в ад.
                                                                                                    • 0
                                                                                                      Это как так? Сначала запиливаем продукт, типа всё закончили, начали продавать, но без поддержки, мотивируя тем, что нам надо порефакторить, а вы тут пока как-нибудь сами? И кто его купит? Чаще всего платят именно за саппорт, голый код никому не сдался.
                                                                                                      • 0
                                                                                                        Почему без поддержки? О чём вы?
                                                                                                        • 0
                                                                                                          у вас поддержка в конце цепочки. вот мне и стало интересно, а отдаём клиентам-то когда, до или после рефакторинга?
                                                                                                          если до, то нафига им такое надо (говнокод да еще без поддержки)?
                                                                                                          если после, то в чем принципиальное отличие от написания сразу нормального кода? в чем выгода стадии говнокода?
                                                                                                          • 0
                                                                                                            до или после рефакторинга?

                                                                                                            Рефакторинг должен происходить в период разработки, по чуть чуть и часто. Тогда появление страшного легаси будет сведено к минимуму (совсем без него наверное никак, но это не должна быть вся система). Это конечно при условии что вам удалось объяснить руководству, ну или руководство само в курсе, что такое технический долг.

                                                                                                            То есть типичный флоу — сделали фичу (максимально простая реализация если это возможно), порефакторили если видите необходимость (дублирование логики например) или хотя бы пометили что какие-то решения были приняты в угоду скорости разработки и помечаются как технический долг. Далее при разработке фич, как-то относящихся к проблемным местам, можно рефакторить, уменьшать технический долг. Некоторые закладывают определенный процент тасков связанных именно с техническим долгом на итерацию (например 80%-90% времени на разработку фич, и остаток на устранение технического долга, зависит от масштабов трагедии и необходимости.) Какие-то сложные вещи могут идти как отдельные таски и приоритизировать (например костыль который влияет на производительность, или еще чего).
                                                                                                            • 0
                                                                                                              ну то есть говнокод в продакшен мы не пускаем. а тогда зачем делать говнокод+рефакторинг — вот этого я не понимаю. не проще сразу сделать нормально, но по минимуму для реализации требуемых фич? отдали набор фич в продакшен, тут клиент захотел новую фичу, похожую на имеющуюся. вот тут самое место рефакторингу, чтобы значит не копипастить, а подвести под обе фичи единую основу.
                                                                                                              Либо не делать рефакторинг, тогда со временем получится либо кривой продукт, либо прототип, который только выбросить можно. Но обычно никто так не делает, поэтому имхо лучше сразу писать нормально
                                                                                                              позволять себе говнокодить — не вижу, когда бы такая стратегия приносила профит
                                                                                                              • 0
                                                                                                                ну то есть говнокод в продакшен мы не пускаем

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

                                                                                                                не проще сразу сделать нормально

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

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

                                                                                                                Именно так. Тут есть нюансы, рефакторить нужно часто и маленькими этапами, и фичи дробить надо на как можно более маленькие.

                                                                                                                позволять себе говнокодить — не вижу, когда бы такая стратегия приносила профит

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

                                                                                                                А вот без тестов постоянный рефакторинг штука болезненная, и тогда ее откладывают уже по понятным причинам. Никто не хочет делать полное регрессионное тестирование на каждый чих.
                                                                                                            • 0
                                                                                                              Я смотрю ниже тему раскрыли :)
                                                                                                      • +3
                                                                                                        Зависит от размера проекта. Если для запуска достаточно пары ночей хакатона — да, наговнокодить уместно. Если же речь идет о неделях, хорошие практики только ускорят разработку — при условии, что уровень команды достаточно высокий.
                                                                                                        • +2
                                                                                                          «Хоть вы и говнокодите, не пишете доки и не комментите код, фирма [какая-то-фирма] уже выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим».

                                                                                                          Не всякий проект может позволить себе быть написанным говнокодерами. Не всегда выйти на рынок первым — значит победить. Не нужно делить мир лишь на черное и белое, как автор этого поста — «Всё в гит! Конфиги в гит! Или тебя съедят!»
                                                                                                        • +2
                                                                                                          А как же phpUnit и функциональные тесты?
                                                                                                          • –2
                                                                                                            Я вполне допускаю ситуацию, когда в реальном производстве именно юнит-тесты приходится писать крайне редко. Тестами покрыты библиотеки и ваш фреймворк — этого вполне достаточно в реальности.

                                                                                                            А функциональные тесты пишет QA-инженер и его команда.

                                                                                                            Впрочем, возможно, я слишком долго занимаюсь построением индустриальных команд разработки и идеализирую. Сорри.
                                                                                                          • 0
                                                                                                            > PHPStorm?
                                                                                                            Спор насчет редакторов и\или ide переживет еще не одного грозного питекантропа.
                                                                                                            И да, только ископаемые моллюски пишут исключительно на одном на php (или любом другом языке). Тем более используя php-специфичную ide. Почему использовать несколько разных ide плохо, объяснять я надеюсь не нужно.
                                                                                                            • +1
                                                                                                              php-специфичную ide

                                                                                                              Шторм не специфичен к PHP.
                                                                                                              В остальном Вы, разумеется, совершенно правы.