Мифический месяц человека 10 строк на день разработчика - как близко на крупных проектах? [закрытый]
Вы можете просто написать что-нибудь быстро сами:
public static class Extensions
{
public static string ToCSV(this DataTable table)
{
var result = new StringBuilder();
for (int i = 0; i < table.Columns.Count; i++)
{
result.Append(table.Columns[i].ColumnName);
result.Append(i == table.Columns.Count - 1 ? "\n" : ",");
}
foreach (DataRow row in table.Rows)
{
for (int i = 0; i < table.Columns.Count; i++)
{
result.Append(row[i].ToString());
result.Append(i == table.Columns.Count - 1 ? "\n" : ",");
}
}
return result.ToString();
}
}
И проверить:
public static void Main()
{
DataTable table = new DataTable();
table.Columns.Add("Name");
table.Columns.Add("Age");
table.Rows.Add("John Doe", "45");
table.Rows.Add("Jane Doe", "35");
table.Rows.Add("Jack Doe", "27");
var bytes = Encoding.GetEncoding("iso-8859-1").GetBytes(table.ToCSV());
MemoryStream stream = new MemoryStream(bytes);
StreamReader reader = new StreamReader(stream);
Console.WriteLine(reader.ReadToEnd());
}
РЕДАКТИРОВАТЬ: Re ваши комментарии:
Это зависит от того, как вы хотите, чтобы ваш формат csv был отформатирован, но, как правило, если текст содержит специальные символы, вы хотите заключить его в двойные кавычки, например: "my, text". Вы можете добавить проверку в коде, который создает CSV для проверки специальных символов и заключает текст в двойные кавычки, если это так. Что касается .NET 2.0, просто создайте его как вспомогательный метод в своем классе или удалите слово this в объявлении метода и вызовите его так: Extensions.ToCsv (table);
10 ответов
Я думаю, что количество добавленных строк сильно зависит от состояния проекта, скорость добавления в новый проект будет намного выше, чем скорость начального проекта.
Работа у них разная - в большом проекте вы обычно тратите большую часть времени на выяснение отношений между частями и лишь небольшую часть времени на фактическое изменение / добавление. тогда как в новом проекте вы в основном пишете ... пока он не станет достаточно большим и скорость не снизится.
В одном из моих текущих проектов в некоторых модулях я горжусь тем, что внес отрицательное количество строк в базу кода. Определить, какие области кода стали ненужными и могут быть упрощены за счет более ясного и ясного дизайна, - полезный навык.
Конечно, некоторые проблемы по своей сути сложны и требуют комплексных решений, но в большинстве крупных проектов области с плохо определенными или меняющимися требованиями, как правило, имеют чрезмерно сложные решения с большим количеством проблем на строку.
Учитывая проблему, которую необходимо решить, я предпочитаю решение, которое сокращает количество строк. Конечно, в начале небольшого проекта я могу генерировать намного больше, чем десять строк кода в день, но я склонен думать не о количестве написанного мной кода, а только о том, что он делает и насколько хорошо он это делает.
Вам следует прекратить использовать эту метрику, по большей части она бессмысленна. Сплоченность, взаимосвязь и сложность - более важные показатели, чем строки кода.
Without actually checking my copy of "The Mythical Man-Month" (everybody reading this should really have a copy readily available), there was a chapter in which Brooks looked at productivity by lines written. The interesting point, to him, was not the actual number of lines written per day, but the fact that it seemed to be roughly the same in assembler and in PL/I (I think that was the higher-level language used).
Brooks wasn't about to throw out some sort of arbitrary figure of productivity, but he was working from data on real projects, and for all I can remember they might have been 12 lines/day on the average.
He did point out that productivity could be expected to vary. He said that compilers were three times as hard as application programs, and operating systems three times as hard as compilers. (He seems to have liked using multipliers of three to separate categories.)
I don't know if he appreciated then the individual differences between programmer productivity (although in an order-of-magnitude argument he did postulate a factor of seven difference), but as we know superior productivity isn't just a matter of writing more code, but also writing the right code to do the job.
There's also the question of the environment. Brooks speculated a bit about what would make developers faster or slower. Like lots of people, he questioned whether the current fads (interactive debugging using time-sharing systems) were any better than the old ways (careful preplanning for a two-hour shot using the whole machine).
Given that, I would disregard any actual productivity number he came up with as useless; the continuing value of the book is in the principles and more general lessons that people persist in not learning. (Hey, if everybody had learned them, the book would be of historical interest only, much like all of Freud's arguments that there is something like a subconscious mind.)
Легко получить пару сотен строк кода в день. Но попробуйте получить пару сотен качественных строк кода в день, и это не так просто. Добавьте к этому отладку и прохождение нескольких дней с небольшим количеством новых строк или без них в день, и среднее значение снизится довольно быстро. Я потратил недели на отладку сложных проблем, и в ответ я получил 1 или 2 строчки кода.
Не существует такой вещи, как серебряная пуля.
Единственная метрика вроде это само по себе бесполезно.
Например, у меня есть собственная библиотека классов. На данный момент верна следующая статистика:
Всего строк: 252,682
Строки кода: 127.323
Комментариев: 99.538
Пустые строки: 25.821
Предположим, я вообще не пишу никаких комментариев, то есть 127.323 строк кода. С учетом вашего соотношения, на написание этой библиотеки кода у меня ушло бы около 10610 дней. Это 29 лет.
Я определенно не потратил 29 лет на написание этого кода, поскольку он полностью основан на C #, а C # существует не так давно.
Теперь вы можете возразить, что код - это не совсем так. хорошо, поскольку очевидно, что я, должно быть, превзошел ваши 12 строк в день, и да, я согласен с этим, но если я сокращу сроки до того момента, когда была выпущена 1.0 (а я фактически не начал делать до выпуска 2.0), то есть 13 февраля 2002 г., около 2600 дней, в среднем 48 строк кода в день.
Все эти строки кода хороши? Черт возьми нет. Но до 12 строк кода в день?
Черт возьми
Все зависит от обстоятельств.
Вы можете иметь первоклассного программиста, производящего код порядка тысяч строк в день, и среднего программиста, производящего код порядка сотен строк в день, и качество будет таким же.
И да, ошибки будут.
Сумма, которую вы хотите, - это баланс. Количество измененного кода по сравнению с количеством обнаруженных ошибок, по сравнению со сложностью кода, по сравнению с трудностями исправления этих ошибок.
Я думаю, это происходит из дней разработки водопада , когда фактическая фаза разработки проекта могла составлять всего 20-30% от общего времени проекта. Возьмите общее количество строк кода и разделите на все время проекта, и вы получите около 10 строк в день. Разделите только на период написания кода, и вы приблизитесь к тому, что люди цитируют.
Я думаю, что размер проекта и количество задействованных разработчиков являются важными факторами при этом. Я намного выше этого за свою карьеру, но все это время я работал один, так что работа с другими программистами не теряется.
Кто-то подозревает, что этот многолетний кусок конфетного менеджера был придуман, когда все было системным приложением, написанным на C, потому что, если бы ничего другого, магическое число могло бы меняться на порядки в зависимости от языка, масштаба и характер приложения. И тогда вам придется сбрасывать со счетов комментарии и атрибуты. И, в конечном счете, кого волнует количество написанных строк кода? Вы должны закончить, когда наберете 10 тысяч строк? 100К? Так произвольно.
Это бесполезно.
Стив МакКоннелл приводит интересную статистику в своей книге «Оценка программного обеспечения» (стр. 62, таблица 5.2). Он различает типы проектов (Avionic, Business, Telco и т. д.) и размер проекта: 10 kLOC, 100 kLOC, 250 kLOC. Номера даны для каждой комбинации в LOC/StaffMonth. НАПРИМЕР. Авионика: 200, 50, 40 Интранет-системы (внутренние): 4000, 800, 600 Встроенные системы: 300, 70, 60
Что означает: например. для проекта Avionic 250-kLOC их 40 (LOC/месяц) / 22 (дня/месяц) == <2LOC/день!