Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.
И это здорово!
Не совсем здорово то, что мы с вами, обычные разработчики, в массе своей всё больше отстаём от стремительного потока. История знает аналогичный пример — мамонты тоже отстали от стремительно меняющейся среды. И вымерли. Ну, или, по другой гипотезе — были съедены своими конкурентами за экологическую нишу — людьми. Неважно. Конец бедных гигантов в любом случае был печален.
Попробуйте пройти несложный тест и определить — не мамонт ли Вы в мире 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 баллов в студию!
И да, вы же помните — сценарии сборки у вас лежат где, где? Правильно,
Не знаете, что такое сценарии сборки? Не понимаете, зачем они нужны? Ааа, мамонт, еда для всего племени!!! Слышите, как уже бежит толпа охотников выбросить вас за борт?
Автоматический деплой
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. Не воспринимайте тест всерьёз, всё-таки пятница!
Комментарии (239)
AlexLeonov Автор
22.05.2015 18:33+4Объясните, в чем проблема? Как надо правильно делать?
php.net/manual/ru/function.password-hash.php
php.net/manual/ru/function.password-verify.php
maxic
24.05.2015 23:17Это все хорошо, и это мы знаем, но 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 и выше, частенько встречаю «глупые» вопросы, «а почему у меня белый экран» и ничего не показываетsymbix
25.05.2015 09:29+1Мне, например, наплевать на существование шаред хостингов, а код я в последний раз продавал 16 лет назад и вообще не понимаю этого бизнеса. Клиентам нужно решение задач их бизнеса, а не какой-то там код, хостинг и прочая ерунда.
maxic
25.05.2015 09:37:)
E-commerce системы не решение задач для бизнеса?
Что «вы» все зацикливаетесь на обычных сайтах и совсем забываете о e-commerce бизнесе.
16 лет назад не было того, что сейчас. Сейчас очень бурно развивается направления «интернет-магазинов» обычными «домохозяйками». Где они хостятся? ;) Правильно на шаред хостингах. И хорошие модули (код) очень востребованы.symbix
25.05.2015 10:43+2Непонятно, зачем домохозяйке такие сложные технические манипуляции — для них есть shopify и подобные сервисы.
maxic
26.05.2015 17:05Серьезно? shopify? Для «домохозяек»?
Вы к примеру пробовали opencart? Я смотрю вы не особо в «теме» ИМ -в (без обид). Я понимаю у каждого своя специализацияsymbix
26.05.2015 18:59Если пользоваться готовыми темами — вполне для домохозяек. Еще ecwid есть. Ну или всякие там wix.com (вроде там был примитивный e-commerce?), если уж для совсем-совсем домохозяек.
У opencart я видел исходный код, после чего все свои усилия сосредоточил на том, чтобы развидеть. :-)maxic
26.05.2015 19:25Идеального кода не бывает, но есть еще такое понятие как архитектура. По моему мнению она тоже не идеальна у opencart (мне очень многое не нравиться именно в архитектуре), но получше чем у существующих php e-commerce систем.
И как показатель, рост сообщества (очень не маловажный фактор для домохозяек), модулей, тем, сайтов на opencart. Здесь была статья, так вот, пару лет назад было в ру нете всего 5000 интернет-магазинов на opencart, а полгода назад уже насчитали 150`000.symbix
26.05.2015 21:23Архитектура opencart лучше, чем magento, SRSLY?
Впрочем, если он так популярен, дарю бизнес-идею — сделайте opencart SAAS. Если вы правы — неплохо можно заработать.
Fesor
26.05.2015 22:04лучше, чем magento, SRSLY?
В целом да. Возможно за последние 2 года в магенту что-то поменялось но…symbix
26.05.2015 23:24github.com/opencart/opencart/blob/master/upload/system/library/request.php
Архитектура, да.Fesor
27.05.2015 00:44Это не opencart, это codeigniter, и он убог, да. Зато все просто. Можно без подготовки взять и перепилить под себя. А магенту… это только ради конвеерного производства, когда ты штампуешь интернет магазины пачками.
symbix
27.05.2015 08:48Вордпресс или там phpbb тоже можно без подготовки взять и перепилить, но назвать это архитектурой я бы постеснялся. В Magento много странностей, но там хотя бы видны признаки дизайна, а не «опа-опа и в продакшен».
В codeigniter тоже прогоняют входные данные через htmlspecialchars? Бред какой.
maxic
27.05.2015 18:42Лучше, потому что проще.
Поэтому и такая популярность у opencart — он прост (при очень большом функционале) для обычных пользователей и очень прост для разработчиков (читаем модули дешевле в 5 раз (это лучшие, которые must have, а простые так вообще раз в 10 дешевле) чем для magento)
И opencart в умелых руках — очень гибкий framework (да, не ослышались именно можно трактовать как fw, потому что уже имеет архитектуру а не просто куча кода)
diwms
22.05.2015 18:42+1А что сейчас используют НЕ мамонты для того что бы следить за изменениями в базе данных?
AlexLeonov Автор
22.05.2015 18:44+8А откуда могут взяться изменения в базе данных (речь про структуру БД) кроме тех, что внесли вы сами, как разработчик? У вас есть некий Нафаня, который по ночам залезает в БД и нещадно добавляет поля и индексы?
diwms
22.05.2015 19:11Есть команда, которая может удалять/добавлять поля/индексы итп. Всё это под контролем версий понятное дело. Разработчики всегда в курсе что твориться со структурой базы во время разработки, посредством конечно-же до боли знакомым всем — миграциям.
Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.AlexLeonov Автор
22.05.2015 22:11+7Что угодно. От файлов типа 0001_up.sql и 0001_down.sql и баш-скрипта, который умеет их скормить БД, до систем миграции, встроенных в используемый фреймворк. Особой разницы нет.
Смысл лишь в том, что все изменения в БД должны быть под контролем системы контроля версий. Как конкретно это реализовано — не так уж и важно, идеальной реализации еще не написано.
hudson
24.05.2015 20:47Тоже озаботился этим вопросом для legacy проекта на днях. И вот, разрешите вам представить — phinx.
В Symfony проектах это doctrine migrations, куда же без них.diwms
25.05.2015 10:10Кажется, Вы тот кто понял мой вопрос. Огромное спасибо!
Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.hudson
25.05.2015 12:11А какие у вас проблемы с миграциями доктрины?
diwms
25.05.2015 12:53Возможно такие, что я неправильно их готовлю… Не особо в этом разбирался, миграции достались в наследство вместе с проектом. Попросту говоря, сейчас, это простой phar который всем управляет… Но что мне не нравится, так это то что достукаться до модулей приложения я не могу. Использовать такой же сахар, как скажем, в phinx тоже нет… Да и постоянные проблемы вылазят во время этих же миграций… То оно примененную миграцию в свою же таблицу записать не может, то ещё что-то…
Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.hudson
25.05.2015 13:05+1Честно говоря подобных проблем не испытывал все время использования миграций. Да, у них есть ограничения, но не все они именно доктриновские. В MySQL, к примеру, если миграция рушится на изменении схемы (во время отладки, положим), то схема останется в полуразобранном состоянии. Это особенность MySQL (и MS SQL Server тоже). Postgres же корректно откатывает все изменения.
Что касается доступа к модулям — есть ContainerAwareMigration которая по-идее как раз эту проблему и решает (если я правильно понял).
А проблема вставок в свою же таблицу это скорее всего результат «грязной» разработки — вмешательства в служебные таблицы «ручками», удаление миграций после их выполнения, неполный откат при фэйлах, разница в схемах в разных окружениях и т.д.
Я бы рекомендовал все-таки попробовать разобраться, провести рефакторинг и научиться готовить. Phinx конечно интересен, но он прежде всего ориентирован на проекты без ORM.diwms
25.05.2015 15:12В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций
Спасибо за наводку на ContainerAwareMigration. Обязательно посмотрю что это за зверь.
А ORM и нет :) Всё что от доктрины — миграции. По-этому phinx тут как раз кстати.
Electronick
27.05.2015 11:27Oracle?
Fesor
27.05.2015 12:18PostgreSQL?
Electronick
27.05.2015 13:37Вопрос был поставлен из-за особенностей реализации взаимодействия с Oracle в современном php-мире. Откройте как-нибудь драйвер oci8 в Doctrine 2.
Fesor
27.05.2015 13:54Ммм… я увы не работал с ораклами, вы о том что нет реализации под PDO стабильной?
Fesor
27.05.2015 12:17В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций
ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.
Спасибо за наводку на ContainerAwareMigration.
Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.diwms
27.05.2015 12:50ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.
Отработала на половину, значит делаем полный rollback и сообщаем о эксепшене. Соответственно ничего и не мигрируем до момента пока не исправим.
Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.
У меня как раз тот случай когда надо. Сервисы содержат методы со сложными выборками. Переписывать эти выборки или дублировать код ради этих целей — как-то не очень.
Sartor
22.05.2015 18:56-4Согласен с подходом автора примерно на 95%. Спасибо, порадовали и дали дополнительный повод подумать, а не сожрут ли меня завтра...?
neolink
22.05.2015 19:00+13> и не боитесь переносить логику во внешние ключи, триггеры и процедуры.
а если я не боюсь, но и не переношу?
ммм, как у вас организованы миграции для триггеров и для процедур?
а вообще слишком агрессивно
Ugputu
22.05.2015 22:01+1Согласен, слишком агрессивно. Все зависит от проекта, еще больше зависит от заказчика и уж почти все зависит от денег которые заказчик вам платит. Если мне друг вася дает бутылку за то, чтобы я ему сделал лендинг, я естественно не буду делать под это репозиторий. Если большой проект который подразумевает рост то безусловно все в git.
hell0w0rd
23.05.2015 00:03git репозиторий я бы все равно создал, тк это не сложно и скорее облегчит процесс разработки даже однодневного проекта. А вот CI, авто-деплой и прочее разворачивать смысла точно нет.
AlexLeonov Автор
23.05.2015 00:08+1А что там «разворачивать»-то?
Сценарий вида «скопируй конфиги, накати миграции, переключи симлинк» пишется за 15 минут. И сам по себе является документацией для процесса выкладки.
Шаг сборки в TeamCity вида «выполни этот сценарий при изменении в master» — еще 5 минут.
Итого 20 минут, а в результате — отсутствие каких-либо проблем с деплоем.
AlexLeonov Автор
22.05.2015 22:38а если я не боюсь, но и не переношу?
Возможно, Вам это не нужно? ОК, не вопрос. Главное — понимать как это делать, если вдруг понадобится.
ммм, как у вас организованы миграции для триггеров и для процедур?
Вы не поверите!
$this->execute('CREATE PROCEDURE ...');
Можете предложить более красивый вариант — с удовольствием поучусь.neolink
23.05.2015 01:10+1я к этому и спрашивал, что процедура и триггер не атомарные объекты и для них нужны отдельные способы миграции (например хранить полные тексты, тогда изменения не должны потеряться).
но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это злоAlexLeonov Автор
23.05.2015 15:39+1бизнес логика размазанная на 2 уровня (приложение и базу) это зло
Позвольте не согласиться. Что же злого, к примеру, во view, которая нами сделана, чтобы агрегировать статистику по какому-то параметру и разрезу? А это бизнес-логика, на минуточку. Или вы предлагаете в таких случаях вытаскивать все данные в приложение и обрабатывать? Зачем? База данных по определению лучше справится с данными.
DmitryKoterov
23.05.2015 16:00Это зло, если система миграций не позволяет отслеживать, что и где (и какого черта) поменялось в базе и сравнивать с продакшеном то, что должно в итоге получиться. И добро (относительное) в некоторых проектах при условии, что ваша система миграции не допускает потери изменений или рассинхронизаций ни при каких обстоятельствах.
AlexLeonov Автор
23.05.2015 16:02если система миграций не позволяет отслеживать, что и где (и какого черта) поменялось в базе
Разумеется. Это хреновая система миграций.
neolink
23.05.2015 18:01+1вообще странный у вас какой-то выбор, сделать VIEW или вытащить все данные, а что SQL запросы уже отменили?
обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать
> База данных по определению лучше справится с данными.
не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.
ну и изначально разговор был про триггеры и хранимкиDmitryKoterov
24.05.2015 02:10Товарищ прав про то, что view — это гадость, кстати. Потому что во view жестко зашит список колонок. Когда нужно добавить новую колонку в ту или иную таблицу, приходится альтерить и все (или многие) view, которые таблицу используют — по крайней мере, при активной разработке и и развитии проекта именно так и происходит подчас.
vimruler
22.05.2015 19:38+5legacy-код — это не проблема кода, а проблема вашей лени
Имеется в виду лень уволиться с сытного, но «технологически отсталого» места? Или всё таки это намёк, что нужно изучать технологии без реальных задач?AlexLeonov Автор
22.05.2015 22:59-2Имеется в виду, что проверка совместимости кода со следующей версией PHP достаточно тривиальна. А адаптация — незатратна.
Нет ни одной причины работать на 5.3 или старше даже в случае легаси. Создайте тестовый стенд. Ловите каждую ошибку и отправляйте в свой любимый таск-трекер через его API. День на автоанализатор кода, благо все несовместимости тщательно задокументированы. Неделю потратьте на ручное тестирование сомнительных мест или написание тестов — смотря что Вам ближе. Не торопясь исправляйте найденные ошибки.
Лень? А получить фактически бесплатный прирост производительности в 2-3 раза не лень?neolink
23.05.2015 01:16+2на самом деле бывает дешевле держать отдельное окружение под legacy проекты чем их переписывать
mickvav
23.05.2015 14:14+2Скорее проще — если есть понимание, что некий кусок кода/сайт/whatever будет списан в утиль как целое по мере готовности полностью нового — тогда, да, более-менее осмысленно.
velvetcat
22.05.2015 20:02+2VCS, миграции, сборки… Все так, но причем тут PHP?
А вообще «тест Джоэля» о том же, только лучше. Хоть и был создан 15 лет назад.AlexLeonov Автор
22.05.2015 22:45+7VCS, миграции, сборки… Все так, но причем тут PHP?
В целом неплохому языку не повезло. Неверное позиционирование, лишняя консервативность, низкая планка входа.
Отсюда низкий в среднем (!) уровень разработчиков, выражающийся в незнании современных инструментов разработки и пренебрежении ими.
Поэтому для многих именно PHP-программистов некоторые слова и термины из теста станут открытием.
smarteq
22.05.2015 20:03Господа, а поясните пожалуйста что не так с array()?
MaximChistov
22.05.2015 20:07+1Ну по-моему
$a=[];
лучше смотрится :)smarteq
22.05.2015 20:09+8И все?
Blumfontein
22.05.2015 20:38+12 символа вместо 7. К тому же скобки () пишутся с шифтом, а в случае [] без шифта. Какие преимущества у array()?
BoShurik
22.05.2015 21:18-5Подсветка. Не заметно, один параметр передается в функцию или несколько.
$this->someMethod($foo, $bar);
$this->someMethod([$foo, $bar]);
$this->someMethod(array($foo, $bar));
smarteq
23.05.2015 12:23Я не сказал что у array() есть преимущества. Мне действительно интересно, может я чего-то не знаю.
gonzazoid
23.05.2015 15:55+3не обращайте внимания, это для товарищей, которые под программированием подразумевают 8-ми часовое ежедневное печатание на клавиатуре.
Blumfontein
23.05.2015 16:35Отсутствие преимуществ уже есть недостаток. Ну и потом, именование массива тоже может попасть под код-стайлы, у вашего array() шансов никаких против [] в этом случае.
maximw
23.05.2015 18:09-1Преимущества array() — поддержка большим числом версий PHP, включая все еще распространную версию 5.3.
Например, если вы делаете приложение, предполагающее установку на серверах клиентов, то лучше иметь в требованиях инсталляции как можно более широкий диапазон версий.Blumfontein
23.05.2015 18:35+2Вы были бы безусловно правы, если бы различия между 5.3 и 5.6 на array() и заканчивались. Но так как это не так, то это не очень-то и преимущество.
Fesor
24.05.2015 20:06php5.3 увы больше не поддерживается, да и суппорт 5.4 скоро дропнут. Лучше стимулировать спрос хостингов с более новыми версиями php.
p.s. Лично я не пользуюсь услугами шаредов, как по мне VDS намного лучше и удобнее.
SerafimArts
24.05.2015 21:04Как пользователь шаредов хочу добавить, что даже отечественные второсортные хостинги уже давно имеют на борту хоть и не 5.6, но 5.5 точно. Так что «популярные 5.3» — это лишь отговорка. А если и нет, то стоит побыстрее бежать оттуда, всё же «фиксы безопасности», коих нет в 5.3 (и скоро не будет в 5.4) — это не пустой звук.
forgotten
22.05.2015 20:14+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 в качестве основного хранилища реляционных по своей природе данных.
Отличный пример двоемыслия в одном абзаце. «Исходя из бизнес-требований к приложению», но «прекрасно знаете» и «смеётесь над идеей». Оооок.
> Много вкусного мяса! «Мням-мням-мням» — слышите, как щелкают челюсти ваших конкурентов? Сожрут-с, однако.
Я не стал считать свои баллы. Подожду, пока меня сожрут.SerafimArts
22.05.2015 20:47+28Помимо приватных ключиков я бы ещё вытащил из гита продакшн конфиги и вендорные папочки, плюс всякие бинарники (например редис, тарантул, сфинкс, которые бывают хранятся локально вместе с проектом), плюс конфиги иде (.idea, .iml, etc.) тоже не стоит отправлять в гит. Всякий кеш тоже однозначно в игнор, включая tmp папочку с сессиями.
Этот список можно продолжать ещё долго, но результат один — автору статьи стоит вычесть у себя 5 баллов. =)hell0w0rd
23.05.2015 00:06-4на счет .idea я бы поспорил. .idea/workspace.xml стоит игнорить, а все остальные настройки скорее всего понадобятся и остальным разработчикам.
SerafimArts
23.05.2015 00:39Вполне возможно, только там зархардкожены пути так, что проще перенастроить, начиная с Command Line Tools плагина, заканчивая композером и старт-командами. Полезную информацию можно выдрать разве что о каталогах (что скрыто, что ресурсы, что сырцы, что ещё что-либо).
Больше я не представляю чего там полезного может быть, что прописано не в виде абсолютного пути.
mickvav
23.05.2015 14:18Не, продакшн-конфиги должны лежать в отдельном git-е.
foxmuldercp
23.05.2015 16:01+2в принципе конфиги должны лежать в отдельной репе + какой нить ансибл/шеф для развертывания дев/продакшен нод, как и конфигов из гита нужных.
На сложных проектах быстро получить прод/дев окружение на физике или виртуалке достаточно сложно — слишком много иногда зависимостей — сервер бд, редис, кафки, кассандры, а развернуть какойнить pyenv с тремя разными версиями питона потому что кусок купленного сто лет назад продукта — легаси еще вполне живет на питон 2.6, и будет жить еще с полгода пока пилится next-gen version приложения.
AlexLeonov Автор
22.05.2015 22:15-19Как известно, нет более рьяных фанатиков, нежели новообращённые.
Если вы это в мой адрес, Вы слегка ошиблись. Я первый коммит кода, написанного на PHP, сделал лет 10 назад, еще на PHP 4.
А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)forgotten
22.05.2015 22:21+13> А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)
Разве я пишу на Хабр статьи про то, что всё должно быть в гите?AlexLeonov Автор
22.05.2015 22:25-1Разве Вам кто-то запрещает?
Во-первых это всё-таки пятничный пост. Во-вторых, поверьте, всё-таки проще сначала ввести общее правило, а уже потом добавлять к нему исключения, нежели пойти обратным путём.
Общее правило — «Всё в гите». Правило вводится в теории, но не ввести его нельзя.
Удачно подмеченные Вами исключения — это служебные файлы IDE, приватные ключи (собственно, а кому пришла такая идея в голову?), пароли в открытом виде, папка vendor (это бессмысленно, достаточно хранить composer.json, всё равно при сборке всё будет тянуться заново), папки ресурсов и прочее, что в .gitignore и так далее. Исключения постигаются на практике.
Не вижу противоречия между шуточно-серьёзным тестом и вашим комментарием. Они прекрасно дополняют друг друга, за что мы и любим Хабр.SerafimArts
22.05.2015 23:07Желательно помимо composer.json таскать composer.lock, даже не желательно, а более чем рекомендательно. И ставить всё через composer install.
AlexLeonov Автор
22.05.2015 23:19Тоже верно. Впрочем, на тестовых стендах можно и composer update запустить. Лишним не будет.
Blumfontein
23.05.2015 11:23+5На тестовых нельзя. Только на девовских. Тестовые стенды должны быть идентичны продакшену.
symbix
23.05.2015 11:30+1А еще лучше делать composer install на билд-машине, а на серверы притаскивать готовый tarball со всеми зависимостями.
Composer install на продакшене допустимым считаю, только если поднят свой packagist, и все зависимости лежат на своем сервере. Иначе может и github прилечь, и packagist — всякое случается (вон, недавно китайцы github ддосили), такие вещи не должны останавливать деплой.
Fesor
24.05.2015 20:08Приватные ключи разработчиков не должны быть в гите, например.
ну я к примеру храню их в git (зашифрованными в gpg), и доступ к содержимому архива есть только у меня. На каждый сервер генерируется свой ключ и что бы не потерять оный, и легко было заменить, лучше хранить в git. По поводу приватных штук (креды к внешним api и т.д.) — так же есть варианты, в зависимости от того что используется для деплоймента.
Makcym
22.05.2015 20:31+56Вы копаете ямы обычной лопатой, а не лопатой с супер черенком 7.0?
Вы используете лопату нажимая ногой, а не втыкая с разворота?
Вы не используете в работе 2-3 инновационные лопаты одновременно?
Вы не делаете тестовых ям, чтобы потом накатить на основную яму?
У вас все еще нет автоматических тестов устойчивости для вашей ямы?
Вы обречены… другие ямы поглотят вас!
sferrka
22.05.2015 20:38+3Интересно было бы увидеть список успешных бизнесов, победивших конкурентов за счет немамонтовости в разработке.
Fesor
24.05.2015 20:12+2победивших конкурентов за счет немамонтовости в разработке.
немамонтовость разработки дает несколько другие вещи:
— предсказуемость (git-flow, continuous delivery)
— уменьшение затрат на поддержку (популярные готовые решения, пусть они и не идеальны, всегда лучше чем самописный велосипед)
— уменьшение затрат на изменение/внедрение нового функионала
Все это позволяет более гибко упровлять релизами и добавлять плюшки, доставлять пользователям больше ценности и за счет этого уже побеждать. На и да, можно просто жахнуть денег в маркетинг.sferrka
24.05.2015 22:07Вопрос немного в другом, стоит ли гнаться за всеми немамонтовыми фишками, новыми версиями языков и т.д. Ведь это деньги на переобучение, перестроение процессов или найм людей. Ведь с другой стороны, старые бизнес-процессы разработки тоже работали. Т.е. для крупных компаний окупаемость в несколько лет имеет смысл (или нет?), но всем поголовно?
Вот и хотелось бы увидеть сравнение нескольких компаний с конкурентами, ключевым фактором победы у которых было бы следование всем новым лучшим практикам.Fesor
24.05.2015 22:52Ведь это деньги на переобучение
Деньги на переобучение — возможно, как долгосрочная инвестиция, но проще найти новых разработчиков если все так уж плохо. Здравый смысл никто не отменял, нужно менять все постепенно. Обычно вводится одна плюшка, которая тянет за собой другую, потом третью. continuous improvement и все такое.
Darksynx
22.05.2015 20:55+3«Неважно какой фреймворк вы используете, простейший механизм миграций в состоянии написать даже Junior за пару часов.»
1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?
2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?
3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.AlexLeonov Автор
22.05.2015 22:17Есть ровно два подхода.
1. Вы запрещаете откат такой миграции (что сводит на нет всю систему миграций, как истории изменений)
2. Вы не запрещаете откат, но он не производит никаких действий.
Третий вариант, когда откат поднимает прежние данные из бэкапа, не имеет смысла на боевой базе и может применяться разве что для отладки.
powerman
23.05.2015 18:48+1- Нет, не сводит на нет. Лучше иметь возможность отката для большинства миграций, чем вообще её не иметь.
- Отличный способ получить напрочь сломанный проект в результате отката.
- Восстановление из бэкапа не так страшно для продакшна, как Вы расписываете. Во-первых бэкап нужно делать автоматически перед миграцией на новую версию. Таким образом, если с новой версией обнаружатся проблемы, то скорее всего это случится в течении минут, максимум часов после обновления, и восстановление из бэкапа приведёт к потере минимума данных. Во-вторых если только это не реально большой проект с HA и избыточными серверами то он в любом случае будет восстанавливаться из бэкапов если умрёт винт. Так что если это будет происходить не раз в 3-5 лет, а раз в год-два из-за ошибок девелоперов при выкатывании новой версии — никакой трагедии в этом нет.
neolink
23.05.2015 19:24+1> Во-первых бэкап нужно делать автоматически перед миграцией на новую версию
ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.
> и восстановление из бэкапа приведёт к потере минимума данных
вот честно я не знаю примера реальной продакшен базы кроме логов которые можно похерить не то что за часы, а даже за минуты
powerman
23.05.2015 19:42он будет сутки делаться и пока он будет делать там ещё данных набежит
Ну дык бэкапы тоже нужно правильно делать.
Данные нужно организовывать так, чтобы те таблицы, которые реально большие и которые полностью бэкапить слишком долго, были инкрементальными — т.е. чтобы в них делался только INSERT, без UPDATE/REPLACE/DELETE (на самом деле DELETE тоже можно для компактификации, но это делается отдельно). Это позволит сделать полный бэкап только для небольших таблиц, а для больших сделать инкрементальный бэкап только новых записей (более того, если эта миграция не будет делать ALTER этим большим таблицам то можно вообще просто запомнить id последней строки и реально бэкапить интервал нужных строк этих таблиц уже после завершения миграции на новую версию).
При таком подходе бэкап большинства даже весьма крупных проектов будет занимать секунды.neolink
23.05.2015 19:56эм, а вы такой инкрементальный бекап сами настраивали? и если вдруг да, то восстановится потом пробовали?
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.powerman
23.05.2015 21:07Не только настраивал и использовал в продакшне годами, есть готовый фреймворк Narada для разработки и деплоя таких проектов — с поддержкой бэкапов, миграций, etc… Он сам написан на Perl+sh (устанавливается как обычный Perl-модуль), но разрабатывать проекты используя этот фреймворк можно на любом языке.
powerman
23.05.2015 21:23+1это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят
Нет, дело не в кейсе и не в данных, а в способе их организации. Это аналогично тому, что для удобства тестирования требуется немного иначе писать код — в данном случае для удобства бэкапов требуется немного иначе работать с данными.
Типичный приём — колонки в таблице A, которые содержат большие объёмы данных (текстовый контент, json, блобы) выносятся в отдельную инкрементальную таблицу B, а в таблице A эти колонки заменяются колонками с id записей в таблице B. Это позволяет значительно уменьшить размер таблицы A и ускорить её (полный) бэкап. Любое изменение данных вынесенных в таблицу B реализуется добавлением новой записи в таблицу B и изменением её id в таблице A. Для уменьшения размера базы можно периодически удалять все записи в B на которые больше нет ссылок в A и делать полный бэкап B.
Это несколько усложняет код и добавляет лишний (но очень быстрый т.к. работает по primary key) JOIN в некоторые запросы, но зато даёт возможность бэкапить проект в течении пары секунд. Что в свою очередь даёт возможность блокировать проект на время бэкапа фактически незаметным для пользователей образом (задержка ответа на пару секунд мало заметна). Что даёт возможность атомарно делать консистентные бэкапы включающие файлы/логи/настройки/базы проекта. Плюс такие блокировки дают возможность так же атомарно обновлять проект. В общем, если взвесить все недостатки и преимущества такого подхода незначительное усложнение при работе с некоторыми колонками в базе оказывается вполне приемлемым.
AlexLeonov Автор
23.05.2015 19:33+1из-за ошибок девелоперов при выкатывании новой версии
Это невозможно при грамотно построенном воркфлоу. Например в моем текущем случае без визы QA и человека от бизнеса на препродакшне никакая выкатка на прод невозможна физически. И более того — девелоперы вообще не имеют доступа к процессам деплоя.
Задача проходит три стенда — изолированный, интеграционный и предпродакшн. Во всех случаях деплой полностью автоматический и ручное вмешательство крайне нежелательно. Право же нажать кнопочку Run на продакшне есть только у специально обученного человека, а сама кнопка не появится без получения двух виз, о которых я говорил выше.powerman
23.05.2015 19:49+1Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн. И в этом случае количество виз и специально обученные люди которые имеют право на выкатывание — хоть и уменьшают вероятность ошибки, но не сводят её к нулю.
Ну и кстати опыт показывает, что когда деплой делается несколько раз в день (разумеется, автоматизированно!), пусть даже по инициативе одного девелопера, это ведёт к меньшему количеству ошибок, чем когда он делается редко (т.е. с большим количеством изменений) но с участием виз и специально обученных людей.AlexLeonov Автор
23.05.2015 20:54Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн
Так ровно на это пост и намекает. Зачем держать код задачи в отдельной ветке? Зачем писать сценарии сборки? Для того, чтобы отдельно тестировать!
Поверьте, для этого есть очень дешевые (и по деньгам и по времени) технологии и приёмы. Те, кто их не применяет — те сами себе злобные буратины и мамонты.
Ну и кстати опыт показывает, что когда деплой делается несколько раз в день… это ведёт к меньшему количеству ошибок, чем когда он делается редко
Подписываюсь. За исключением возможности девелоперу инициировать выкладку. Для меня это звучит абсолютным абсурдом.
ilyaplot
22.05.2015 21:30со всеми пунктами согласен, но почему PHPStorm? Чем netbeans не угодил? Или просто скажите мне, что не может netbeans по сравнению со штормом и я скажу как это сделать.
SerafimArts
23.05.2015 00:46+7Вызов принят!
1) Простенькое: Множественное выделение кода
2) Средненькое: Переименовывание класса, включая все зависимости от него
3) Чуть посложнее: Поиск по классам, так, например «So\An» найдёт класс «namespace Some; class Any» из всех сырцов (исключая скрытые)
4) Ещё более круто: Анализ composer.json с указанием установленной версии зависимости (из lock файла) прямо в коде composer.json?
5) Вообще верх крутости: Интеллектуальный поиск с автодополнением по Dependency Injection контейнерам, включая анализ аннотаций
nogoody
24.05.2015 17:19расскажите про пятый пункт поподробнее, потому как DI контейнер только по аннотациям работает, сам PhpStorm конфиги не понимает. Вы каким-то плагино пользуетесь? В рамках какого-то фреймворка?
SerafimArts
24.05.2015 18:15Не только с аннотациями, можно же ещё напрямую вытаскивать, например так: Container::get(Some::class)->…
Плагин, если не путаю — Symfony2 Plugin этим занимается. Совместим с Laravel (4,5), PHP-DI и наверняка с какими-нибудь плюшками симфони (доктриной, например).
marapper
26.05.2015 10:29PHP Annotations + Symfony Plugin (при открытии или в проекте надо выбрать фреймворк) + Symfony Clickable Views
stardust_kid
24.05.2015 14:04+2А еще в netbeans не завезли нормальный интерфейс (имхо), и он жутко тормозит (объективно, сравнивал на одной машине).
ctacka
22.05.2015 21:32+11Взгляд неандертальца. :-)
Мамонтов вы, конечно, сожрете, но совсем недалеко стоянка кроманьонцев с docker, heroku, devops, lean-kanban и macbook-ом с красивыми наклеечками.iborzenkov
22.05.2015 22:22-17docker на макбуке с наклеечкой превращается в VirtualBox, хотя конечно если снести предустановленную фигню на макбуке и поставить операционную систему
AlexWinner
22.05.2015 23:57+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
Извините, накипело.AlexLeonov Автор
23.05.2015 00:02+2Сейчас приходится
Под дулом пистолета приходится?
Если вы понимаете, почему плохо то, о чём пишете — почему Вас нет на HH?AlexWinner
23.05.2015 01:21+1А за что вам минус поставили? Оо
Просто работаю в другой стране с маленьким выбором вакансий, комментарием ниже подробнее написал.
ctacka
23.05.2015 00:12+2Присоединяюсь к вышевысказавшемуся.
Копошась (другого слова не подберу) в таких вот условиях, вы теряете время и отстаете от современных технологий. Если нет каких-то особенных связей с текущим местом (угроза расправы, з/п намного выше рынка, единственный работодатель в окрестностях, обет), то надо уходить. Хорошего опыта вы там не получите, о новых подходах не узнаете, потеряете инициативность и просто деградируете как специалист.
Не нужно, думаю, объяснять, что современный прикладной программист — это не только технологии непосредственно программирования, но и современный тулстэк, методологии работы с задачами и заказчиками и т.п.
Тем более с вакансиями положение неплохое.AlexWinner
23.05.2015 00:59+4Как раз есть особенные связи. Работаю системным администратором в Колумбии (которая не штат, а страна), тут всё тяжело в IT. А на этом месте работы и зарплата выше рыночной, и такую работу, где могут организовать визу, проблемно найти. В принципе, постепенно всё и тут двигается, стараюсь, внедряю и оптимизирую что могу. Но разруха — она в головах.
Зато остаётся время на фриланс и свои проекты, где всё более радужно:)
AlexLeonov Автор
23.05.2015 00:26-1Нужны интересные вакансии (современный PHP, современные средства разработки, не сайтики) — стучитесь в личку. Думаю, договоримся.
jonic
22.05.2015 22:02Давайте лучше приколимся результатами, у меня 115 набралось ) больше из за git и велосипеда с deploy
Lexx918
22.05.2015 22:03+16Молодые мамонтята читают такие посты, подрастают и потом мы видим кучу бесполезного УГ, но с очень правильным и красивым бэкэндом. Странно что не упомянули о какой-нибудь модной методологии типа аджайла. Наверное, после постов типа «почему аджайл не работает» это уже не так модно? Видимо, надо написать ещё десяток статей а-ля «почему мой проект плох, ведь я хранил весь код в гите» или «почему товар в моём магазине не покупают, ведь его сайт написан на php версии over 9000».
edogs
22.05.2015 22:04+4Автор случаем не перепутал в тесте слова «знаете» и «используете»?
Знать все это перечисленное барахло — надо, использовать — только при необходимости.
Прошедшие тест люди нас будут изрядно пугать, потому что у них тупо отсутствует гибкость.
Основное качество адекватного разработчика.
Вброс с phpstorm особенно доставил, zend studio что, никто не использует из модных ребят?SerafimArts
23.05.2015 00:52Пробовал разок Zend. Заткнулся на попытке создать проект из существующей папки, так до сих пор и висит одиноко ярлычок, даже опробовать не получилось. Готов с удовольствием выслушать как это сделать, попробовать то хочется, можно даже в личке, дабы не оффтопить.
edogs
23.05.2015 02:10Честно говоря, не поняли даже в чем именно у Вас затык.
Проект создается по старому принципу «создать проект — далее — далее — готово»:)
Правда у нас 8-ка, обновляться жаба душит, а ее вполне хватает.
Зенд не очень добр к ресурсам (тут да, жесть, при чем издревле, видимо из-за явы), поэтому перешли на него только с 8 версии (когда обзавелись достойным железом, до этого использовали nushpere phped), но на сейчас никаких проблем не испытываем.
p.s.: Если есть вопросы — пишите в личку, чем сможем поможем, но скорость не обещаем. Или можно на почту. admin@наш_ник_здесь.ru
Ugputu
22.05.2015 22:11+4Я вот несколько лет назад на DEVConf слушал выступление одного мальчика, который что-то там придумал со своими друзьями, а потом встал мужичек в зале и сказал примерно следующее — «Пока вы делали все по правилам и стандартам, писали доки и комментили код фирма [какая-то-фирма] выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим». Так вот если у вас команда, есть готовый продукт и вы делаете рефакторинг для того чтобы клиенты не падали в обморок, то да, всё что писал ТС верно, но если вы реализуете идею то можно и спагетти-код и ничего в этом нет плохого.
Darksynx
22.05.2015 23:13+4Такая проблема чаще всего возникает из-за того, что разработчики сосредоточены на «красоте» проекта. Код ради кода, а не ради бизнеса. Насколько я понимаю, то «мамонт» в посте — это опытный разработчик, который не использует новые инструменты. Думаю, что у опытного разработчика, который использует эти инструменты и подходы, время на выполнение проекта не сильно увеличится. Я бы даже сказал, что многие инструменты больше помогают в дальнейшей поддержке проекта. Проблемы будут лишь у тех, кто про эти вещи узнал, но не правильно их применил. Так что эта история больше относится к людям, принимающим неоправданные решения с точки зрения бизнеса (обычно это лиды и ПМы).
AlexLeonov Автор
22.05.2015 23:15+1время на выполнение проекта не сильно увеличится
Позвольте уточнить — оно радикально сократится. Хороший инструмент это тот, который снижает себестоимость (то есть уменьшает затраченное время). Поверьте, всё, что я перечислил в пятничном тесте, работает на снижение себестоимости. Если правильно применять.Darksynx
22.05.2015 23:24+2Опять-таки надо разделять время на создание проекта и его дальнейшую поддержку. Часто решения «в лоб» по скорости разработки с нуля не сильно уступают некоторым подходам, которые вы описали. Зато на этапе поддержки (изменения функциональности) это может вылится в дикие трудозатраты и бессоные ночи(не всегда, но зачастую).
Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
bolk
23.05.2015 09:56+1Хорошая стратегия — говнокод > рефакторинг > поддержка. Говнокод позволяет быстро запуститься и, если проект оказался востребованным, можно уже рефакторить, чтобы дальнейшая поддержка не превратилась в ад.
guai
24.05.2015 18:08Это как так? Сначала запиливаем продукт, типа всё закончили, начали продавать, но без поддержки, мотивируя тем, что нам надо порефакторить, а вы тут пока как-нибудь сами? И кто его купит? Чаще всего платят именно за саппорт, голый код никому не сдался.
bolk
24.05.2015 20:42Почему без поддержки? О чём вы?
guai
24.05.2015 21:00у вас поддержка в конце цепочки. вот мне и стало интересно, а отдаём клиентам-то когда, до или после рефакторинга?
если до, то нафига им такое надо (говнокод да еще без поддержки)?
если после, то в чем принципиальное отличие от написания сразу нормального кода? в чем выгода стадии говнокода?Fesor
24.05.2015 21:47до или после рефакторинга?
Рефакторинг должен происходить в период разработки, по чуть чуть и часто. Тогда появление страшного легаси будет сведено к минимуму (совсем без него наверное никак, но это не должна быть вся система). Это конечно при условии что вам удалось объяснить руководству, ну или руководство само в курсе, что такое технический долг.
То есть типичный флоу — сделали фичу (максимально простая реализация если это возможно), порефакторили если видите необходимость (дублирование логики например) или хотя бы пометили что какие-то решения были приняты в угоду скорости разработки и помечаются как технический долг. Далее при разработке фич, как-то относящихся к проблемным местам, можно рефакторить, уменьшать технический долг. Некоторые закладывают определенный процент тасков связанных именно с техническим долгом на итерацию (например 80%-90% времени на разработку фич, и остаток на устранение технического долга, зависит от масштабов трагедии и необходимости.) Какие-то сложные вещи могут идти как отдельные таски и приоритизировать (например костыль который влияет на производительность, или еще чего).guai
24.05.2015 22:04ну то есть говнокод в продакшен мы не пускаем. а тогда зачем делать говнокод+рефакторинг — вот этого я не понимаю. не проще сразу сделать нормально, но по минимуму для реализации требуемых фич? отдали набор фич в продакшен, тут клиент захотел новую фичу, похожую на имеющуюся. вот тут самое место рефакторингу, чтобы значит не копипастить, а подвести под обе фичи единую основу.
Либо не делать рефакторинг, тогда со временем получится либо кривой продукт, либо прототип, который только выбросить можно. Но обычно никто так не делает, поэтому имхо лучше сразу писать нормально
позволять себе говнокодить — не вижу, когда бы такая стратегия приносила профитFesor
24.05.2015 23:05ну то есть говнокод в продакшен мы не пускаем
Почему? Пускаем конечно, если этот говнокод выполняет свою работу. Конечно есть еще разница что именно вы понимаете под говнокодом.
не проще сразу сделать нормально
Ну если у вас сразу выходит нормально, и при том так, что в течении полугода все ваши решения были идеальны — то круто и славно. Но я не верю что такие люди существуют. В большинстве случаев ретроспектива решает как надо было делать правильно.
отдали набор фич в продакшен, тут клиент захотел новую фичу, похожую на имеющуюся. вот тут самое место рефакторингу, чтобы значит не копипастить, а подвести под обе фичи единую основу.
Именно так. Тут есть нюансы, рефакторить нужно часто и маленькими этапами, и фичи дробить надо на как можно более маленькие.
позволять себе говнокодить — не вижу, когда бы такая стратегия приносила профит
Что для вас говнокодить? Если код, как бы он не пах, покрыт тестами и удовлетворяет всем функциональным и нефункциональным требованиям, ну и он изолирован, то я не думаю что это плохой код и ему не место на продакшене. Иногда приходится идти на компромисы в угоду бизнесу. Все относительно конечно, но обычно страшные и пахнущие вещи сложно покрыть тестами.
А вот без тестов постоянный рефакторинг штука болезненная, и тогда ее откладывают уже по понятным причинам. Никто не хочет делать полное регрессионное тестирование на каждый чих.
symbix
23.05.2015 10:14+3Зависит от размера проекта. Если для запуска достаточно пары ночей хакатона — да, наговнокодить уместно. Если же речь идет о неделях, хорошие практики только ускорят разработку — при условии, что уровень команды достаточно высокий.
Kroid
24.05.2015 10:54+2«Хоть вы и говнокодите, не пишете доки и не комментите код, фирма [какая-то-фирма] уже выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим».
Не всякий проект может позволить себе быть написанным говнокодерами. Не всегда выйти на рынок первым — значит победить. Не нужно делить мир лишь на черное и белое, как автор этого поста — «Всё в гит! Конфиги в гит! Или тебя съедят!»
ganjar
22.05.2015 23:02+2А как же phpUnit и функциональные тесты?
AlexLeonov Автор
22.05.2015 23:05-2Я вполне допускаю ситуацию, когда в реальном производстве именно юнит-тесты приходится писать крайне редко. Тестами покрыты библиотеки и ваш фреймворк — этого вполне достаточно в реальности.
А функциональные тесты пишет QA-инженер и его команда.
Впрочем, возможно, я слишком долго занимаюсь построением индустриальных команд разработки и идеализирую. Сорри.
SDSWanderer
22.05.2015 23:06> PHPStorm?
Спор насчет редакторов и\или ide переживет еще не одного грозного питекантропа.
И да, только ископаемые моллюски пишут исключительно на одном на php (или любом другом языке). Тем более используя php-специфичную ide. Почему использовать несколько разных ide плохо, объяснять я надеюсь не нужно.AlexLeonov Автор
22.05.2015 23:09+1php-специфичную ide
Шторм не специфичен к PHP.
В остальном Вы, разумеется, совершенно правы.Darksynx
22.05.2015 23:19-1WebStorm — не специфичен, а вот PhpStorm всё же чётко заточен под веб-разработку на PHP, а не на питоне, например.
Я бы ещё добавил, что пишут и могут писать — разные вещи. Практически для всех задач, которые мне приходится решать (в т.ч. и консольные приложения не для веба), php подходит отлично, чем я и пользуюсь. Но это не значит, что я не умею писать на других языках и не умею пользоваться другими IDE.AlexLeonov Автор
22.05.2015 23:21PhpStorm всё же чётко заточен под веб-разработку на PHP
Гм. Прекрасно пишу в нем на HTML, CSS, XML, YAML, JS, SQL… Что я делаю не так?Darksynx
22.05.2015 23:27-1Ну давайте всё же разделять язык программирования и среду для работы с ним, с языком разметки. Языки разметки, которые вы перечислили, успешно можно редактировать и в Java специфичных IDE, .NET и т.д. SQL так же достаточно универсальный язык запросов, который в том или ином виде поддерживается разными СУБД, а так же используется другими языками программирования.
AlexLeonov Автор
22.05.2015 23:33Соглашусь с комментарием.
Но не с высказыванием, что Шторм только для PHP.Darksynx
22.05.2015 23:37Для IDE веб-разработка на PHP не исключает работы с тем, что вы перечислили, но требует специфичной заточки под него. И, заметьте, я не писал «только» :)
AlexLeonov Автор
22.05.2015 23:38Шторм — это IDEA с плагином PHP. Если Вы это считаете «заточкой», можно на этом закончить спор.
Darksynx
22.05.2015 23:47Большая часть IDE которые я знаю и использовал работают по той же схеме — основа + плагин. Спорить не буду, просто расскажите, пожалуйста, что же такое «заточка» в вашем понимании?
AlexLeonov Автор
22.05.2015 23:53Это Вы ввели термин. Вам и рассказывать )))
Для меня фактически нет разницы между Штормом и той же IntelliJ IDEA в версии для Java (грешен, Java FX иногда балуюсь). Ну ОК, пара специфичных пунктов в меню разве что.
Поэтому я и удивился Вашим комментариям.Darksynx
23.05.2015 00:07Ок. Всё просто. Пример со стормом:
Есть WebStorm, который подойдёт для тех вещей, которые вы описали чуть выше, более чем. PhpStorm идёт с удобной работой с xdebug, phpunit, symfony, laravel, навигацией по классам, выбора различных версий интерпретатора для разных профилей тестов и ещё приличным количеством вещей, которые для разработки не на PHP вообще не нужны — это то, что я называю заточкой среды разработки под язык программирования. Брать PhpStorm не для работы с PHP — не вижу смысла впринципе ни по цене, ни по функциональности. Стоимость первого — $100, а второго $200.
Таким образом заточенной средой разработки под язык программирования можно назвать ту среду, основная задача которой упрощать работу с конкретным языком и его окружением.
Просто если вы не согласны с тем, что «Шторм только для PHP», в первую очередь уточните какой именно из вышеперечисленных стормов. А то получается, что мы можем говорить про разные вещи.AlexLeonov Автор
23.05.2015 00:10Стоимость первого — $100, а второго $200.
Уже 200? Нифига себе, я отстал от жизни…
noder
23.05.2015 00:33+1Отлично разрабатываю на node.js в PhpStorm. При чём использую не просто как редактор. Проект на годе полностью поддерживается в этом IDE.
noder
23.05.2015 00:36+1Отлично разрабатываю на node.js в PhpStorm. При чём использую не просто как редактор. Проект на ноде полностью поддерживается в этом IDE.
Temirkhan
23.05.2015 04:321. Руководство для охотников на крупную дичь
1.1 Наживка и выманивание дичи на открытую местность
Если вы понимаете, о чем я)
symbix
23.05.2015 08:55+1За PHPStorm + IdeaVim-плагин 15 баллов полагается? :-)
Delphinum
23.05.2015 17:20За Vim + собственные плагины под него и заточка под конкретный проект — сколько балов дадите?
Elfet
23.05.2015 09:53+2Или считаете себя умнее всех и написали свой велосипед для выкладки релизов?
А я вот взял и написал: deployer.org =)
Forx
23.05.2015 11:04+3Расскажите мне, «немамонты», как миграция БД справится с обновлением высоконагруженных серверов? И какую используете вы?
symbix
23.05.2015 12:34+1Прекрасно справляется. Если под «высоконагруженными» имеется ввиду «сделали таблицы на 100500 миллионов записей и надо сделать ALTER TABLE» — это, простите, ССЗБ, партиционировать надо.
Forx
23.05.2015 12:50Да, вопрос был именно про такую ситуацию, большая таблица, требуется добавить поле. Странная логика, партицировать ради того, что бы сделать крайне редко ALTER через миграцию. Просто есть адекватные способы сделать изменение такой таблицы (через создание копии и тригеры).
И, кстати, как именно партицирование спасёт?symbix
23.05.2015 13:34Я не знаю, для чего у вас эта таблица. Но если неочевидна польза от партиционирования, подозреваю, что какие-то логи; а логи стоило бы хранить в чем-то более подходящем, чем ориентированная на OLTP-операции РСУБД: скажем, Cassandra, ElasticSearch и т.п., — в зависимости от того, что потом с этим надо делать.
Кстати, создание копий и триггеров прекрасно делается миграцией, если уж на то пошло.Forx
23.05.2015 13:53Это не совсем логи, в моём случае это координаты.
Спасибо, надо пробоватьDmitryKoterov
23.05.2015 16:02+1Используйте нормальные СУБД, в которых операция добавления/удаления/переименования колонки — легкая и не зависит от числа строк в таблице, а индексы можно навешивать асинхронно, не останавливая работу. (Подсказка: например, на букву П.)
AlexLeonov Автор
23.05.2015 16:04Добавил бы:
— используйте нормальные БД, в которых операции изменения структуры могут быть обёрнуты в транзакции.
Подсказка: это не MySQL
symbix
24.05.2015 07:47+1К сожалению, в базе на букву П большинство операций ALTER TABLE вызывают блокировку ACCESS EXCLUSIVE.
О базе на букву М вообще говорить нечего, там с DDL плохо почти всё. :-)DmitryKoterov
24.05.2015 15:08ACCESS EXCLUSIVE на пару секунд — не такая уж и большая цена в большинстве случаев.
Sega100500
23.05.2015 11:23+6Как же забавляют подобные рассуждения!
Прежде всего надо быть Программистом! И тут мантры в виде используемых инструментов и техник мало чем помогут. Тем более, когда это преподается в виде «используешь — ты крут, не используешь — мамонт — быстро в яму, и закопаем уже его!». Настоящий специалист использует инструменты исходя из своих потребностей, удобства работы и необходимости их применения в решаемой задаче.
Печально, что оценивается не талант программиста, а лишь набор инструментов. Но, как говорится, по одежке (набору используемых инструментов) только встречают, а провожают все же по уму.
Автору сего теста я желаю, чтоб у него прорвало в квартире батарею, канализацию, а на вызов явился сантехник, весь увешанный новомодными инструментами, с умными пространными рассуждениями, но капец какой криворукий, чтобы у него «руки выросли прям из жопы, и даже нифига не золотые».
andrewiWD
23.05.2015 12:13+2Продолжу тему. Работал на проекте с кучей «полезных» инструментов (wordpress, laravel, angularjs, git, jenkins, composer, bower, grunt, phinx, ant, последняя версия php и т.д.). Набор из целого спектра. Следуя логике из теста, работающие над этим проектом получили бы 200 баллов. Но вот не задача, проект не работал как хотелось: стал очень ресурсоёмкий, сложно поддерживался, на любую задачу требовал много человеко-часов, работал на магии и костылях, слабо развивался и в итоге не приносил ожидаемой прибыли.
Я это к тому, что инструменты созданы для человека — когда будет нужно, тогда и воспользуемся. Но никак не наоборот — если есть интсрумент, то его необходимо использовать.
Если у вас есть дрель, это же не означает, что дома нужно прорешетить все стены?sferrka
23.05.2015 12:46Странный набор, это в Wordpress делались вставки Angular-модулей, API к которым обслуживал Laravel? Или как?
andrewiWD
23.05.2015 13:57Именно. Ангулар, как клиентский обработчик (множество форм, форм в формах и т.д.), а Ларавел — АПИ. От вордпресса (в вордпрессе) избавиться не удалось :)
lexxpavlov
23.05.2015 12:42Вы всё правильно сказали. Но пока не придумали хороший способ оценить талант, нет такого теста, который покажет X% «таланта». Поэтому часто приходится заменять тест на «талант» тестом на знание/умение.
armab
23.05.2015 13:12+1Я б еще добавил 2 пункта:
— Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
— Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.
> Вы правильно используете современные системы контроля версий
> * Всё должно быть в git-е
> * Всё — это значит всё! И даже конфиги приложения
Здесь уместно добавить примечание: все, кроме паролей и токенов.DmitryKoterov
23.05.2015 16:06-4В PSR есть одна странность: они не рекомендуют использовать подчерки для приватных и протектед-свойств, что не соответствует, например, стилю кодирования в Zend Framework и еще куче чего:
Method names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.
Это что вообще?AlexLeonov Автор
23.05.2015 16:08+2Это стандарт. Выработанный сообществом.
Мне кажется, что наличие любого стандарта, пусть даже он вызывает вопросы, всё-таки лучше, чем его отсутствие. А Вам?DmitryKoterov
24.05.2015 02:44+2Наличие стандарта, который Не вызывает вопросов, еще лучше.
Давайте разбираться.
1. Вначале были PEAR Coding Standards, еще в PHP4. Авторы — мейнтейнеры php, многие из которых были также авторами pear и pecl-модулей. PEAR используют сотни тысяч, если не миллионы сайтов. Pivate-члены начинаются с подчерка.
2. Потом Zend начал активничать и выпустил Zend Framework и Zend Framework Coding Standards. Авторы — прародители PHP. Zend Framework, кажется, был первым массовым фреймворком для PHP с таким высоким качеством исполнения (до него тоже были фреймворки, но они все были «наколеночными» — поправьте меня, если я ошибаюсь; кстати, сейчас уже, наверное, другие выбились в лидеры). Отдельные модули из Zend Framework используют сотни тысяч сайтов. Private и protected-члены начинаются с подчерка.
3. Есть такой язык, называется python (со змеей в логотипе). Он где-то раз в несколько менее популярен, чем PHP. В нем protected-методы очень жестко начинаются с подчерка, а private — даже с двух (sic!) подчерков. Хотя я, признаться, ни разу не видел в реальном коде двухподчеркнутых членов, но сам механизм языка устроен таким образом, что два подчерка подряд как бы привязывают член к его собственному классу, т.е. получается реально private. Мне кажется, два подчерка — это перебор, но, тем не менее, их даже в язык вшили.
И вот теперь приходит «сообщество», как вы говорите, и почему-то на github-е, а не на официальном сайте php, публикует PSR. Стандат в целом хороший, я сам его придерживаюсь почти во всем, но у меня остаются два вопроса к нему:
1. Почему так обошлись с префиксами-подчерками, отбросив тонну существущего кода, практик и стандартов, применявшихся до этого.
2. Почему на официальном сайте php нет упоминаний PSR (или есть? где?).symbix
24.05.2015 09:52PEAR мертв как раз во многом потому, что прародители PHP забросили усилия сообщества в виде PEAR и стали с нуля делать ZF, качество которого, кстати, поначалу было весьма сомнительным. Но сейчас это все уже не важно — инициативу взяло на себя сообщество «нового поколения», образованное прежде всего вокруг Symfony — и что там на официальном сайте php — уже не имеет значения, эти сообщества очень мало пересекаются. Весь современный тулчейн (за, наверное, единственным исключением в лице PhpUnit) )не имеет никакого отношения к мейнтенерам php, Zend-у и прочей старой гвардии. Меня тот же composer поначалу смущал «переизобретением» PEAR — но сейчас это уже не важно, это стандарт де-факто, а про PEAR помнят только мамонты :-).
Подчерки же придумали во времена PHP4, когда не было private/protected. Современный PSR code style мне как раз нравится приближенностью к Java.
AlexLeonov Автор
24.05.2015 13:06+2Вначале были PEAR Coding Standards, еще в PHP4
Вот и ответ на Ваше недоумение. Язык развивается, стандарты тоже. Естественный и очень правильный процесс.
Почему так обошлись с префиксами-подчерками
Потому что они не нужны.
armab
23.05.2015 16:45Согласен. В любых правилах могут быть исключения.
Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php
Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.
Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
Delphinum
23.05.2015 17:24Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
Может стоит ограничиться «использованием стандарта форматирования кода внутри всей команды»?
Fedot
23.05.2015 18:05Единый стандарт кодирования хорош не только тем что в команде все пишут одинаково. А ещё тем что при необходимости внести изменения в стороннюю библиотеку и сделать пулл реквест, не нужно изменять никакие настройки своей среды разработки или изменять своим привычкам.
Arenim
23.05.2015 20:41+4Как человек, активно использующий `ant` для скриптов сборки истинно говорю вам: поставьте за его использование отрицательный рейтинг (касаемо мира PHP, конечно)
AlexLeonov Автор
23.05.2015 20:56Всегда считал, что Ant и phing — это одно и тоже. Разумеется, применяю phing. А в чем принципиальная разница?
DmitryKoterov
24.05.2015 02:49ИМХО лучший инструмент для «сборки» — это «пришел новый разработчик, создал себе директорию, склонировал исходники — и тут же пошел в браузер, открыл, и у него все сразу же заработало». Т.е. лучший инструмент — отсутствие необходимости в таком инструменте. Этого можно добиться, да (единственное исключение — если вы делаете «коробочный» продук, с дистрибутивом, инсталлятором и т.д., но это относительно редкость).
AlexLeonov Автор
24.05.2015 11:14Какой-то идеальный и нереальный пример. Зачем этого нужно добиваться?
- Склонировал проект
- Набрал в консоли phing
- Открыл браузер и получил полнофункциональную рабочую копию
— вот более реальный вариант, которого мне неоднократно удавалось «добиться». При этом build.xml — самодокументируемый скрипт, он расскажет пытливому разработчику всё о том, как происходит сборка проекта.symbix
24.05.2015 11:44Самый реальный вариант — это запустить vagrant up. :-) Почти любой нетривиальный проект требует определенного нестандартного окружения.
AlexLeonov Автор
24.05.2015 12:22Можете привести пример — что Вы имеете в виду под нестандартным окружением?
symbix
24.05.2015 12:48У меня, скажем, в предыдущем проекте был собственный extension, написанный на php-cpp, в текущем — FDW для postgresql.
AlexLeonov Автор
24.05.2015 12:59Так наверное несложно в скрипте сборки проверить наличие нужного extension? И если нет — остановить, выдать код 1, выслать письмо и смс дев-опсу?
Хотя да, вы правы, в этом случае преднастроенное окружение в виде того же vagrant, безусловно, лучший вариант.symbix
24.05.2015 15:03Проверить-то несложно, но девопс — не эникей, после второго такого случая взвоет и сделает vagrant-сборку. :-)
DmitryKoterov
24.05.2015 15:24Вот vagrant — это совсем другое дело, это не phing. Потому что vagrant создает ВСЕ рабочее окружение с нуля, а phing и другие «сборщики» — только его часть.
DmitryKoterov
24.05.2015 15:22+1Мой аргумент такой: если у вас сразу все работает после клонирования репозитория, то, значит, вы можете и исходники править «на лету» и тут же их обратно пушить в репозиторий. Т.е. репозиторий, исходники и работающий проект — суть одно и то же как бы. Если же у вас репозиторий+исходники — это одно, а файлы рабочего проекта — это другое, то возникают накладные расходы на ту или иную сихронизацию одного с другим.
Или вы имеете в виду, что сборка никогда не трогает исходники (и веб-сервер работает именно с теми же исходниками, которые склонировали из репозитория), а занимается чем-то еще? Можете привести пару конкретных примеров?
grcool
23.05.2015 23:02-1PHPStorm?
Пробовал, не понравилось.
Пишу на Lua и PHP в Komodo Edit.Delphinum
23.05.2015 23:19+4Зря вы. Любое мнение против PHPStorm смертельно в сфере Web-разработки.
Temirkhan
24.05.2015 01:02+1Проблема в том, что любое not «За», воспринимается как else «Против». А шторм — вещь действительно прекрасная. Единственная причина от него отказываться, на мой взгляд, — дело вкуса.
Delphinum
24.05.2015 11:41-1… и страшные лаги на крупных проекта, а так же долгий старт, ну и конечно же необходимость подстраивать код под среду, дабы она могла правильно определять тип переменных и возвращаемых значений, можно еще вспомнить насилующие мизинец комбинации клавишь (ctrl+shift+tab+enter+a) или сложнейшую модель разработки плагиов, разобраться в которой сложнее, чем слетать в космос, а так да, прекрасная среда.
chetzof
24.05.2015 12:19+2Обновите железо, ну или хотя-бы SSD добавьте.
Delphinum
24.05.2015 15:44-1Зачем? Меня мое железо вполне устраивает.
chetzof
24.05.2015 15:47+1Зачем?
страшные лаги на крупных проекта, а так же долгий старт
Delphinum
24.05.2015 15:52+2Ну так я не пользуюсь PHPStorm, меня эти страшные лаги не касаются.
Temirkhan
24.05.2015 16:13+2Мне не нравятся машины. Он потребляют много топлива и необходимо получить лицензию на вождение. Поэтому я пользуюсь велосипедом. Он не такой требовательный, хотя в нем нельзя откинуться на спинку кресла, съездить из одной точки в другую за куда более короткий промежуток времени, перевозить одновременно несколько пассажиров или багаж. Если бы было можно, я бы пользовался просто ногами.
Надеюсь, Вы увидели сарказм и аналогию.
Никто не запрещает Вам пользоваться любой другой IDE или даже блокнотом — дело абсолютно Ваше. Но возмущаться тем, почему ради мощности иногда приходится жертвовать скоростью или ресурсами — это как-то неразумно.Delphinum
24.05.2015 16:18+2Он не такой требовательный, хотя в нем нельзя откинуться на спинку кресла, съездить из одной точки в другую за куда более короткий промежуток времени, перевозить одновременно несколько пассажиров или багаж
А если вам все это не нужно, то?
Но возмущаться тем, почему ради мощности иногда приходится жертвовать скоростью или ресурсами
Что такого мощного в PHPStorm, что он позволяет себе лагать на компьютере, на котором другие среды чуствуют себя хорошо?andrewiWD
27.05.2015 09:49Не скажу насчёт мощного, зато в нем есть ВСЁ, что может потребоваться для разработки на php.
— Браузер \ Restful service
— Управление базами
— FTP, VCS
— Тесты
— Различный диплой
— Консоль
— Поддержка Vagrant, SSH соединений, тунели
— все прелести вашего комодо|sublime|atom|другого текстового редактора
— и т.д. и т.п.
Я не опровергаю наличие других хороших IDE, но тем не менее PhpStorm я счёл лучшим для себя.
AlexLeonov Автор
24.05.2015 12:24+1Внимательно трижды прочёл Ваш комментарий, но не понял, что Вы имели в виду вот этим:
ну и конечно же необходимость подстраивать код под среду, дабы она могла правильно определять тип переменных и возвращаемых значений
О чём речь?Delphinum
24.05.2015 15:44Никогда не сталкивались с тем, что PHPStorm подсвечивает рабочий код как ошибку только потому, что не может распознать тип? Или нет возможности перейти к объявлению метода/класса?
symbix
24.05.2015 16:10+1В 9-ке почти все проблемы, с этим связанные, исправили. WI-12654 только мешает немного, но это редкий кейс.
В любом случае, в остальных IDE всегда было еще хуже.Delphinum
24.05.2015 16:12Что будет, если я сделаю так:
trait MyTrait{ function getInstance(){ return new self; } } class MyClass{ use MyTrait; } $obj = MyClass::getInstance();
PHPStorm определит переменную $obj как объект класса MyClass, или MyTrait?
В любом случае, в остальных IDE всегда было еще хуже.
Я не сравниваю PHPStorm, я говорю о его недостатках.neolink
24.05.2015 16:45ну собственно вот: youtrack.jetbrains.com/issue/WI-17671
можно флеш моб устраивать
а вообще напишите
return new static();
это будет понято правильно + больше соответствует поведению self/static вне трейтовDelphinum
24.05.2015 16:53-2а вообще напишите
return new static();
А какая разница? Все равно PHPStorm не определит тип.neolink
24.05.2015 16:58+1вы думаете я от балды написал, чтоли?
habrastorage.org/files/60e/fbf/722/60efbf722ce048d8a0b6d38a2fcddec4.jpgDelphinum
24.05.2015 16:59-1Нисколько, я вам верю, но то лишь пример, думаю вы сами знаете случаи, когда PHPStorm не может распоздать тип.
neolink
24.05.2015 17:08+1ну честно с типами все очень даже хорошо, например у свойства будет правильный тип:
public $container;
public __construct(ContainerInterface $container) {
$this->container = $container;
}
единственное когда в аннотации написано не всё. то да лишнего он не добавит. Просто в силу природы динамичности php без подсказок тут нельзя
а так большинство моих issue они позакрывали, я где-то с 5 версии уже не сижу активно на их баг-трекере, так что меня в принципе всё устраивает
symbix
24.05.2015 18:31Антипаттернами не увлекаюсь:-), так что не сталкивался — но вообще тут должен помочь хинт return $this. Не идеально, но не вижу ничего страшного написать это 1 раз в трейте.
Arik
25.05.2015 07:23+1Всё — это значит всё! И даже конфиги приложения
Как-то опасно звучит, особенно для тех кто далек от систем контроля версий. По-моему
основной конфиг-файл, который подключает приложение, должно быть в игноре, но рядом должен лежать пример этого файла (без логинов и паролей!!!).
/config.php — в игнор
/config.template.php — пример
А так в пуб репозитарии попадут пароли или долго будут гадать как сделать у себя на машине и на продакшн разные пароли и логины…
Secessus
25.05.2015 12:42Я бы свел статью к
«Все прикручиваете модули к CMS? Откройте для себя Мэтта Зандру и Symfony Book».
Не так категорично и подталкивает людей к (хорошим, добрым, вечным) лучшим практикам.
uaoleg
27.05.2015 12:51+1переносить логику во внешние ключи, триггеры и процедуры
Вот здесь автору 0.
А так отличный чек-лист, спасибо!andrewiWD
28.05.2015 10:07А? Чё? А за что вам минус то влепили? Триггеры и процедуры — зло! Лишь в очень редких случаях их использование может быть оправдано.
Вот кстати на прошлом проекте в базе было более десятка триггеров, без VCS, без миграций и без доков. Как много кайфа я испытал :sarcasm:.
Проблемы которые я увидел:
— Что-то магическим способом происходит, как — хз.
— Вылетает ошибка, мейл об ошибке не отсылается, да и логгер её не видит. Ручками заходим на сервер и идём в логи базы.
— Под Убунтой так и не нашёл GUI для их редактирования. (кто знает — подскажите)
— Об их существовании постоянно забывается. Правится код, правятся модели — но работает не так. WAT?!.. **** Триггеры, точно!uaoleg
28.05.2015 10:11-1К сожалению, минусовавший свои аргументы не озвучил. Логику в триггерах ни тестами не покроешь, ни контроль версий нормальный не сделаешь, ну и про остальные прелести вы уже написали.
gonzazoid
28.05.2015 12:08+1использую plv8 для постгреса в хранимках и триггерах. Есть приблуда для отладки, но мне хватает console log. Тестировать можно как угодно — есть юнит тесты через тестовую ноду (вывод в qunit на клиенте), behavior тестируется также как и везде, там вообще не принципально что на бэке. Контроль версий — через дамп структуры базы в git-e.
На вопрос про редкий случай, где они нужны. Ну не так уж и редко. Быстрый мультапдейт у меня на тригере, журналируемые таблицы тоже, очень удобно — повесил тригер и таблица сама хранит историю своих изменений, не надо это учитывать в сто пятиста местах внесения изменений данных в коде.
Расскажите мне пожалуйста, где я должен начать страдать, а то я себя обделенным чуствую.
p.s. минус не мой был, если что :)uaoleg
28.05.2015 12:17-1Конечно, журналирование — это один из тех кейсов, где триггеры самое оно. Но переносить на них бизнес логику…
Fesor
28.05.2015 12:42Как по мне CQRS + event sourcing поудобнее триггеров будет для задач журналирования. Но опять же есть случае где этот подход не катит. Универсальных решений и абсолютного зла не бывает. Просто если можно обойтись без процедур (а обычно можно) — лучше обойтись без процедур. Это вопрос подходов, выбранных методологий разработки и т.д.
Для процедурок есть свои ниши, связанные с разграничением доступа к данным и бизнес логике. Там другие подходы тоже работают но не так хорошо.gonzazoid
28.05.2015 13:39о, теперь я знаю, как это называется. Делал такой велосипед при реализации аналога 1С регистров. Но есть свои ограничения, для хайлоада не катит.
Fesor
28.05.2015 14:11для хайлоада не катит.
Катит. Единственный случай, когда CQRS не подходит (может и не единственный, но я знаю только об этом), это если наша система должна читать и изменить данные атомарно (пимер — стэк и pop, который за одну операцию считывает элемент в конце массива и удаляет его из оного, если мы разделим на чтение + запись то при конкурентных запросах будет плохо, так как один из запросов на чтение может вернуть не то) то да, CQRS не подходит. Но это не такой уж частый кейс и уж никак он не связан с хайлоадом. А event-sourcing — зависит от реализации. Можно писать лог изменений сначала в память а потом уже в базу, можно еще придумать прикольных штук.
akazakou
31.05.2015 08:03+1Ну а мне пост понравился. Я не адепт всего нового, и давно не тяну первые попавшиеся вещи в проекты, но познакомиться с новыми подходами, и хотя бы просто оценить их жизнеспособность, применительно к своим проектам, никогда не помешает. Вот только бы агрессивности поменьше, а то иногда обидно, когда git-flow тебе не подходит из-за требований заказчика, и тебя из-за этого называют мамонтом. :(
dostelon
Объясните, в чем проблема? Как надо правильно делать?
wtf?
А, просто, папочка Vendor?
Yavanosta
«why should not i use md5 for passwords» > Google
www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored
sayber
Вы вкусный наверное, надо попробовать!
nochkin
Как бы живот не заболел от такого давнишнего мяса.
Fesor
Для md5 легко подобрать коллизию. Лучше использовать bcrypt (хотя уже говорят что и это не ок, и нужно юзать scrypt но и bcrypt для большинства систем достаточно). Ну и можно погуглить почему медленные алгоритмы хэширования паролей лучше в контексте безопасности.
password_hash, причем даже соль не нужно генерить руками, password_hash с этим прекрасно справится и сам. Возможно для некоторых случаев и стоит так делать но я не могу пока придумать зачем.
Вот тут солидарен. PhpStorm няшка, но я знаю массу разработчиков которые перешли на vim, как раз для того что бы умный ide, в котором есть масса удобных штук, не подначивал делать плохо. Ну и да, vim многие настраивают под себя, и есть в принципе неплохие проекты реализующие сервер для автокомплита. VIM это круто. Хотя я еще не дорос… Для меня пока только phpstorm, netbeans и тд.
Не просто. Тут больше акцент внимания стоит выделить на том, что люди понимают зачем нужно использовать готовые решения типичных задач. То есть просто папочка vendor значит что вы используете composer. Круто. Но вот если вы, к примеру, используете какой-то пакет реализующий PSR-7 как слой абстракций над HTTP, то это уже круче.
hMartin
это вы где такое услышали?
Fesor
Под «легко подобрать коллизию» я имею в виду возможность взять GPU и очень очень быстро считать хэши, если сравнивать с медленными bcrypt или scrypt.