ИТ-оценка качества кодирования - как мы знаем, что хорошего?

Ответ 1

Отличный вопрос. Должны получить хорошие ответы.

• Чистота кода (с отступом, организация файлов, структура папок)
• Хорошо прокомментировал (не только встроенные комментарии, но и переменные, которые говорят, что они есть, функции, которые говорят, что они делают и т.д.).
• Малые понятные функции/методы (без сумасшедших 300-строчных методов, которые делают всевозможные вещи с вложенными, если логически повсюду)
• Выполняет SOLID принципы
• Является ли количество unit test кода похожим по размеру и качеству в качестве базы кода проекта
• Код интерфейса отделен от кода бизнес-логики, который, в свою очередь, должен быть отделен от кода доступа к инфраструктуре (электронная почта, база данных, веб-службы, файловая система и т.д.).
• Что инструмент анализа производительности считает кодом (NDepend, NDoc, NCover и т.д.).

В этом есть много чего... но это заставляет вас начать.

Ответ 2

Код имеет две основные аудитории:

• Люди, которые его используют
• Люди, которые его развивают

Итак, вы выполнили 2 простых теста:

• Запустите код. Можете ли вы заставить его выполнять работу, которую он должен выполнять?
• Прочитайте код. Можете ли вы понять общие намерения разработчика?

Если вы можете ответить "да" на оба из них, это отличный код.

При чтении кода не беспокойтесь, что вы не программист. Если код хорошо написан/задокументирован, даже не-программист должен уметь многое из того, что он должен достичь.

Кстати: Большой вопрос! Я желаю, чтобы больше не программистов заботились о качестве кода.

Ответ 3

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

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

В некоторых ваших конкретных точках сложность и размер функции работают хорошо, равно как и покрытие кода во время повторяемого (единичного) тестирования, но в последнем пункте есть оговорка: если вы не работаете над чем-то, где высокие стандарты качества являются необходимость (встроенный код, например, или критически важный для безопасности код) 100% -ный охват кода означает, что вы тестируете 10% кодовых путей, которые стоит тестировать, и 90%, которые почти никогда не кодируются неправильно. Достойные тесты - это те, которые обнаруживают ошибки и улучшают ремонтопригодность.

Ответ 4

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

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

Ответ 5

как я могу оценить, хорошо ли написано кодирование

Существуют различные способы/метрики для определения "хорошего" или "хорошего", например:

• Поставляется вовремя
• Поставляется быстро
• Без ошибок после доставки
• Простота установки
• Хорошо документировано
• Быстро запускается
• Использует дешевое оборудование
• Использование дешевого программного обеспечения
• Не стоило много писать
• Простота администрирования
• Простота использования
• Легко изменить (т.е. добавить новые функции)
• Легко переносить на новое оборудование
• ... и т.д...

Из них программисты склонны оценивать "легко меняющиеся": потому что их задача - изменить существующее программное обеспечение.

Ответ 6

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

• укажите требования к производительности: транзакции в секунду, время отклика, ожидаемые записи БД во времени,
• требуют, чтобы доставка включала результаты из инструмента анализа производительности.
• укажите, на каком устройстве будет работать приложение, вам не нужно обновлять свое оборудование для запуска приложения

Для просмотра кода и разработки того, насколько хорошо он написан, он более жестко отвечает на вопросы от @Andrew и @Chris... вы хотите, чтобы код выглядел хорошо, прост в обслуживании и работает.

Ответ 7

Резюме

Используйте Joel Test.

Почему?

Спасибо за жесткий вопрос. Я собирался написать длинный ответ о достоинствах прямой и косвенной оценки кода, понимая ваш организационный контекст, перспективу, выясняя процесс и устанавливая критерии для кода, чтобы быть достаточно хорошим, а затем разница между совершенным кодом и просто что еще может означать "очень впечатляюще". Я собирался обратиться к Code Steve McConnells Complete и даже предложить делегировать аудит кода кому-то беспристрастному, которому вы можете доверять, кто достаточно разбирается в бизнесе и программировании - чтобы понять суть контекста, взглянуть на перспективу, применять критерии разумно и отчетливо отчитываться о результатах. Я хотел бы порекомендовать взглянуть на части пользовательского интерфейса, которые, как правило, недоступны конечным пользователям, так же, как можно было бы оценить качество очистки, проверяя наличие грязи в труднодоступных местах.

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

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

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

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

Это подводит меня к фактическому выводу или фактически к двум:

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

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

Хорошо, как мы знаем, что компания-разработчик права? Здесь я полностью соглашаюсь с философией, благовествованной Джоэл Спольский: качество программного обеспечения напрямую зависит от качества вовлеченных людей, что, как и было, , указанный несколькими исследованиями, может меняться на порядок. И благодаря работам свободных рынков разработчики в конечном итоге группируются в компании, исходя из того, насколько конкретная компания заботится о привлечении и сохранении их.

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

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

Решение состоит в том, чтобы искать компанию, в которой таланты разработчика более согласованы, и каждый, по крайней мере, достаточно хорош для получения правильного качества кода. И когда дело доходит до выбора такой организации, где Joel Test становится очень удобным. Я считаю, что он особенно подходит для применения кем-то, у кого нет опыта программирования, но хорошим пониманием ИТ и управления.

Чем больше баллов компания оценивает на Joel Test, тем больше вероятность привлечь и удержать хороших разработчиков и, самое главное, предоставить им условия для создания качественного кода. И поскольку большинство великих разработчиков действительно влюблены в программирование, все, что нужно, нужно объединить, учитывая хорошую и благоприятную рабочую среду, заслуживающую доверия цель (или даже лучше невероятную), и они начнут выкапывать высококачественный код. Это просто.

Хорошо, единственная вещь, что компания, которая набирает полные двенадцать баллов в Тесте Джоэлса, скорее всего, будет взимать больше, чем потогонная игра, которая насчитывает всего 3 или 5 (самооценка в среднем по отрасли). Однако выгоды от синергии эффективных операций и беспроблемного программного обеспечения, которые используют стратегические организационные цели, несомненно, будут иметь исключительную отдачу от инвестиций и преодолеть любые барьеры, значительно перевешивающие любые затраты по проекту. Я имею в виду, что в конце дня работа компании, скорее всего, будет стоить денег, каждый пенни.

Также надеюсь, что кто-то найдет этот длинный ответ стоящим.