Управление качеством кода

    В одной из книг ДеМарко была приведена интересная история. Представьте, что к руководителю проекта приходит представитель Всемирно Известной Организации по Измерению Качества и сообщает, что команда проекта попала в Топ 10 всех команд в мире по качеству кодирования.

    О чем думает руководитель? Его сердце наполняется теплотой и проскакивают мысли «Вот молоцы! А я всегда подозревал...». После чего, представитель вдруг возвращается и приносит свои извинения — произошла ошибка, проект на самом деле 10й с конца. Настроение руководителя кардинально меняется и он уже вовсю проклинает свою команду.

    В чем ошибка руководителя? Он не измеряет качество кода.

    А это делается быстро и безболезненно с помощью автоматизированных средств сбора метрик кода. В своем проекте мы используем Sonar. Вот как выглядит Dashboard страница проекта:



    Sonar поддерживает Java, также возможна поддержка языков Flex, PHP, PL/SQL, Cobol, Visual Basic 6 с помощью плагинов. Полное описание метрик можно найти здесь.

    Рекомендуемые значения некоторых метрик:
    • Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк.
    • Повторения строк — чем меньше, тем лучше.
    • Средняя сложность методов — не больше 5.
    • Покрытие кода тестами — от 80% и больше.
    • Rules compliance (соответствие правилам, настраиваемым в Sonar) — чем больше, тем лучше.
    • LCOM4 (разнесенность компонентов) — чем ближе к 1, тем лучше.

    У нас налицо проблемы с юнит тестами. А у вас?
    Поделиться публикацией

    Комментарии 91

    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
          +8
          Это символ с кодом 0, NULL-терминальная строка -)
          • НЛО прилетело и опубликовало эту надпись здесь
          0
          Вы будете удивлены тем, что можно сделать на VB, в Visual Studio. Впрочем, то же самое, что и на встроенных C#, Java, Python и остальных языках.
            0
            Если человек писал VB драйвер, то его сложно чем-то удивить.
            • НЛО прилетело и опубликовало эту надпись здесь
            0
            А у нас единственная проблема — тестами покрыто малая часть приложения. Фичи успевают внедрять быстрее, чем их покрывают тестами. А внедряют их быстрее тестов, поскольку так требует руководство :)
              0
              Эээээ… А почему вообще фичи пишутся до тестов? TDD или не TDD, в конце-то концов? :)))
                0
                TDD это что, истина в последней инстанции? Других методологий нет?
                  0
                  Вот поэтому и тестов нет :)
                  PS: У нас тоже тестов мало
              +5
              Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк.

              40% от общего количества — довольно спорный вопрос. Изобилие комментариев внутри метода (а не в «шапке») зачастую мешает восприятию кода, который в принципе должен писаться так, чтобы быть понятным. Конечно, это субъективное мнение. А тулза вроде интересная:)
                +4
                Да, как правило приходится сталкиваться с комментариями типа:
                # Frobnicate throbber
                throbber.frobincate()

                или

                # Increase reference count
                references += 1

                При этом назначение метода в шапке часто никак не описывается. Бороться с этим тяжело, почему-то мало кто понимает, для чего нужны комментарии.
                  –2
                  Путаете немножко.

                  В шапке или докстринге (если таковые есть в языке) пишется про назначение метода или функции. В теле — пояснения к реализации. Если реализацию еще можно не прояснять, то назначение следует описывать всегда.

                  И, черт возьми, реально время на комментарии не любят тратить только те, что так и не соизволили освоить адекватно слепую печать!
                    0
                    Это никак не связано, или почти никак
                      –2
                      Это вы только что признались, что сами не очень с набором текста или что?

                      Просто не знаю уже, как объяснить нежелание отдельных кодеров комментировать собственные творения. Это так трудно? Это так не нужно? Сложно? И ведь не лохи какие-нибудь, а люди с десятилетним опытом. Сначал понять не мог.

                      А потом увидел, с какой скоростью они русский текст из себя выдавливают и прозрел. Это просто-напросто тяжело для них!

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

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

                        К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
                          0
                          Надо, понятное дело, объяснять, когда и зачем это надо.

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

                          В идеальном случае автоматический сборщик комментариев вроде того же sphinx для Питона или какие-нибудь Doxygen, scaladoc, javadoc в результате должен выдавать полноценное описание API. В качественном open source проекте это более чем хороший тон.

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

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

                      Живой пример (PHP):
                      // Render
                      $layoutPath = $this->getLayoutPath('Base');
                      if (file_exists($layoutPath)) {
                          // Render Layout
                          ob_start();
                          include $layoutPath;
                          $content = ob_get_clean();
                      }
                      
                      // Render
                      echo $content;
                      


                      И код никудышный, и комментарии соответствующие.
                    +9
                    А у нас нет проблем, мы в отпуске :)
                      +2
                      А для C++/Qt сообщество что то аналогичное может посоветовать?
                        +4
                        Открою небольшой секрет: Sonar будет поддерживать C++ в ближайшее время — мы работаем над этим ;)
                          0
                          Это будет очень уместно, следующий проект на 80% C++
                            0
                            Ждем с нетерпением! Есть место, где можно подписаться и узнать когда оно будет готово?
                        +7
                        ооооо, метрики кода :)
                        самая нелепая вещь что была придумана быдломенеджерами :)
                        мне всё время интересно как можно померять качество кода, например, html парсера, глядя только на исходники и 100% покрывающие их юниттесты? :)

                        P.S. подсказка html парсер это в первую очередь нечто опирающееся на стандарт, описанный человеческим языком…
                          +1
                          Я согласен, что померять качество когда метриками задача не из простых. Но вот пример ваш не очень. В данном случае, вы говорите о качестве продукта, а не о качестве кода. Можно красиво запрограммировать, но не то. А это уже другая проблема.
                            –2
                            о да

                            int main()
                            {
                            };

                            идеальный код, наверное, по метрикам :)
                              +2
                              а где комменты?
                                –1
                                а коменты зависит уже от метрики писать их или не писать :) если метрика считает что просто наличие коммента хорошо, то конечно надо написать, и обрадовать менеджера :) а если метрика считает что к коротким функциям комментарии ничего не стоят — то зачем лишние телодвижения? :)
                                0
                                gcc -Wall скажет, что этот код не совсем чистый ;)
                              +2
                              Метрики кода — довольно полезная вещь. Например, по ним я оцениваю состояние текущего проекта и сравниваю его с ранее выполненными. На основе полученных данных можно оценить сложность, объем работ и необходимые для выполнения ресурсы. Зачастую эти цифры показывают более точный результат, чем субъективный взгляд со стороны.
                                0
                                в точку
                                  0
                                  хахаха, примитивный пример, как по метрикам оценить сложность:

                                  class Outputer{
                                  public:
                                  virtual void put( const string & ) = 0;
                                  virtual void put_char( char ) = 0;
                                  virtual ~Outputer(){};
                                  }

                                  typedef shared_ptr OutputerPtr;

                                  class HelloWord{
                                  static const string hello_word_string;
                                  OuputerPtr out;
                                  public:
                                  HelloWord( OuputerPtr o ): out( o ){};
                                  void operator()(){
                                  for( string::size_type i=0;iput_char( hello_word_string[ i ] );
                                  };
                                  }

                                  и что про этот код скажет программист делающий ревью…
                                    0
                                    Ваши метрики кода дают илюзию контроля, но не сам контроль. Что толку с вашего идеального кода по метрикам, если код не обрабатывает ошибок и имеет дедлок на 2-ом часу работы, ой а здесь ваши юнитэсты скорее всего тоже не помогут, потому что дедлок случается согласно теории вероятности и если его не искать целенаправлено то ваши тэсты все успешно буду пройдены, но софтина завалится. Ваши метрики ничерта не покажут что обработчик прерываний запорол стэк изза неправильно выбраной модели памяти и контролер начинает валится в самых непредвиденных местах. Зато у нас шапка в каждом файле и описание над каждой функицей.
                                    К чёрту менеджера который думает что одними метриками он что-то будет контролировать, просто в один момент звёзды сложатся плохо и всё накрыется медным тазом и виноват будет он, а не програмисты.
                                    Хотите контролировать качество кода извольте найти квалифицированных програмистов не задействованных в разработке даного фрагмента и заставьте проделать качественны разбор кода хотя бы раз в неделю. От проблем вас это не убережёт, но зато вы о них будете знать не за день до релиза. А метрики, метрики можете оставить, но это только для 1-го уровня контроля, что-то вроде базовых правил гигиены, чистить зубы по утрам, документировать внешние интерфейсы и неочевидные вещи.
                                    А оценивать сложность работ и объём работ по таким примитивным метрикам можно разве для типовых проэктов.
                                  +5
                                  Я думаю качество кода — это плохо формализируемая область, тем более для автоматических программ. Качественный код — это код, который понятен человеку и с которым удобно работать. Раз психика человека неформализируема, а автоматическая программа попытаться понять код не может, то и все метрики Sonar не более, чем цифры, хотя как-то и связанные с реальным качеством кода.
                                  Это примерно тоже самое, что брать на работу только тех, кто набирает много баллов в IQ и других тестах.
                                    +7
                                    А в случае с Sonar внедрение его может быть наоборот отрицательным. Разработчики зная его критерии будут писать код под них, а не понятный и удобный код.
                                      +8
                                      По-моему, лучшие способ поднять качество кода, это:
                                      — выкладывать код в open source;
                                      — парное программирование;
                                      — проверка любого кода, другим разработчиком, как в Google.
                                        0
                                        То идея в том, чтобы проверять код другими людьми, а не машинами.
                                          +1
                                          нужно проверять и тем и другим
                                          0
                                          >>проверка любого кода, другим разработчиком, как в Google.
                                          Это называется pier review. Вот например Gerrit для этого прекрасно подходит.
                                            0
                                            peer review
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Ручной тест не позволяет создать регрессию. Через месяц что то сломается и не узнаете. Юнит или не юнит, но тесты должны быть автоматическими
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Кроме юнит тестов есть еще куча тест техник. Тот же acceptance testing с помощью WebDriver.
                                                  0
                                                  Я понимаю, иногда вообще удобнее сразу всю компоненту тестировать, но важно тобы они были автоматические и автоматически запускались — во время билда или после билда
                                              –3
                                              Лично я считаю, что оценка качества кода по количеству комментариев и проценту покрытия кода тестами в принципе не может дать никакого результата, потому что эти показатели не имеют ничего общего с качеством кода.
                                              Например у меня на работе код оценивается следующим образом. Мы работаем над проектом командой из 4 человек, и если кто-то увидел ковнокод в репозитарии, то он громко на весь офис кричит: «Говнокод!», и имя автора кода, после чего над автором глумятся весь день… По-моему, самый лучший мотиватор.
                                              Ну а если серьезно, то просто нужно, чтобы программисту доставляло эстетическое удовольствие писать качественный код, и тогда все будет хорошо, иначе это ошибка в выборе программиста.
                                                +1
                                                Это зависит от психики и организации человека. Если бы я допустил ляп, и мне бы день кричали говнокод, я бы в этот же день уволился нахуй. Потому что извините, в гробу видал работать в таком коллективе.

                                                Ты забываешь золотое правило. Критикуй ошибки, код, дизайн, но не критикуй людей.
                                                  0
                                                  И уж тем более, еще более важное правило — хвали на людях, ругай наедине.
                                                    0
                                                    Зачем же увольнятся. Надо тихо терпеть, накапливая злобу, а потом в один прекрасный день всех порезать на маленькие кусочки, воткнуть напильник в глаз техдиректору и т.п. По-моему, самый лучший мотиватор для подобных работодателей.
                                                    +1
                                                    Понятие «Говнокод» иногда очень субъективное. У нас раз в неделю проводили коллективный Code Review. Каждый мог выставить на обсуждение чужой участок кода, который он считал проблемным. Далее шло обсуждение, где приводились доводы как против, так и в защиту кода. В результате вырабатывалась практика, обязательная для всей команды. На самом деле выработка практики происходила далеко не всегда с первого раза. Но в целом, по моим ощущениям, это помогло подтянуть качество кода у более слабых членов команды.
                                                      0
                                                      Если говорить про стиль кода, то зачастую главное не какой стиль вы выбрали, а то, как строго вы ему следуете.
                                                      Хотя согласитесь, есть и вполне объективные метрики показывающие качество кода, например степень вложенности или абсолютно неговорящие имена методов.
                                                        0
                                                        для этого существуют стандарты кодирования
                                                    –1
                                                    Какая увлекательная история в эпиграфе, причём заметьте с хэппиэндом: «приходит представитель Всемирно Известной Организации по Измерению Качества… попала в Топ 10… проект на самом деле 10й с конца.» Т.е. десятый с конца в десятке, они всё-таки выиграли? Ай, молодцы какие
                                                      +1
                                                      Джоэл Спольский наоборот пишет, что у программиста ничего не надо мерить. Все эти измерения не объективны, а если проект 10 с конца, то это вина руководителя, проектом и людьми надо руководить, а не метрики мерить. На мой взгляд плохое качество кода лечится введением небольшого стандарта кодирования. Хотя если так задуматься, что это такое вообще качество кода? может начнем с определения, что бы все мы говорили об одном и том же.
                                                        –1
                                                        как руководить проектом, о котором ты ничего не знаешь?
                                                          0
                                                          я должен отвечать на этот вопрос? по моему это более чем странно — руководить проектом о котором ничего не знаешь. Вопрос тут только — а руководите ли вы проектом?
                                                            0
                                                            все верно. ты ничего не знаешь о проекте, в котором ничего не измеряешь.

                                                            а значит и не можешь им управлять
                                                              0
                                                              Ну можно мерять проект — но не программиста, дайте ему спокойно работать и грамотно ставьте задачи и мерять Вам его не придется. В проекте можно контролировать время и и сроки. Но нельзя мерять людей.
                                                          0
                                                          Согласен на счет стандартов кодирования. Есть те, кто пишет великолепно (то есть доступоно, прозрачно, оптимально). Но во всем должен быть баланс. По сути стандарты это и фиксируют.

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

                                                          Вот книга Дж. Ханка Рейнвотера «Как пасти котов». Я сейчас не предлагаю ее обсуждать, не буду говорить хорошая она или плохая. Это не важно. Но в этой книге автор пытается поделить все братсво кодеров на категории. Он там выделяет разгельдяев и еще кого-то там. Ну во общем доля правды в этом есть. Есть люди, которые, не умеют кодировать. Они порождают просто ужастный код. От них нужно либо избавляться в своей команде (но это если человек просто не адекватен), либо приучать к стилю (если человек отличный программист, но так случилось, что он не умеет работать в команде).

                                                          Вот как раз для обучения подобные решения и нужны. Лично мне кажется, что приведенный здесь продукт вполне неплохое решения для подобных задач.
                                                            0
                                                            Вы говорите кодировать, простите, но чтобы кодировать много ума ненадо. Есть кодер есть девелопер, или разработчик, как Вам будет угодно. Да не все люди гении. Кто-то пишет код дольше, укого-то процесс разработки занимает больше времени (я имею ввиду именно процесс проектирования системы), но Вы этого никак не замеряете, потому как еще вмешивается психология. Да и вообще я же и предлагаю, давайте определимся что значит качество кода, а то мы будем мереть не то.
                                                            0
                                                            Я согласен з Джелом, но вот делать с него большого авторитета в области разработки софта не стал бы. После его ухода из Майкрософта он был больше известен благодаря блогу чем реальным достижениям в области софтостроения. Его багтрекинг уныл и судя по всему никогда не был заметным игроком в сегменте. Что у него действительно получилось хорошо так это stackoverflow.
                                                            0
                                                            Кто нибудь знает подобные проекты для питоновских проектов?
                                                              +1
                                                              Я пользуюсь pyLint'ом в связке с емаксом (можно сразу перейти на строчку с ворнингом).
                                                              Отчет выглядит так: pastebin.com/kaHf2yNj
                                                                0
                                                                Тока у него некоторые проблемы с русским языком — строки с русским он считает слишком длинными. Да и вообще слишком многословен, но в целом кое что может показать полезное.
                                                                  +1
                                                                  А для проверки покрытия кода тестами есть утилита PyCoverage. Конечно покрытие тестами на 100% — это хорошо, но даже разработчик пишет, что это не панацея

                                                                  А PyLint хорошая утилита, но когда работаешь с библиотеками или фреймворками, а она начинает ругаться на них, то это отвлекает.
                                                                    0
                                                                    не панацея конечно, нужно выдерживать соотношение цена/эффект.
                                                                –1
                                                                Почему не в «Я пиарюсь»?
                                                                  0
                                                                  потому что я не пиарюсь :)
                                                                    0
                                                                    Надо создать раздел «Я пиарю»
                                                                  +1
                                                                  Единственное чего сильно не хватает это описания того как его установить и как использовать.
                                                                    0
                                                                    Вроде на сайте есть у них: docs.codehaus.org/display/SONAR/Install+Sonar
                                                                      0
                                                                      Спасибо. Это я видел и даже пытался поставить (под win), но вот как его использовать — непонятно.

                                                                      P.S. Хотел PHP проект прогнать, но как выяснилось уже после установки, похоже, нужен проект под maven. Просто так — без maven (только ради sonar-a не хочется его использовать), его нельзя запустить?
                                                                        0
                                                                        Конкретно сейчас Sonar проблематично использовать без Maven, но мы работаем и над этим тоже.
                                                                    0
                                                                    Было бы еще круче, если бы вместо краткого описания проблемы в конкретном месте кода было бы еще можно поглядеть детальное описание этой проблемы, почему это нехорошо и т.д. (на сайте где водится этот puppycrawl, оно конечно есть, но гуглить туда неудобно). Ну и там же — возможность отфильтровать/отключить эти сообщения в текущем проекте. А так проект очень понравился :).
                                                                      0
                                                                      Этот функционал есть, попробуйте. Каждое замечание можно отследить прямо в коде.
                                                                        0
                                                                        Вы меня неправильно поняли.
                                                                        Например:
                                                                        private void btAddScheduleActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_btAddScheduleActionPerformed
                                                                        ^ Unused formal parameter: Avoid unused method parameters such as 'evt'.
                                                                        На это можно нажать, вы попадаете на страницу, где написано:
                                                                        Unused formal parameter
                                                                        Plugin: pmd Key: UnusedFormalParameter
                                                                        Avoid passing parameters to methods or constructors and then not using those parameters.

                                                                        Это в общем-то и все. Но если этого мало, приходится гуглить по сообщению и попадать на проект PMD: pmd.sourceforge.net/rules/unusedcode.html

                                                                        Хотя, может быть, это их проблема, а не Sonar :)

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

                                                                          0
                                                                          Можно использовать комментарий "//NOSONAR".
                                                                      0
                                                                      А иконки Violations слизаны с Atlassian Jira…
                                                                      0
                                                                      В одной компании мы использовали Bamboo. Это платный билд-сервер, который заодно и генерирует похожие отчёты.
                                                                      А в другой компании мы при билде запускали ряд плагинов для Maven (FindBugs, PMD, CheckStyle), которые тоже генерировали похожие отчёты. Кстати, Sonar их тоже использует, кажется.

                                                                        0
                                                                        Меня заинтересовала первая рекомендация: «Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк. ». Почему именно столько? У нас вот считается, что комментариев должно быть как можно меньше.
                                                                          0
                                                                          Зависит от проекта, от модуля. API должно быть хорошо покрыто комментариями, а вот для внутренних штук лучше покрытие тестами.
                                                                          0
                                                                          Интересно, а откуда взяты «рекомендуемые значения»? :)
                                                                          0
                                                                          Интересно а для C++ есть что-либо подобное?
                                                                          0
                                                                          Средняя сложность методов — не больше 5

                                                                          100 простых геттеров, 100 простых сеттеров и 10 методов со сложностью 100. Средняя по больнице — 4.2.
                                                                            0
                                                                            Sonar отличает методы от аксессоров (геттеров/сеттеров)

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

                                                                          Самое читаемое