Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
А у нас единственная проблема — тестами покрыто малая часть приложения. Фичи успевают внедрять быстрее, чем их покрывают тестами. А внедряют их быстрее тестов, поскольку так требует руководство :)
Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк.
40% от общего количества — довольно спорный вопрос. Изобилие комментариев внутри метода (а не в «шапке») зачастую мешает восприятию кода, который в принципе должен писаться так, чтобы быть понятным. Конечно, это субъективное мнение. А тулза вроде интересная:)
Да, как правило приходится сталкиваться с комментариями типа:
# Frobnicate throbber
throbber.frobincate()
или
# Increase reference count
references += 1
При этом назначение метода в шапке часто никак не описывается. Бороться с этим тяжело, почему-то мало кто понимает, для чего нужны комментарии.
# Frobnicate throbber
throbber.frobincate()
или
# Increase reference count
references += 1
При этом назначение метода в шапке часто никак не описывается. Бороться с этим тяжело, почему-то мало кто понимает, для чего нужны комментарии.
Путаете немножко.
В шапке или докстринге (если таковые есть в языке) пишется про назначение метода или функции. В теле — пояснения к реализации. Если реализацию еще можно не прояснять, то назначение следует описывать всегда.
И, черт возьми, реально время на комментарии не любят тратить только те, что так и не соизволили освоить адекватно слепую печать!
В шапке или докстринге (если таковые есть в языке) пишется про назначение метода или функции. В теле — пояснения к реализации. Если реализацию еще можно не прояснять, то назначение следует описывать всегда.
И, черт возьми, реально время на комментарии не любят тратить только те, что так и не соизволили освоить адекватно слепую печать!
Это никак не связано, или почти никак
Это вы только что признались, что сами не очень с набором текста или что?
Просто не знаю уже, как объяснить нежелание отдельных кодеров комментировать собственные творения. Это так трудно? Это так не нужно? Сложно? И ведь не лохи какие-нибудь, а люди с десятилетним опытом. Сначал понять не мог.
А потом увидел, с какой скоростью они русский текст из себя выдавливают и прозрел. Это просто-напросто тяжело для них!
Просто не знаю уже, как объяснить нежелание отдельных кодеров комментировать собственные творения. Это так трудно? Это так не нужно? Сложно? И ведь не лохи какие-нибудь, а люди с десятилетним опытом. Сначал понять не мог.
А потом увидел, с какой скоростью они русский текст из себя выдавливают и прозрел. Это просто-напросто тяжело для них!
Глупости, во-первых, можно быстро набирать русский, английский, какой-угодно текст без слепого набора, во-вторых, это не решает.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
Надо, понятное дело, объяснять, когда и зачем это надо.
Только комменты в докстрингах или чуть выше тела функции нужны всегда. И лучше бы у программиста были бессознательной привычкой пояснения к своим функциям. Это такой же хороший тон, как и качественное тестирование кода.
В идеальном случае автоматический сборщик комментариев вроде того же sphinx для Питона или какие-нибудь Doxygen, scaladoc, javadoc в результате должен выдавать полноценное описание API. В качественном open source проекте это более чем хороший тон.
А вот так называемые «корпоративные» продукты очень часто представляют собой недокументированную кашу кода.
Только комменты в докстрингах или чуть выше тела функции нужны всегда. И лучше бы у программиста были бессознательной привычкой пояснения к своим функциям. Это такой же хороший тон, как и качественное тестирование кода.
В идеальном случае автоматический сборщик комментариев вроде того же sphinx для Питона или какие-нибудь Doxygen, scaladoc, javadoc в результате должен выдавать полноценное описание API. В качественном open source проекте это более чем хороший тон.
А вот так называемые «корпоративные» продукты очень часто представляют собой недокументированную кашу кода.
Если вы пишете блок, который надо прокомментировать — вынесите его в отдельный метод и опишите в шапке (алгоритмы, ссылки на документацию и обсуждения и т.п.)
Чаще всего поясняющие комментарии в коде методов действительно не имеют смысла. Плюс ко всему, качество комментариев по моему опыту всегда коррелирует с качеством кода. Поэтому обычно хорошему программисту комментировать код не нужно, а плохой программист комментирует код так, что лучше бы не комментировал.
Живой пример (PHP):
И код никудышный, и комментарии соответствующие.
Чаще всего поясняющие комментарии в коде методов действительно не имеют смысла. Плюс ко всему, качество комментариев по моему опыту всегда коррелирует с качеством кода. Поэтому обычно хорошему программисту комментировать код не нужно, а плохой программист комментирует код так, что лучше бы не комментировал.
Живой пример (PHP):
// Render
$layoutPath = $this->getLayoutPath('Base');
if (file_exists($layoutPath)) {
// Render Layout
ob_start();
include $layoutPath;
$content = ob_get_clean();
}
// Render
echo $content;
И код никудышный, и комментарии соответствующие.
А у нас нет проблем, мы в отпуске :)
А для C++/Qt сообщество что то аналогичное может посоветовать?
ооооо, метрики кода :)
самая нелепая вещь что была придумана быдломенеджерами :)
мне всё время интересно как можно померять качество кода, например, html парсера, глядя только на исходники и 100% покрывающие их юниттесты? :)
P.S. подсказка html парсер это в первую очередь нечто опирающееся на стандарт, описанный человеческим языком…
самая нелепая вещь что была придумана быдломенеджерами :)
мне всё время интересно как можно померять качество кода, например, html парсера, глядя только на исходники и 100% покрывающие их юниттесты? :)
P.S. подсказка html парсер это в первую очередь нечто опирающееся на стандарт, описанный человеческим языком…
Я согласен, что померять качество когда метриками задача не из простых. Но вот пример ваш не очень. В данном случае, вы говорите о качестве продукта, а не о качестве кода. Можно красиво запрограммировать, но не то. А это уже другая проблема.
Метрики кода — довольно полезная вещь. Например, по ним я оцениваю состояние текущего проекта и сравниваю его с ранее выполненными. На основе полученных данных можно оценить сложность, объем работ и необходимые для выполнения ресурсы. Зачастую эти цифры показывают более точный результат, чем субъективный взгляд со стороны.
в точку
хахаха, примитивный пример, как по метрикам оценить сложность:
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 ] );
};
}
и что про этот код скажет программист делающий ревью…
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 ] );
};
}
и что про этот код скажет программист делающий ревью…
Ваши метрики кода дают илюзию контроля, но не сам контроль. Что толку с вашего идеального кода по метрикам, если код не обрабатывает ошибок и имеет дедлок на 2-ом часу работы, ой а здесь ваши юнитэсты скорее всего тоже не помогут, потому что дедлок случается согласно теории вероятности и если его не искать целенаправлено то ваши тэсты все успешно буду пройдены, но софтина завалится. Ваши метрики ничерта не покажут что обработчик прерываний запорол стэк изза неправильно выбраной модели памяти и контролер начинает валится в самых непредвиденных местах. Зато у нас шапка в каждом файле и описание над каждой функицей.
К чёрту менеджера который думает что одними метриками он что-то будет контролировать, просто в один момент звёзды сложатся плохо и всё накрыется медным тазом и виноват будет он, а не програмисты.
Хотите контролировать качество кода извольте найти квалифицированных програмистов не задействованных в разработке даного фрагмента и заставьте проделать качественны разбор кода хотя бы раз в неделю. От проблем вас это не убережёт, но зато вы о них будете знать не за день до релиза. А метрики, метрики можете оставить, но это только для 1-го уровня контроля, что-то вроде базовых правил гигиены, чистить зубы по утрам, документировать внешние интерфейсы и неочевидные вещи.
А оценивать сложность работ и объём работ по таким примитивным метрикам можно разве для типовых проэктов.
К чёрту менеджера который думает что одними метриками он что-то будет контролировать, просто в один момент звёзды сложатся плохо и всё накрыется медным тазом и виноват будет он, а не програмисты.
Хотите контролировать качество кода извольте найти квалифицированных програмистов не задействованных в разработке даного фрагмента и заставьте проделать качественны разбор кода хотя бы раз в неделю. От проблем вас это не убережёт, но зато вы о них будете знать не за день до релиза. А метрики, метрики можете оставить, но это только для 1-го уровня контроля, что-то вроде базовых правил гигиены, чистить зубы по утрам, документировать внешние интерфейсы и неочевидные вещи.
А оценивать сложность работ и объём работ по таким примитивным метрикам можно разве для типовых проэктов.
Я думаю качество кода — это плохо формализируемая область, тем более для автоматических программ. Качественный код — это код, который понятен человеку и с которым удобно работать. Раз психика человека неформализируема, а автоматическая программа попытаться понять код не может, то и все метрики Sonar не более, чем цифры, хотя как-то и связанные с реальным качеством кода.
Это примерно тоже самое, что брать на работу только тех, кто набирает много баллов в IQ и других тестах.
Это примерно тоже самое, что брать на работу только тех, кто набирает много баллов в IQ и других тестах.
А в случае с Sonar внедрение его может быть наоборот отрицательным. Разработчики зная его критерии будут писать код под них, а не понятный и удобный код.
По-моему, лучшие способ поднять качество кода, это:
— выкладывать код в open source;
— парное программирование;
— проверка любого кода, другим разработчиком, как в Google.
— выкладывать код в open source;
— парное программирование;
— проверка любого кода, другим разработчиком, как в Google.
То идея в том, чтобы проверять код другими людьми, а не машинами.
>>проверка любого кода, другим разработчиком, как в Google.
Это называется pier review. Вот например Gerrit для этого прекрасно подходит.
Это называется pier review. Вот например Gerrit для этого прекрасно подходит.
Ручной тест не позволяет создать регрессию. Через месяц что то сломается и не узнаете. Юнит или не юнит, но тесты должны быть автоматическими
Кроме юнит тестов есть еще куча тест техник. Тот же acceptance testing с помощью WebDriver.
Лично я считаю, что оценка качества кода по количеству комментариев и проценту покрытия кода тестами в принципе не может дать никакого результата, потому что эти показатели не имеют ничего общего с качеством кода.
Например у меня на работе код оценивается следующим образом. Мы работаем над проектом командой из 4 человек, и если кто-то увидел ковнокод в репозитарии, то он громко на весь офис кричит: «Говнокод!», и имя автора кода, после чего над автором глумятся весь день… По-моему, самый лучший мотиватор.
Ну а если серьезно, то просто нужно, чтобы программисту доставляло эстетическое удовольствие писать качественный код, и тогда все будет хорошо, иначе это ошибка в выборе программиста.
Например у меня на работе код оценивается следующим образом. Мы работаем над проектом командой из 4 человек, и если кто-то увидел ковнокод в репозитарии, то он громко на весь офис кричит: «Говнокод!», и имя автора кода, после чего над автором глумятся весь день… По-моему, самый лучший мотиватор.
Ну а если серьезно, то просто нужно, чтобы программисту доставляло эстетическое удовольствие писать качественный код, и тогда все будет хорошо, иначе это ошибка в выборе программиста.
Это зависит от психики и организации человека. Если бы я допустил ляп, и мне бы день кричали говнокод, я бы в этот же день уволился нахуй. Потому что извините, в гробу видал работать в таком коллективе.
Ты забываешь золотое правило. Критикуй ошибки, код, дизайн, но не критикуй людей.
Ты забываешь золотое правило. Критикуй ошибки, код, дизайн, но не критикуй людей.
И уж тем более, еще более важное правило — хвали на людях, ругай наедине.
Зачем же увольнятся. Надо тихо терпеть, накапливая злобу, а потом в один прекрасный день всех порезать на маленькие кусочки, воткнуть напильник в глаз техдиректору и т.п. По-моему, самый лучший мотиватор для подобных работодателей.
Понятие «Говнокод» иногда очень субъективное. У нас раз в неделю проводили коллективный Code Review. Каждый мог выставить на обсуждение чужой участок кода, который он считал проблемным. Далее шло обсуждение, где приводились доводы как против, так и в защиту кода. В результате вырабатывалась практика, обязательная для всей команды. На самом деле выработка практики происходила далеко не всегда с первого раза. Но в целом, по моим ощущениям, это помогло подтянуть качество кода у более слабых членов команды.
Какая увлекательная история в эпиграфе, причём заметьте с хэппиэндом: «приходит представитель Всемирно Известной Организации по Измерению Качества… попала в Топ 10… проект на самом деле 10й с конца.» Т.е. десятый с конца в десятке, они всё-таки выиграли? Ай, молодцы какие
Джоэл Спольский наоборот пишет, что у программиста ничего не надо мерить. Все эти измерения не объективны, а если проект 10 с конца, то это вина руководителя, проектом и людьми надо руководить, а не метрики мерить. На мой взгляд плохое качество кода лечится введением небольшого стандарта кодирования. Хотя если так задуматься, что это такое вообще качество кода? может начнем с определения, что бы все мы говорили об одном и том же.
как руководить проектом, о котором ты ничего не знаешь?
Согласен на счет стандартов кодирования. Есть те, кто пишет великолепно (то есть доступоно, прозрачно, оптимально). Но во всем должен быть баланс. По сути стандарты это и фиксируют.
Вопрос измерения метрик он пожалуй все-таки важный. Я почитал про Sonar. По сути это просто автомат по проверке соблюдения таких стандартов. Когда команда сыграна здесь никаких проблем, а вот когда куча народу с участием подрядных организаций, то стандарты пожалуй не помешают.
Вот книга Дж. Ханка Рейнвотера «Как пасти котов». Я сейчас не предлагаю ее обсуждать, не буду говорить хорошая она или плохая. Это не важно. Но в этой книге автор пытается поделить все братсво кодеров на категории. Он там выделяет разгельдяев и еще кого-то там. Ну во общем доля правды в этом есть. Есть люди, которые, не умеют кодировать. Они порождают просто ужастный код. От них нужно либо избавляться в своей команде (но это если человек просто не адекватен), либо приучать к стилю (если человек отличный программист, но так случилось, что он не умеет работать в команде).
Вот как раз для обучения подобные решения и нужны. Лично мне кажется, что приведенный здесь продукт вполне неплохое решения для подобных задач.
Вопрос измерения метрик он пожалуй все-таки важный. Я почитал про Sonar. По сути это просто автомат по проверке соблюдения таких стандартов. Когда команда сыграна здесь никаких проблем, а вот когда куча народу с участием подрядных организаций, то стандарты пожалуй не помешают.
Вот книга Дж. Ханка Рейнвотера «Как пасти котов». Я сейчас не предлагаю ее обсуждать, не буду говорить хорошая она или плохая. Это не важно. Но в этой книге автор пытается поделить все братсво кодеров на категории. Он там выделяет разгельдяев и еще кого-то там. Ну во общем доля правды в этом есть. Есть люди, которые, не умеют кодировать. Они порождают просто ужастный код. От них нужно либо избавляться в своей команде (но это если человек просто не адекватен), либо приучать к стилю (если человек отличный программист, но так случилось, что он не умеет работать в команде).
Вот как раз для обучения подобные решения и нужны. Лично мне кажется, что приведенный здесь продукт вполне неплохое решения для подобных задач.
Вы говорите кодировать, простите, но чтобы кодировать много ума ненадо. Есть кодер есть девелопер, или разработчик, как Вам будет угодно. Да не все люди гении. Кто-то пишет код дольше, укого-то процесс разработки занимает больше времени (я имею ввиду именно процесс проектирования системы), но Вы этого никак не замеряете, потому как еще вмешивается психология. Да и вообще я же и предлагаю, давайте определимся что значит качество кода, а то мы будем мереть не то.
Я согласен з Джелом, но вот делать с него большого авторитета в области разработки софта не стал бы. После его ухода из Майкрософта он был больше известен благодаря блогу чем реальным достижениям в области софтостроения. Его багтрекинг уныл и судя по всему никогда не был заметным игроком в сегменте. Что у него действительно получилось хорошо так это stackoverflow.
Кто нибудь знает подобные проекты для питоновских проектов?
Я пользуюсь pyLint'ом в связке с емаксом (можно сразу перейти на строчку с ворнингом).
Отчет выглядит так: pastebin.com/kaHf2yNj
Отчет выглядит так: pastebin.com/kaHf2yNj
Тока у него некоторые проблемы с русским языком — строки с русским он считает слишком длинными. Да и вообще слишком многословен, но в целом кое что может показать полезное.
А для проверки покрытия кода тестами есть утилита PyCoverage. Конечно покрытие тестами на 100% — это хорошо, но даже разработчик пишет, что это не панацея
А PyLint хорошая утилита, но когда работаешь с библиотеками или фреймворками, а она начинает ругаться на них, то это отвлекает.
А PyLint хорошая утилита, но когда работаешь с библиотеками или фреймворками, а она начинает ругаться на них, то это отвлекает.
Почему не в «Я пиарюсь»?
Единственное чего сильно не хватает это описания того как его установить и как использовать.
Вроде на сайте есть у них: docs.codehaus.org/display/SONAR/Install+Sonar
Было бы еще круче, если бы вместо краткого описания проблемы в конкретном месте кода было бы еще можно поглядеть детальное описание этой проблемы, почему это нехорошо и т.д. (на сайте где водится этот puppycrawl, оно конечно есть, но гуглить туда неудобно). Ну и там же — возможность отфильтровать/отключить эти сообщения в текущем проекте. А так проект очень понравился :).
Этот функционал есть, попробуйте. Каждое замечание можно отследить прямо в коде.
Вы меня неправильно поняли.
Например:
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 :)
Другое заключается в том что я пока не понял, как ему объяснить, что такие вещи можно иногда опускать (например, когда наличие параметра обязательно, чтобы не нарушать сигнатуру метода, но параметр не используется).
Например:
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 :)
Другое заключается в том что я пока не понял, как ему объяснить, что такие вещи можно иногда опускать (например, когда наличие параметра обязательно, чтобы не нарушать сигнатуру метода, но параметр не используется).
А иконки Violations слизаны с Atlassian Jira…
В версии 2.2 это было исправлено — jira.codehaus.org/browse/SONAR-1636
В одной компании мы использовали Bamboo. Это платный билд-сервер, который заодно и генерирует похожие отчёты.
А в другой компании мы при билде запускали ряд плагинов для Maven (FindBugs, PMD, CheckStyle), которые тоже генерировали похожие отчёты. Кстати, Sonar их тоже использует, кажется.
А в другой компании мы при билде запускали ряд плагинов для Maven (FindBugs, PMD, CheckStyle), которые тоже генерировали похожие отчёты. Кстати, Sonar их тоже использует, кажется.
Меня заинтересовала первая рекомендация: «Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк. ». Почему именно столько? У нас вот считается, что комментариев должно быть как можно меньше.
Интересно, а откуда взяты «рекомендуемые значения»? :)
В основном из двух источников:
1. Определения метрик. Пример — LCOM4.
2. Stack overflow. Пример — покрытие тестами.
1. Определения метрик. Пример — LCOM4.
2. Stack overflow. Пример — покрытие тестами.
Интересно а для C++ есть что-либо подобное?
выше ответили: habrahabr.ru/blogs/pm/100013/#comment_3089261
Средняя сложность методов — не больше 5
100 простых геттеров, 100 простых сеттеров и 10 методов со сложностью 100. Средняя по больнице — 4.2.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление качеством кода