Вычисление, сколько времени можно сэкономить путем оценки кода, который Вы пишете через год [закрытый]
4 ответа
Во-первых, строки кода написаны плохо коррелируют с фактической производительностью. По крайней мере, на мой взгляд, если вы хотите измерить и / или оценить производительность, точки функции являются более эффективным измерением. Во-вторых, когда метрика зависит от широкого диапазона, среднее значение обычно очень мало значит. В этом случае, как это, геометрическое среднее значение, как правило, означает больше, чем среднее арифметическое, но без (по крайней мере) что-то о дисперсионном / стандартном отклонении, он все еще много значит.
Я также отметил, что существуют несколько довольно сложных моделей, которые претерпели существенные исследования и даже измеряются в отношении реальных проектов, чтобы получить хотя бы некоторую идею, что их результаты коррелируют с реальностью. Например, модель Cocomo II , как правило, приведет к гораздо лучшим результатам, чем просто используя строки кода на единицу времени. Есть хотя бы один бесплатная онлайн-реализация (редактирование: Глядя на него, теперь это позволяет моделирование на основе POC или функциональной точки). Существуют также такие инструменты, как Softstar и функциональная точка Modeler ), которые сочетают в себе модульную модель с функциями, чтобы получить то, что появляются (по крайней мере для меня), чтобы быть довольно твердыми результатами Отказ
18000 в среднем до 36 строк кода в день.
С только 36 строками кода в день, в чем проблема? Проблема отладка и переписывая ваш код.
Ничего, что вы не можете сделать, чтобы автоматизировать кодирование, будет ускорить вас - на самом деле, все, что вы можете автоматизировать, вероятно, не должен быть закодирован, потому что если вы автоматизируете ввод какого-либо шаблона в вашем коде, это должно быть учтено.
Где вы можете сэкономить время, - это быть более осторожным о том, как вы код. Получите ваш проект через QA немного быстрее - код в более четко более четко, типографский язык и код более четко.
Также делая ваши кодовые данные, приводимые в действие и полностью фактически, хотя это возможно, хотя он уменьшит SC, у вас будет упростить жизнь каждого проще, а проектный корабль быстрее.
Не всегда автоматизируйте ввод кода - если вы можете, вы делаете это неправильно!
Еще один способ подумать об этом - каждая строка кода, которую вы создаете, должен быть отлажен и поддерживается. Почему вы пытаетесь придумать способы дать всем больше работать, когда вы могли бы просто создать полностью забитый код (вход полностью заметного кода не может быть автоматизирован - почти по определению).
Это тип метрики, о котором говорится о мифическом месяце Mythical Man Manage . Оценка проектов в человеческих днях / месяцах / годах или подсчет линий кода в качестве производительности METIRC гарантирует неточность в отчетности.
Это скорее бс вопрос, на самом деле. Даже преданные SLOC будут признаться вам, что оценки производительности SLOC действительны только в аналогичных средах. Он не только варьируется в зависимости от языка программирования, но по отраслям, средам развития, приложении и т. Д.
в целом, поскольку числа SLOC стоит того, то это только в рамках одной команды разработки, работающих над аналогичными проектами.