Комментарии 26
Спасибо!
И где здесь собственно про code review?
Разве это не относится к области code review? Если нет, буду благодарен если поясните его смысл, спасибо!
Вы считаете человек надежнее чем машина выполняет рутиную работу и человеческий взгляд надежнее машинного? Мне всегда казалось машина как раз рутиную работу и предназначена делать и машина лучше может сравнить например написание переменной при ее объявлении и при ее вызове (php к сожалению прощает такие ошибки как разное написание переменной, в итоге при обращении к ней в ней может оказаться совсем не то, что ожидалось)
Т.е. вы считаете данные инструменты никчемные и их вообще надо запретить, все должен делать человек?
И да, кто запрещает использовать человеческий труд? Здесь описаны инструменты которые ПОМОГАЮТ проводить code review, но итог и процесс зависит только от человека.
А всякий автоматический анализ кода — это уже из другой оперы.
Из какой, подскажите? Цель вроде одна и та же.
Из области Хука на пуш коммита в бранч.
Т.е. вы считаете данные инструменты никчемные и их вообще надо запретить, все должен делать человек?
Что-то вас куда-то не туда понесло. Статический анализ – это хорошо, но это не code review. Посмотрите, например, в википедии: сколько там пунктов того, что включает в себя code review, и это совсем не то, что вы описали. Более того:
The above-mentioned definition of code review delimits it against neighboring but separate software quality assurance techniques: In static code analysis the main checking is performed by an automated program, in self checks only the author checks the code, in testing the execution of the code is an integral part, and pair programming is performed continuously during implementation and not as a separate step.
Ну и да, code review – это нифига не просто. Люди пишут огромные статьи на тему того, как правильно проводить review, а оказывается, надо просто настроить линтер и статический анализатор. Это какой-то дилетантизм. За это и минус от меня с причиной "Низкий технический уровень материала".
За это и минус от меня с ...
Спасибо за Ваше мнение! Немного переименовать статью надо. Могу только добавить, что эти инструменты в помощь при code rewiev и они не могут полноценно заменить весь rewiev.
… об инструментах которые помогают проводить code review.
php-cs-fixer правит code style, это не относится к code rewiev?
К code review – нет, к software quality assurance techniques – да. Если у вас человек в ходе code review следит за стилем и единообразием кода – это одно. Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.
А у вас получается как-то так: "Высшая математика – это просто, возьмите калькулятор, чтобы не умножать большие числа вручную – вот и все. Ведь решая задачи вышей математики, нам надо умножать числа..."
Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.
Статья наверное больше об этом, об исключении из code rewiev моментов которые можно автоматизировать.
"Помощь" с мягким знаком пишется, еще и в заголовке такое…
Уровень материала крайне низкий в целом.
Вот качество материала крайне низкое, только почему то в большинстве команд такое не используется, по крайней мере в проектах PHP которых участвовал приходилось предлагать и внедрять данные инструменты. Хотя не знаю конечно, может это все туфта, все эти инструменты, правда после их внедрения sentry меньше ошибок стало отлавливать.
Странно.
Дело не только в информации, но и в том, как ее преподносить.
Как я уже писал, изначально вы представили все так, будто линтер + статический анализатор – это и есть всё code review. Да, заголовок вы потом поправили, но осадочек остался если убрать из статьи воду про упрощение жизни и улучшение качества кода на порядок (очень сомнительно, никаким линтером из плохого кода не сделать хороший), то из полезного остается только раздел "Инструменты помогающие улучшить качество кода". Маловато как-то для полноценной статьи, как по мне: список из 5 инструментов с кратким описанием.
Может, если бы вы описали, как именно это внедрение повлияло на качество кода в вашей команде, привели какие-то данные, показали, как внедрение статического анализатора помогло найти неочевидные баги, да хотя бы описали как настроить и с какими параметрами лучше запускать – возможно, статья получилась бы интереснее, а плюсов было бы больше.
Ну а что касается "Два человека спасибо сказали, так и их заминусовали" – на хабре не приняты мусорные комментарии типа "спасибо", "+1" и т.д. Для этого и есть голосование за статью.
Еще раз спасибо, именно такую помощь на хабре и хотел увидеть! Надеюсь я Вас услышал.
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.
Не буду вдаваться в технические подробности почему статическая типизация лучше динамической, а логическая проблема в следующем — легче выстрелить себе в ногу, допустим когда определил переменную как int, далее переопределил её как string, а потом обратился к этой переменной как к int, теоретически это возможно и сделать такое может любой программист (особенно в больших проектах, поэтому в них как правило Java используют, а не PHP), не нарочно. Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.
Здесь дальше можно разговарить о компиляции и о статических анализаторах (котрые я немного упомянул в этой статье, это реально крутая вещь!), но это уже отдельная и большая тема.
Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.
Вы путаете статическую/динамическую и сильную/слабую типизацию.
Динамическая типизация — переменная связывается с типом в момент присваивания значения, а не в момент объявления переменной. Динамическая типизация упрощает написание программ для работы с меняющимся окружением, при работе с данными переменных типов; при этом отсутствие информации о типе на этапе компиляции повышает вероятность ошибок в исполняемых модулях.
Я об этом.
Ну а если глубже капнуть, то да, слабая и сильная типизация.
Качество кода, инструменты в помощь