Расчет, сколько времени вы можете сэкономить, оценивая код, который вы пишете в год

Question

Я ищу реальные цифры и опыт, пожалуйста, не принимайте это слишком субъективно:

В поисках чего-то еще, Я happened on an interesting statement, который частично гласит следующее:

[...] в среднем по стране составляет 9000 строк кода в год на одного человека [...]

. 210

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

Для оценки экономии времени для крупных проектов мне нужны средние значения. Сколько строк кода делает человек писать через год, в среднем, на C# (или на другом языке выбора)? И, глядя на свою собственную ситуацию, считаете ли вы, что ваш написанный вручную код может (частично) быть автоматизированным и с какой выгодой?

Answer 1

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

Я также хотел бы отметить, что существуют довольно сложные модели, которые подверглись существенным исследованиям и даже измеряли реальные проекты, чтобы получить хотя бы некоторое представление о том, что их результаты коррелируют с реальностью.Например, модель COCOMO II, как правило, дает гораздо лучшие результаты, чем просто использование строк кода за единицу времени. Есть хотя бы один free online implementation (Edit: глядя на него, теперь это позволяет использовать LoC или функцию, основанную на точках). Существуют также такие инструменты, как SoftStar и Function Point Modeler), которые сочетают в себе модель COCOMO-like с функциональными точками, чтобы получить то, что кажется (по крайней мере для меня), чтобы быть довольно солидными результатами.

Answer 2

18000 будет составлять до 36 строк кода в день.

Всего 36 строк кода в день, в чем проблема? Проблема заключается в отладке и перезаписи кода.

НИЧЕГО, что вы можете сделать, чтобы автоматизировать кодирование, ускорит вас - на самом деле все, что вы можете автоматизировать, вероятно, не должно быть закодировано, потому что если вы автоматизируете типизацию некоторого шаблона в своем коде, его следует учитывать.

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

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

НЕ КАЖДЫЙ автоматизация ввода кода - если можно, вы делаете это неправильно!

Другой способ подумать об этом - каждая строка создаваемого кода должна быть отлажена и сохранена. Почему вы пытаетесь придумать способы дать всем БОЛЬШУЮ работу, когда вы можете просто создать полностью факторизованный код (ввод полностью факторизованного кода не может быть автоматизирован - в значительной степени по определению).

Answer 3

Это тип показателя, который обсуждался в Mythical Man Month. Оценка проектов в Man-Days/Months/Years или подсчет строк кода как производительности metirc гарантирует неточность в отчетности.

Answer 4

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

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

Answer 5

Я считаю, что курс для LOC сильно зависит от technical debt в проекте.

У меня есть проект (SQL), который составляет 27KLOC (плюс еще 4K для поддержки). Работая над этим кодом, более 7 месяцев я добавил в проект 3K net new LOC, около 14KLOC, написанных только для выборочного тестирования (тестирование для изоляции аномалий, а не модульных тестов).

В зависимости от того, как вы измеряете, я пишу 29KLOC/year ((3K + 14K)/7months * 12months), но производит только 5KLOC/year (3K/7months * 12months).

Рассматривая код (27KLOC) в качестве долгового обязательства, у нас есть код, который генерирует 7% (2KLOC) в металическом коде ежемесячно или 88% (24KLOC) в год.

Предполагая, что я могу продолжать получать целый 29KLOC/год, и если стоимость поддержания кода остается на уровне 88%/год, мой личный предел проекта составляет 33K строк кода. Помимо этого, я буду тратить все свое время на выплату процентов по моему техническому долгу, написание кода для раздачи и создание чистого нуля LOC.

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