Качество кода, инструменты в помощь

    Добрый день, уважаемые хабровчане!

    В последнее время в сообществе PHP часто слышу обсуждения по поводу code review, решил внести свой вклад, хочу рассказать о возможностях которые предназначены упростить вам жизнь и улучшить качество кода в вашем проекте. Актуально не только для PHP, подобные инструменты, описанным здесь, существуют также и для других языков программирования, например я узнал о таковых когда участвовал в проекте на NodeJS.

    Хочу поделиться инструментами которые призваны улучшить качество кода, найти синтаксические ошибки, привести все к одному code style и т.п.

    Pre-commit


    Если в поисковике наберете “pre-commit php”, то он вам выдаст несколько уже готовых скриптов проводящих анализ написанного кода. Для git, скрипт надо разместить в папке “.git/hooks/” и тогда каждый раз, когда делаете commit он будет запускаться и если будут обнаружены ошибки, то просто не даст запушить код в репозиторий. Для некоторых IDE есть отдельные плагины которые делают то же самое, но что, если у вас большая команда и все пользуются разными редакторами? Да и настроить данный скрипт один раз, выложив его в ваш репозиторий, проще, нежели для каждого разработчика по отдельности настраивать его IDE. Что еще важно, в данный скрипт вы можете добавить любые другие инструменты которые используете в своей команде, такие как статический анализатор (например phpstan), и/или производить юнит тестирование (например phpunit)

    Инструменты помогающие улучшить качество кода


    php -l (Syntax check only (lint)) — встроенная в ядро PHP проверка синтаксиса.

    php-cs-fixer (PHP Coding Standards Fixer) — Исправляет ваш код в соответствии со стандартами PSR-1, PSR-2 и т. д., или другим сообществам, таким как Symfony. Вы также можете определить свой (командный) стиль через конфигурацию. Т.е. во всей вашей команде стиль кода будет один.

    php-cs + php-cbf (PHP CodeSniffer + PHP Code Beautifier) — Представляет собой набор из двух PHP-скриптов; Основной скрипт phpcs, который выделяет PHP, JavaScript и CSS-файлы для обнаружения нарушений определенного стандарта кодирования, а второй скрипт phpcbf автоматически исправляет стандартные нарушения кодирования. Схожий инструмент с php-cs-fixer.

    php-md (PHP Mess Detector) — Побочный проект PHP Depend, цель которого стать PHP-эквивалентом хорошо известного инструмента Java PMD. Берет заданную базу исходного кода PHP и ищет несколько потенциальных проблем в этом источнике. Эти проблемы могут быть такими, как синтаксические ошибки, субоптимальный код, слишком сложные выражения, неиспользуемые параметры/методы/свойства.

    php-cpd (PHP Copy/Paste Detector) — Детектор копирования / вставки для кода PHP. Т.е. находит одинаковые блоки кода в различных частях приложения которые можно вынести в отдельные функции/методы.

    Вы можете более глубоко погрузиться в автоматизацию проверки кода и вероятно найдете много других интересных инструментов.

    Вывод


    Используя имеющиеся в мире разработки инструменты многие рутинные процессы по проверке кода вы можете автоматизировать, что на порядок улучшит его качество (т.к. мы исключаем человеческий фактор). Для большей уверенности в использовании этих инструментов всей командой их можно внедрять в pre-commit скрипт который запускается перед созданием коммита в вашей системе управления версиями.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 26

      –1
      Спасибо!
      +2
      Уважаемые хабравчане, буду благодарен за комментарий если минусуете, не совсем понятно что здесь не так, неужели описанных инструментов нет в природе? Вроде ссылки на них дал даже.
      Спасибо!
        +3

        И где здесь собственно про code review?

          0
          Описал инструменты которые помогают автоматизировать (статья поэтому и называется «Code review это просто») code review, проверяют на синтасические ошибки, приводят code style к одному виду во всем коде, проверяют наличие повторного кода, статический анализатор может проверить типы данных, phpunit даже можно автоматически запускать, статический анализатор может найти ошибки вида «не достижимая переменная» и многое другое, все возможности в одной статье не уместить.
          Разве это не относится к области code review? Если нет, буду благодарен если поясните его смысл, спасибо!
            0
            Всегда думал, что code review — это когда твой код читает другой живой человек. А всякий автоматический анализ кода — это уже из другой оперы.
              0
              Все эти инструменты настраиваются человеком как ему захочется, согласно принятым правилам в команде.
              Вы считаете человек надежнее чем машина выполняет рутиную работу и человеческий взгляд надежнее машинного? Мне всегда казалось машина как раз рутиную работу и предназначена делать и машина лучше может сравнить например написание переменной при ее объявлении и при ее вызове (php к сожалению прощает такие ошибки как разное написание переменной, в итоге при обращении к ней в ней может оказаться совсем не то, что ожидалось)
              Т.е. вы считаете данные инструменты никчемные и их вообще надо запретить, все должен делать человек?
              И да, кто запрещает использовать человеческий труд? Здесь описаны инструменты которые ПОМОГАЮТ проводить code review, но итог и процесс зависит только от человека.

              А всякий автоматический анализ кода — это уже из другой оперы.

              Из какой, подскажите? Цель вроде одна и та же.
                0

                Из области Хука на пуш коммита в бранч.

                  0
                  Данные инструменты можно использовать как в хуках, так и отдельно запускать. Про pre-commit написал только для того, чтобы описать где это все можно удачно использовать, для этого и выделили часть статьи как «Pre-commit review».
                  +2
                  Т.е. вы считаете данные инструменты никчемные и их вообще надо запретить, все должен делать человек?

                  Что-то вас куда-то не туда понесло. Статический анализ – это хорошо, но это не 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, а оказывается, надо просто настроить линтер и статический анализатор. Это какой-то дилетантизм. За это и минус от меня с причиной "Низкий технический уровень материала".

                    0
                    php-cs-fixer правит code style, это не относится к code rewiev?

                    За это и минус от меня с ...

                    Спасибо за Ваше мнение! Немного переименовать статью надо. Могу только добавить, что эти инструменты в помощь при code rewiev и они не могут полноценно заменить весь rewiev.
                    … об инструментах которые помогают проводить code review.
                      0
                      php-cs-fixer правит code style, это не относится к code rewiev?

                      К code review – нет, к software quality assurance techniques – да. Если у вас человек в ходе code review следит за стилем и единообразием кода – это одно. Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.


                      А у вас получается как-то так: "Высшая математика – это просто, возьмите калькулятор, чтобы не умножать большие числа вручную – вот и все. Ведь решая задачи вышей математики, нам надо умножать числа..."

                        +1
                        Спасибо, надеюсь я Вас услышал, просто очень часто слышу, что при code rewiev проверяется как раз единообразие code style, производится поиск синтасических ошибок и т.п.
                        Если вы настраиваете линтер/форматтер, и человеку этим заниматься не надо – значит, вы убрали этот момент из code review, и ревьюер может заниматься другими задачи, которые входят в code review. И вот как раз из этих других задач и складывается сложность code review.

                        Статья наверное больше об этом, об исключении из code rewiev моментов которые можно автоматизировать.
            0

            "Помощь" с мягким знаком пишется, еще и в заголовке такое…
            Уровень материала крайне низкий в целом.

              0
              буквально пять минут так было, волнуюсь, извините.
              Вот качество материала крайне низкое, только почему то в большинстве команд такое не используется, по крайней мере в проектах PHP которых участвовал приходилось предлагать и внедрять данные инструменты. Хотя не знаю конечно, может это все туфта, все эти инструменты, правда после их внедрения sentry меньше ошибок стало отлавливать.
              0
              Решил поделиться инструментами которые на порядок облегчают жизнь программиста и на порядок лучше находят ошибки в коде чем человеческий взгляд (проверено на практике), НО минусов пока больше, наверное ничего не стоят эти инструменты, зачем их только разрабатывают когда есть человеческий, предвзятый и уставший, взгляд. Два человека спасибо сказали, так и их заминусовали. Более того, ведь никто не заставляет вас и никого другого их использовать, а если и захотите использовать, так в любом случае потребуется разобраться со всем этим, здесь только озвучена такая возможность.
              Странно.
                0

                Дело не только в информации, но и в том, как ее преподносить.


                Как я уже писал, изначально вы представили все так, будто линтер + статический анализатор – это и есть всё code review. Да, заголовок вы потом поправили, но осадочек остался если убрать из статьи воду про упрощение жизни и улучшение качества кода на порядок (очень сомнительно, никаким линтером из плохого кода не сделать хороший), то из полезного остается только раздел "Инструменты помогающие улучшить качество кода". Маловато как-то для полноценной статьи, как по мне: список из 5 инструментов с кратким описанием.


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


                Ну а что касается "Два человека спасибо сказали, так и их заминусовали" – на хабре не приняты мусорные комментарии типа "спасибо", "+1" и т.д. Для этого и есть голосование за статью.

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

                  Еще раз спасибо, именно такую помощь на хабре и хотел увидеть! Надеюсь я Вас услышал.
                0
                PS: Скажу больше, без использования подобных инструментов php слабый язык программирования (хотя я его очень люблю, поэтому и рассказал про такие инструменты), т.к. прощает ошибки, например когда объявил переменную в одном регистре, а при обращении соучайно напутал регистр одного из символов в названии переменнтой, то тебе выдаст что то типа «PHP Notice: Undefined variable:» и код продолжит работать, хотя ты думаешь что обратился к переменной в которой уже есть какое то значение. А эти инструменты позволяют найти подобные ошибки, когда человеческий взгляд может их пропустить.
                  0
                  Может, будет проще перейти от PHP к более продвинутым языкам?
                    0
                    Сейчас 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.
                      0
                      Что заставляет вас думать, что динамическая типизация — это проблема?
                        0
                        Это обширный вопрос, но в PHP (как уверен и в других языках с такой типизацией) достаточно много проблем как раз из за динамической типизации, поэтому type hinting и strict_types добавили (как написал выше, язык развивается, кто участвует в его разработке о таких проблемах явно знают и явно стараются их закрыть не повторяя ошибок других ЯП).

                        Не буду вдаваться в технические подробности почему статическая типизация лучше динамической, а логическая проблема в следующем — легче выстрелить себе в ногу, допустим когда определил переменную как int, далее переопределил её как string, а потом обратился к этой переменной как к int, теоретически это возможно и сделать такое может любой программист (особенно в больших проектах, поэтому в них как правило Java используют, а не PHP), не нарочно. Если так случайно сделаете, то в языках со статической типизацией приложение у вас просто упадет и вы будете знать об этом, а в языках с динамической типизацие приложение продолжет работать с ошибкой и вы об этом узнаете только когда компания попадет на круглую сумму.

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

                          Вы путаете статическую/динамическую и сильную/слабую типизацию.

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

                            Я об этом.

                            Ну а если глубже капнуть, то да, слабая и сильная типизация.
                              0

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

                Only users with full accounts can post comments. Log in, please.