PHPStan можно интегрировать с PHPStorm, как это сделать лучше читать документацию к данной IDE. С вс код вероятно тоже есть интеграция, но точно ничего не скажу.
Да, пет-проект это круто, но что делать если увлечен своим проектом на работе (тоже работаю в "МТС Диджитал"), бывает засиживаешься до глубокой ночи или встаешь вместе с петухами и новыми мыслями как реализовать какую-то фичу, подписан на хабр, на несколько телеграмм каналов, читаешь различные статьи по разработке, читаешь книги, НО при этом нет пет-проекта, просто не хватает времени, сил и просто не видишь необходимости т.к. все свои мысли имеешь возможность реализовать на работе. Это значит я не увлеченный человек?
Так на сколько знаю Никите просто нравится Rust и он уже давно контрибьютит и туда. Просто человеку захотелось развития как личности, Rust совсем другие принципы нежели PHP, Java, Go или NodeJS
Первое что приходит в голову, это обработка больших объемов данных, на собеседовании кажется об этом речь и шла, допустим необходимо обработать большую (по объему) таблицу БД имея маленький доступный объем оперативной памяти.
Но я даже не об этом, а о том, что кто то даже не знает что есть в пыхе и плохо понимает что на самом деле в этом языке не так, восхищаясь другими языками не зная что и там есть проблемы.
Как раз про это и говорил, что проблема в людях, а не в языке!
Многие ведь как, когда наслушаются как все круто в другом языке, особенно когда вокруг него много хайпа (Допустим в Java и C# отсутствует множественная наследовательность и сделали это намеренно т.к. с ней много проблем, но она есть в Python вокруг которого много хайпа, в итоге у Дмитрия Стогова спросили «когда будет в PHP множественная наследованность?», на что он четко ответил «Никогда» (слава богу)) столкнувшись с какой то не стандартной задачей начинают думать о другом ЯП.
Пример из жизни — был как то на собеседовании, не помню точный вопрос, но вспомнил про yield и начал рассказывать про генераторы, на что собеседующий сказал «мы сейчас говорим о PHP, а не о Python»! Как Вы думаете, какая была моя реакция и кого винить за незнание ЯП, сам ЯП или человека? Напомню, генераторы появились еще в PHP 5.
Вот и говорю, проблема не в языке, проблема в людях. И людей которые знают только то, с чем работают очень много и не только в PHP, но не надо за это винить ЯП.
Читал как то статью на хабре, где автору не нравится во что превращается PHP.
А я скажу, что прям в точку все попадает, и «Возвращаемый тип static » и "$object::class" и "?->", да и много других вещей, так не хватало в PHP, не раз сталкивался с такой необходимостью, теперь код можно будет писать более чисто, без личшних замудренностей!
Почти каждый обсуждаемый для PHP 8 RFC несет одну и ту же проблему — нарушение ранее сложившейся системы языка. И это плохо. Это ломает мозг и тем, кто пишет на PHP давно, и тем, кто только начинает его изучать.
Мир меняется, мир уже не такой как был в 2004 году! Так в нишу PHP пришел Phyton, а пришол он как раз потому, что PHP долго стоял на месте! Сейчас, если PHP так же и останется в 2004 году, то не долго осталось ждать до его смерти, я в этом убежден!
Далее добавляем понятие «замыкания». …
Замыкание— функция первого класса, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции в окружающем коде и не являющиеся её параметрами. Говоря другим языком, замыкание — функция, которая ссылается на свободные переменные в своей области видимости.
Т.е. это функция с доступными ей переменными из внешнего пространства. В PHP переменные из внешнего пространства в анонимную функцию мы передаем с помощью оператора use, поэтому анонимную функцию и называют замыканием.
А дальше у нас появляются стрелочные функции. И это ломает всё.
Все что сделали, так это убрали use и сделали доступными переменные из внешнего пространства по умолчанию, при этом само внешнее пространство стрелочная функция не меняет.
Где «доллар»? Нет.
Как много ругани я читал про то, что PHP плохой язык именно из за знака $, к константам без знака $ как то привыкли.
это новые match-expressions. Можете объяснить, почему в них используется символ "=>", а не привычный по switch-case ":"? И я не могу.
А разве switch-case удалили или объявили как deprecated? Это просто новая конструкция, если вы не хотите применять новые конструкции, то никто вас и не заставляет.
Ну а далее могу просто сказать — можно меняться в угоду привычкам, а можно меняться в угоду лучших решений. Изменения принимаются путем обсуждения, споров и голосования!
Да, возможно что то лишнее появляется и непонятное, но
Это больше дело привычки, человеку всегда сложно отказываться от старых привычек и завести новые
А может стоит сейчас попробовать как можно больше, посмотреть эффективность тех или иных инструментов, исправить ошибки, а потом вычистить все от хлама? Только ведь пока не попробуешь сложно понять что хлам, а что нет
Статическая типизация — переменная связывается с типом в момент объявления и тип не может быть изменён позже. Динамическая типизация — переменная связывается с типом в момент присваивания значения, а не в момент объявления переменной. Динамическая типизация упрощает написание программ для работы с меняющимся окружением, при работе с данными переменных типов; при этом отсутствие информации о типе на этапе компиляции повышает вероятность ошибок в исполняемых модулях.
Я об этом.
Ну а если глубже капнуть, то да, слабая и сильная типизация.
Это обширный вопрос, но в PHP (как уверен и в других языках с такой типизацией) достаточно много проблем как раз из за динамической типизации, поэтому type hinting и strict_types добавили (как написал выше, язык развивается, кто участвует в его разработке о таких проблемах явно знают и явно стараются их закрыть не повторяя ошибок других ЯП).
Не буду вдаваться в технические подробности почему статическая типизация лучше динамической, а логическая проблема в следующем — легче выстрелить себе в ногу, допустим когда определил переменную как int, далее переопределил её как string, а потом обратился к этой переменной как к int, теоретически это возможно и сделать такое может любой программист (особенно в больших проектах, поэтому в них как правило Java используют, а не PHP), не нарочно. Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.
Здесь дальше можно разговарить о компиляции и о статических анализаторах (котрые я немного упомянул в этой статье, это реально крутая вещь!), но это уже отдельная и большая тема.
Сейчас JS очень популярен, так там проблем еще больше, с ним я дружу и считаю имею право так говорить. Та же проблема с типизацией, даже больше, (TypeScript если только рассматривать как замену), классы появились только в ES6 который еще не везде поддерживается и если не ошибаюсь больше является синтаксическим сахором, т.к. JS это прототипное ООП и т.п. Java — излишне сложен и JVM как правило ресурсоемок, опыт с данным языком так же имеется. Phyton — популярен, та же динамическая типизация, думаю там такие же проблемы присутствуют. Не знаю как сейчас, но раньше если обновляешь ядро OS Linux, то часто phyton просто переставал работать и соответственно приложения написанные на нем просто падали. Golang — крутой язык, но как на нем написать например CRM, которую можно написать на PHP и легко поддерживать, не представляю. C#, Rust, Scala — если не ошибаюсь вообще другая сфера применения нежели у PHP. Конечно и на них можно что то для WEB написать, но стрелять из пушки по воробьям!? Ну а брокеры очередей, базы данных и т.п. пока у меня небыло необходимости писать.
Почему PHP:
1. Я им владею
2. Некоторые вещи реализовывать значительно проще нежели например на Java
3. Язык хорошо развивается
4. Согласно бэнчмаркам php 7.4 уже показывает хорошие результаты, а в конце года ожидается выход php 8
4. Большой выбор уже готовых библиотек и готовых решений проверенных временем.
Поэтому какой язык вы считаете более продвинутым пока непонятно. Думаю просто сказать «используй только этот язык и никогда не используй вот этот» будет не правильно! Но это очень холиварная тема и думаю не стоит продолжать ее здесь обсуждать, просто написал почему я выбираю для некоторых своих проектов PHP.
Да, просто побыстрее хотелось написать про такую возможность, от части на эмоциях была написана статья. Примеров внедрения и как это помогло нашей команде достаточно много, просто надо больше времени уделить написанию статьи и думаю получится достаточно интересно.
Еще раз спасибо, именно такую помощь на хабре и хотел увидеть! Надеюсь я Вас услышал.
PS: Скажу больше, без использования подобных инструментов php слабый язык программирования (хотя я его очень люблю, поэтому и рассказал про такие инструменты), т.к. прощает ошибки, например когда объявил переменную в одном регистре, а при обращении соучайно напутал регистр одного из символов в названии переменнтой, то тебе выдаст что то типа «PHP Notice: Undefined variable:» и код продолжит работать, хотя ты думаешь что обратился к переменной в которой уже есть какое то значение. А эти инструменты позволяют найти подобные ошибки, когда человеческий взгляд может их пропустить.
Решил поделиться инструментами которые на порядок облегчают жизнь программиста и на порядок лучше находят ошибки в коде чем человеческий взгляд (проверено на практике), НО минусов пока больше, наверное ничего не стоят эти инструменты, зачем их только разрабатывают когда есть человеческий, предвзятый и уставший, взгляд. Два человека спасибо сказали, так и их заминусовали. Более того, ведь никто не заставляет вас и никого другого их использовать, а если и захотите использовать, так в любом случае потребуется разобраться со всем этим, здесь только озвучена такая возможность.
Странно.
Спасибо, надеюсь я Вас услышал, просто очень часто слышу, что при code rewiev проверяется как раз единообразие code style, производится поиск синтасических ошибок и т.п.
Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.
Статья наверное больше об этом, об исключении из code rewiev моментов которые можно автоматизировать.
буквально пять минут так было, волнуюсь, извините.
Вот качество материала крайне низкое, только почему то в большинстве команд такое не используется, по крайней мере в проектах PHP которых участвовал приходилось предлагать и внедрять данные инструменты. Хотя не знаю конечно, может это все туфта, все эти инструменты, правда после их внедрения sentry меньше ошибок стало отлавливать.
Данные инструменты можно использовать как в хуках, так и отдельно запускать. Про pre-commit написал только для того, чтобы описать где это все можно удачно использовать, для этого и выделили часть статьи как «Pre-commit review».
Цель статьи дать направление и вкратце рассказать для чего статические анализаторы вообще нужны.
Спасибо за подсказку, людям больше выбора, тоже посмотрю в эту сторону.
PHPStan можно интегрировать с PHPStorm, как это сделать лучше читать документацию к данной IDE. С вс код вероятно тоже есть интеграция, но точно ничего не скажу.
Да, пет-проект это круто, но что делать если увлечен своим проектом на работе (тоже работаю в "МТС Диджитал"), бывает засиживаешься до глубокой ночи или встаешь вместе с петухами и новыми мыслями как реализовать какую-то фичу, подписан на хабр, на несколько телеграмм каналов, читаешь различные статьи по разработке, читаешь книги, НО при этом нет пет-проекта, просто не хватает времени, сил и просто не видишь необходимости т.к. все свои мысли имеешь возможность реализовать на работе. Это значит я не увлеченный человек?
Так на сколько знаю Никите просто нравится Rust и он уже давно контрибьютит и туда. Просто человеку захотелось развития как личности, Rust совсем другие принципы нежели PHP, Java, Go или NodeJS
Но я даже не об этом, а о том, что кто то даже не знает что есть в пыхе и плохо понимает что на самом деле в этом языке не так, восхищаясь другими языками не зная что и там есть проблемы.
Многие ведь как, когда наслушаются как все круто в другом языке, особенно когда вокруг него много хайпа (Допустим в Java и C# отсутствует множественная наследовательность и сделали это намеренно т.к. с ней много проблем, но она есть в Python вокруг которого много хайпа, в итоге у Дмитрия Стогова спросили «когда будет в PHP множественная наследованность?», на что он четко ответил «Никогда» (слава богу)) столкнувшись с какой то не стандартной задачей начинают думать о другом ЯП.
Пример из жизни — был как то на собеседовании, не помню точный вопрос, но вспомнил про yield и начал рассказывать про генераторы, на что собеседующий сказал «мы сейчас говорим о PHP, а не о Python»! Как Вы думаете, какая была моя реакция и кого винить за незнание ЯП, сам ЯП или человека? Напомню, генераторы появились еще в PHP 5.
Вот и говорю, проблема не в языке, проблема в людях. И людей которые знают только то, с чем работают очень много и не только в PHP, но не надо за это винить ЯП.
Проблема не в языке, проблема в людях. Если за 10 лет так и не понял принципы работы ЭВМ, то это не проблема языка.
?
А я скажу, что прям в точку все попадает, и «Возвращаемый тип static » и "$object::class" и "?->", да и много других вещей, так не хватало в PHP, не раз сталкивался с такой необходимостью, теперь код можно будет писать более чисто, без личшних замудренностей!
Мир меняется, мир уже не такой как был в 2004 году! Так в нишу PHP пришел Phyton, а пришол он как раз потому, что PHP долго стоял на месте! Сейчас, если PHP так же и останется в 2004 году, то не долго осталось ждать до его смерти, я в этом убежден!
Замыкание— функция первого класса, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции в окружающем коде и не являющиеся её параметрами. Говоря другим языком, замыкание — функция, которая ссылается на свободные переменные в своей области видимости.
Т.е. это функция с доступными ей переменными из внешнего пространства. В PHP переменные из внешнего пространства в анонимную функцию мы передаем с помощью оператора use, поэтому анонимную функцию и называют замыканием.
Все что сделали, так это убрали use и сделали доступными переменные из внешнего пространства по умолчанию, при этом само внешнее пространство стрелочная функция не меняет.
Как много ругани я читал про то, что PHP плохой язык именно из за знака $, к константам без знака $ как то привыкли.
А разве switch-case удалили или объявили как deprecated? Это просто новая конструкция, если вы не хотите применять новые конструкции, то никто вас и не заставляет.
Ну а далее могу просто сказать — можно меняться в угоду привычкам, а можно меняться в угоду лучших решений. Изменения принимаются путем обсуждения, споров и голосования!
Да, возможно что то лишнее появляется и непонятное, но
Динамическая типизация — переменная связывается с типом в момент присваивания значения, а не в момент объявления переменной. Динамическая типизация упрощает написание программ для работы с меняющимся окружением, при работе с данными переменных типов; при этом отсутствие информации о типе на этапе компиляции повышает вероятность ошибок в исполняемых модулях.
Я об этом.
Ну а если глубже капнуть, то да, слабая и сильная типизация.
Не буду вдаваться в технические подробности почему статическая типизация лучше динамической, а логическая проблема в следующем — легче выстрелить себе в ногу, допустим когда определил переменную как int, далее переопределил её как string, а потом обратился к этой переменной как к int, теоретически это возможно и сделать такое может любой программист (особенно в больших проектах, поэтому в них как правило Java используют, а не PHP), не нарочно. Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.
Здесь дальше можно разговарить о компиляции и о статических анализаторах (котрые я немного упомянул в этой статье, это реально крутая вещь!), но это уже отдельная и большая тема.
Java — излишне сложен и JVM как правило ресурсоемок, опыт с данным языком так же имеется.
Phyton — популярен, та же динамическая типизация, думаю там такие же проблемы присутствуют. Не знаю как сейчас, но раньше если обновляешь ядро OS Linux, то часто phyton просто переставал работать и соответственно приложения написанные на нем просто падали.
Golang — крутой язык, но как на нем написать например CRM, которую можно написать на PHP и легко поддерживать, не представляю.
C#, Rust, Scala — если не ошибаюсь вообще другая сфера применения нежели у PHP. Конечно и на них можно что то для WEB написать, но стрелять из пушки по воробьям!? Ну а брокеры очередей, базы данных и т.п. пока у меня небыло необходимости писать.
Почему PHP:
1. Я им владею
2. Некоторые вещи реализовывать значительно проще нежели например на Java
3. Язык хорошо развивается
4. Согласно бэнчмаркам php 7.4 уже показывает хорошие результаты, а в конце года ожидается выход php 8
4. Большой выбор уже готовых библиотек и готовых решений проверенных временем.
Поэтому какой язык вы считаете более продвинутым пока непонятно. Думаю просто сказать «используй только этот язык и никогда не используй вот этот» будет не правильно! Но это очень холиварная тема и думаю не стоит продолжать ее здесь обсуждать, просто написал почему я выбираю для некоторых своих проектов PHP.
Еще раз спасибо, именно такую помощь на хабре и хотел увидеть! Надеюсь я Вас услышал.
Странно.
Статья наверное больше об этом, об исключении из code rewiev моментов которые можно автоматизировать.
Вот качество материала крайне низкое, только почему то в большинстве команд такое не используется, по крайней мере в проектах PHP которых участвовал приходилось предлагать и внедрять данные инструменты. Хотя не знаю конечно, может это все туфта, все эти инструменты, правда после их внедрения sentry меньше ошибок стало отлавливать.