Качество кода [закрывается]

Вам нужно несколько значений флажков.

И, следовательно, HTML-имя ввода должно быть кратным (массив)

<input type="checkbox" name="participants" будет возвращать строку, только последнее переданное значение.

<input type="checkbox" name="participants[]" вернет массив всех отправленных значений.

Таким образом, замена name="participants" на name="participants[]" будет работать.

21
задан 4 revs, 2 users 100% 14 November 2013 в 21:40
поделиться

19 ответов

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

Из одной из других статей Джоэля :

Роберт Остин в своей книге «Измерение и управление эффективностью в организациях» говорит, что есть два этапа, когда вы вводите новые показатели производительности. Сначала вы действительно получаете то, что хотели, потому что никто не понял, как обмануть. На втором этапе вы на самом деле получаете что-то хуже, так как все понимают, как максимизировать то, что вы измеряете, даже ценой разрушения компании.

23
ответ дан 29 November 2019 в 06:07
поделиться

Before implementing any sort of metrics ask yourself.... ultimately... what is it you want to measure ?

-Programmer productivity are you not listening ?? duh

-Yeah sure.. but why is this important ?

Involving humans in metrics will innevitably try to optimize it for their own goals, thus, knowing this, you should be able to use this optimization in your advantage.

  • Ask yourself then if someone optimize the metric, what will they be concentrated on ?

Then direct your metric in measuring someting that will positively effect the system, thus instead of measuring bugs per programmer which only gives amunition to management to fire if things go bad, try to measure where and why the bugs occur, not who made them.

thus, bugs per modules, bugs per versions, bugs per code fix, bugs per feaures would be much more productive metrics and will help identify hotspots. Of course you can always tie it to someone as there is always an indirect link to a programmer, but before you place a programmer on the forefront of the blame war you better be darn sure HE-SHE is the cause.

  • Ask yourself what kind of environment you want to create ? What will the reaction of the team, managers, directors will be when faced with the metric's publication ?

If you measure people, and make them look bad then you are asking for troubble. If you peasure product then the focus will not be on making themselves look good but making the product look good. This in turn will be a much better motivator and will foster positive team spirit.

  • Make your metric public, any sort of information hiding will cause adverse reaction and injustice. Thus if you publicize your metrics be carefull on what they say.

Lastly if you really isist on measuring people then measure them all, programmer, architects, managers, salesmen, directors veryone should have the same scrutiny. Then hide the knives and place metal detectors on the doors. cause usually, transparency with people ina company only works one way, from the top looking downwards.

0
ответ дан 29 November 2019 в 06:07
поделиться

After reading some of your excellent responses I was thinking that the general problem with the above described metric is that it is negative reporting bugs - it doesn't encourage producing good quality code.

That is true. And you'll have the same trouble with any other metric you apply. The key issue is that quality is not something we know how to measure numerically. Plus, you shouldn't really care about the question of code quality primarily if you're doing your job properly. Your real question should be, "How is this person helping us make money?"

Evaluation is not something you can do with numbers, but it is something you have to try to do. The best advice I can give you is that your managers simply have to work with the programmers and understand what the programmers are doing. Another important source of information comes from a programmer's peers who work with them day in and day out. Since we don't have a numerical way to measure quality, you will to some degree or another have to rely on the softer science to get insight into how well your programmers are performing.

1
ответ дан 29 November 2019 в 06:07
поделиться

I have three things to say about this:

1) a manager who suggests that "higher bug count == worse developer" or "... == better tester" may be a bigger problem for your company than any single developer could ever be. How did this person get to be part of the discussion about evaluating developer performance? If they're managing developers, they should know better.

2) The easiest way for a developer to game any metric related to bugs (bug count, reopen rate, normalized or not per feature/LOC/whatever) is to make their implementation as difficult to test as they can. Impossible to test means zero bugs found by QA. Also probably impossible to use, which means zero bug reports from the field (well, maybe one). Any bug count metric is an incentive against testability. Ask management if that is really what they want.

3) If they ever actually implement this policy, run like hell.

1
ответ дан 29 November 2019 в 06:07
поделиться

This metric stinks and will encourage really bad practices and infighting as to who caused which bug. Any metric of fault should be counterbalanced by a metric measuring success. People who write more code will by definition have more opportunities for mistakes. Depending on the available data you may wish to normalize your rating system. If one developer implemented one feature with no defects I would not rate him in any way better than a developer that implemented 243 features with 3 defects. Rating developers requires management to put aside the numbers and observe each team member. An actively engaged manager will understand which developers have deficiencies and will work with them to improve their performance. This actually requires work by the managers to help each individual set and meet goals.

1
ответ дан 29 November 2019 в 06:07
поделиться

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

Там, где этот метод не считается практичным, я бы порекомендовал (и они тоже ... я думаю ...) рецензирование. Но не называйте это прямо: «Как вы оцениваете своих товарищей по команде?». Вместо этого спросите: к кому вы обращаетесь, если у вас есть проблема, которую вы не можете решить? Кто предоставил лучший творческий вклад в проект? и т. д. Ответы на такие вопросы могут дать гораздо лучшее представление о том, кто больше всего вкладывает в команду.

1
ответ дан 29 November 2019 в 06:07
поделиться

Я не согласен с концепцией «Измерение количества ошибок», даже если тестер находится внутри или снаружи.

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

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

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

Но ваша обязанность - разделить категории ошибок на подгруппы и присвоить им необходимый вес ... Я думаю, вы не можете сделать это сразу. Это «Определение» также должно со временем совершенствоваться с поправками .. :)

1
ответ дан 29 November 2019 в 06:07
поделиться

Отчеты об ошибках не только наводят на размышления, но и не сопоставимы. Насколько «большой» ошибка? Одна большая ошибка может быть хуже, чем наличие 5 маленьких ... с другой стороны, это может быть не так. Таким образом, вам нужно было бы разобраться в специфике каждой отдельной ошибки (что будет кошмаром).

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

Вы можете использовать инструменты lint и модульные тесты, чтобы улучшить качество кода без наказания. Первое - это относительно простое изменение процесса, над которым вы работаете с течением времени (начните с X предупреждений в существующей кодовой базе, а затем вознаградите людей, которые удалили наибольшее количество предупреждений за определенный период времени - превратите это в позитивное, а не в отрицательно).

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

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

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

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

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

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

1
ответ дан 29 November 2019 в 06:07
поделиться

We're professionals, like a lot of people. We also believe that we are artists, and in my opinion we are. Unfortunately (most) programmers are artists with a patron.

By saying that there's no viable metric to measure us is to say "just leave us alone and we'll do our job". That may apply to you, but how many coworkers have you had that you just wish you had a number to show how crappy they are? Subjectivity is nice and makes us all feel better, and creates a nice salary for the manager, but we do need some measure of programmer proficiency.

If we ourselves don't come up with something that makes management happy, then they will do the same thing as art patrons do. "I don't like it, you're fired".

World > Company > Product > Developer

As for a particular metric, I'm as lost as everyone else. The best I saw was the reopened bugs metric.

2
ответ дан 29 November 2019 в 06:07
поделиться

Хорошо сказано Крисом.

У нас была похожая проблема в нашем офисе. Генеральный директор и другие крупные парики не знали, как измерить качество разработки, и они реализовали свои собственные смешные измерения. Суммарное количество ошибок разработчиков, безусловно, не является измерением. Я не знаю, есть ли идеальный ответ, но я надеюсь, что моя работа измеряется тем, соблюдаю ли я свои сроки и обратную связь с потребителем (довольны ли они продуктом).

2
ответ дан 29 November 2019 в 06:07
поделиться

Сообщения об ошибках от разработчиков - ужасный показатель. Как руководитель QA, я снова и снова выступал против этого. Ошибки произойдут . То, как с ними поступают, когда они это делают, является более значимым.

Лучшим показателем является то, какова частота повторных открытий разработчиков. Другими словами, когда QA регистрирует ошибку, которая затем исправляется, исправлена ​​ли ошибка правильно, или что-то упущено, что заставляет QA повторно открыть ошибку?

Чем чаще это происходит, тем чаще разработчик, возможно, не обращает реального внимания на проблему. Это предполагает, конечно, что ошибка была разумно записана в первую очередь, желательно с шагами для воспроизведения, фактическим результатом, ожидаемым результатом и почему. Снимки экрана тоже помогают. 1258 Очевидно, что это всего лишь одна метрика для отчета. Другие возможности:

  • Соответствует ли разработчик обещанным срокам?
  • Отзывчивость к проблемам клиентов.
  • Точность любой необходимой документации.

и, возможно, др.

Редактировать: Я выполнил обе разработки и QA, и мне повезло, что во время разработки я не использовал подсчеты ошибок в обзорах. Я выступаю против этого в моей нынешней компании в моей нынешней роли, потому что это ненадежный показатель ИМО. Мы использовали показатель «открыть заново» как компромисс, чтобы высшее руководство (читай «заядлого» директора отдела разработки) было довольно тем, что у них есть что сообщить. Я не менеджер и на самом деле не создаю никаких отчетов самостоятельно (в случае, если это является причиной некоторых отрицательных голосов).

и, возможно, другие.

Редактировать: Я занимался как разработкой, так и тестированием, и мне повезло, что во время разработки мне не хватало количества ошибок, использованных против меня в обзорах. Я выступаю против этого в моей нынешней компании в моей нынешней роли, потому что это ненадежный показатель ИМО. Мы использовали показатель «открыть заново» как компромисс, чтобы высшее руководство (читай «заядлого» директора отдела разработки) было довольно тем, что у них есть что сообщить. Я не менеджер и на самом деле не создаю никаких отчетов самостоятельно (в случае, если это является причиной некоторых отрицательных голосов).

и, возможно, другие.

Редактировать: Я занимался как разработкой, так и тестированием, и мне повезло, что во время разработки мне не хватало количества ошибок, использованных против меня в обзорах. Я выступаю против этого в моей нынешней компании в моей нынешней роли, потому что это ненадежный показатель ИМО. Мы использовали показатель «открыть заново» как компромисс, чтобы высшее руководство (читай «заядлого» директора отдела разработки) было довольно тем, что у них есть что сообщить. Я не менеджер и на самом деле не создаю никаких отчетов самостоятельно (в случае, если это является причиной некоторых отрицательных голосов).

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

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

3
ответ дан 29 November 2019 в 06:07
поделиться

Это ужасный показатель по причинам, которые вы упомянули.

Кроме того, «внешние» сообщения об ошибках также несправедливый и ненадежный способ судить разработчиков - что если некоторые разработчики работают над областью кода, которая используется чаще других? Если моя функция используется моими 80% пользователей, а ваша - 1%, кто, по вашему мнению, увидит больше отчетов об ошибках?

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

3
ответ дан 29 November 2019 в 06:07
поделиться

Большая проблема, которую я вижу с сообщениями об ошибках из области, состоит в том, что программист, возможно, запрограммировал 100% к спецификациям, которые он был дан, а затем проблема в этой области была из-за плохих или неполных спецификаций.

Позвольте мне привести вам пример: вы разрабатываете и тестируете приложение на 32-битной Windows Vista, а затем происходит сбой на сайте клиента, где они работают. 64-битные Windows XP. Было ли это ошибкой программистов (особенно если вы никогда не давали ему машину с XP 64-битной версией для тестирования)?

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

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

5
ответ дан 29 November 2019 в 06:07
поделиться

The fundamental problem that I have with this type of rating system is that you end up with your team in competition with each other, rather than cooperating with one another. What would be the incentive to work on hard parts of the code if you knew that you might pay a penalty? Just pick the easier things that are less prone to errors. Why help your colleague improve their code when doing so benefits them and potentially harms you with respect to the rating system.

I think you are better off using peer pressure to increase code quality: no one wants to write crap and no one wants to be known for writing crap. Make a real effort to drive defects down with TDD -- or at the very least with unit testing. Move to continuous integration and publicize who breaks the build. Make it the responsibility of the person breaking the build to fix it before they can create any new code. Things like this will drive quality up.

Once everyone is on board with the quality goals, rate the team, not the individuals. Make it a real benefit to work cooperatively. If you have slackers who are taking advantage of the team -- and everyone will know who they are -- work with them to improve and if they don't or can't, cut your losses and find someone who fits better with the team. If you have the right people, it probably will never get to this point. If they're the wrong people, both you and they are better off knowing it and moving on to a better fit.

If someone on the team really goes above and beyond, reward them with something extra, but make sure it really was an extraordinary effort beyond the rest of the team. If that's the case, the team won't mind (too much) because they'll know that their shared reward was in large part due to that person's effort.

Obviously, all of the above should be taken as general rules. Although they like to call it management science, it's really more of an art. Understanding your team's dynamics is complicated business, but I think the general rule ought to be to encourage and reward teamwork.

11
ответ дан 29 November 2019 в 06:07
поделиться

alt text

22
ответ дан 29 November 2019 в 06:07
поделиться

alt text

33
ответ дан 29 November 2019 в 06:07
поделиться

Единственный реальный способ проверки качества - это проверить работу ... и измерить то, что проверено, и сумму переделки. Ошибки - это после того, как фактические способы измерения этого - и только одна метрика, но обзоры в процессе разработки лучше. Посмотрите на некоторые метрики, которые использует TopCoder .

1
ответ дан 29 November 2019 в 06:07
поделиться

Ошибки, найденные QA = хорошие. Ошибки, найденные клиентами = плохо.

Если вам нужно измерить разработчиков, используйте #bugs found ПОСЛЕ тестирования, т. Е. В коде Production / Release / 'on the disc'.

Тот же показатель для QA ... «одна команда - одна мечта».

Майкл

1
ответ дан 29 November 2019 в 06:07
поделиться

Эта идея просто заставляет меня хотеть /facepalm.

Ну, у меня самого был начальник 10 лет назад, который предложил платить мне за SLOC.

Я уволился в тот же день.

0
ответ дан 29 November 2019 в 06:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: