Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Спильный Андрей, Вы писали:
СА>>вы точно уверены, что "winsock придуман в Berkley"?
AVK>В Беркли, естественно не конкретно WinSock придумали
уже легче...
а то предыдущий пост воспринимался как "динозавры произошли от украинцев"
AVK>, а sockets API. А winsock это его вариант, реализованный в Windows. AVK>http://en.wikipedia.org/wiki/Berkeley_sockets
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Друзья, без обид... Но после прочтения вашего короткого но бурного диалога, возникло ощущение, что один из вас является прототипом другого...
VD>Какой ты мне друг?
Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
VD>Но обижаться действительно просто не на кого.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>У меня это норма, и не после часов, а и иногда после дней. Иногда все 100% корректно, иногда вылавливается пара мелких багов, но в общем и целом bug rate практически не выше, как на уже релизнутом продукте — т.е. баги поступают, куда без них, но очень медленно и понемногу.
Долго думал, но не верится что-то...
Какое количество багов у вас приходится на 100 строк кода и сколько строк за день вы пишете (на каком языке и насколько формализовано задание)?
FDS>Какое количество багов у вас приходится на 100 строк кода и сколько строк за день вы пишете (на каком языке и насколько формализовано задание)?
Максимально, в режиме "написать с нуля крупную компоненту с полностью понятными мне требованиями", в великолепном настроении итд — бывали случаи и по 2000 строк в день (включая комментарии, коих у меня немало), но вот это уже потолок, за которым часто следует день полной неработы башки.
Язык как правило Си. В коде, которым я занимаюсь последние 3 года, всего 2 файлика на Си++, где надо звать сложную COMовскую подсистему от MS. Ах, еще дебаг аллокатор есть на Си++ для юнит-тестов, зовется из Си
Задание никогда не формализовано, мне это не нужно. Но мне всегда понятны все требования к вновь разрабатываемой компоненте.
Обычно на 1500-2000 строк потом 2-3 бага находятся при первоначальном тестировании мною же, потом 2-3 бага при "плотном".
После написания с нуля крупного куска кода обязательно делаю передышку и потом код вычитываю. После небольших патчей обязательно вычитываю в режиме сравнения на source control.
Все остальное, что нужно сделать с этой компонентой — это полу-баги типа "не обрабатывает вот такой вот corner case", или "мы хотим более детальный вывод в лог", или "локализуйте нам лог на японский" (код написан за 2 дня и отлажен на примере русского , после чего переводчик перевел пару сотен английских сообщений на японский и прислал мне обратно файл со stringtable resource).
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>это полу-баги типа "не обрабатывает вот такой вот corner case", или "мы хотим более детальный вывод в лог", или "локализуйте нам лог на японский"
странно, я почему то считал, что это зовется фичреквест...
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Максимально, в режиме "написать с нуля крупную компоненту с полностью понятными мне требованиями", в великолепном настроении итд — бывали случаи и по 2000 строк в день (включая комментарии, коих у меня немало), но вот это уже потолок, за которым часто следует день полной неработы башки.
Меня интересует средняя производительность
MSS>Обычно на 1500-2000 строк потом 2-3 бага находятся при первоначальном тестировании мною же, потом 2-3 бага при "плотном".
Т.е. вы утверждаете, что не используя никакой формальной методики вы получаете за несколько дней работы (включая отдых, анализ кода, но не включая написание тестов), например, 1000 строк кода примерно с 6 дефектами? При этом нет какого-либо заранее согласованного алгоритма работы программы и во время кодирования эти алгоритмы и разрабатываются...
При этом я считаю дефектом, в частности, некорректную обработку исключений и неправильного ввода данных (по крайней мере, должна быть какая-то проверка, что ввод правилен) и вообще любой недостаток программы, выявленный после её компиляции, в том числе на тестах. Естественно, нереализованная функциональность, которая и не планировалась к реализации, не в счёт — это не дефект, это Change Requirements
Какой критерий покрытия вы используете для тестирования?
Вообще говоря, при хорошей скорости программирования (если не выше), получается слишком мало багов (у меня 2,3 — 8 дефектов на 100 (сто) строк кода в зависимости от языка и способа программирования). Если речь не идёт о простейших компонентах, то совершенно непонятно, как такое достигается. Было бы интересно подробнее понять как вы пишете код или взглянуть на него самого, если есть такая возможность.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
Интересный такой оттеночек. Бросаешь грязи и для предания оттенка добавляшь "дружище!" .
VD>>Но обижаться действительно просто не на кого.
KV>А (если не секрет), на чем основано это суждение?
На разных факторах. Например, на твоих сообщениях... Ну, вот еще на основании того может ли человек себе такое позволить или нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
VD>Интересный такой оттеночек. Бросаешь грязи и для предания оттенка добавляшь "дружище!" .
О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
VD>>>Но обижаться действительно просто не на кого.
KV>>А (если не секрет), на чем основано это суждение?
VD>На разных факторах. Например, на твоих сообщениях...
Т.е. читая мои сообщения, ты во мне не увидел профессионала либо личность, либо и то и другое, я правильно понимаю?
VD>Ну, вот еще на основании того может ли человек себе такое позволить или нет.
Влад, если я тебя как-то задел этой шуткой — искренне и здесь же приношу свои извинения, т.к. это не было целью того сообщения. Это я себе тоже могу позволить
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
Может ты что-то и подразумевал, но это осталось у тебя в мозгах. А на поверку получилось, то что получилось. Надеюсь я понятно выражаюсь?
Что касается резкости, то согласен. В конце я был резок. Но ёрш тваю меть (с) я перед этим несколько сообщений кидал ссылки (долго роясь в гугле чтобы их найти) и объяснял вполне доходчивым и мягким языком. Но упертость оказалась потрясающая. Даже, казалось бы, прозрачное описание подвергалось реинтерпретации в совершенно причудливой форме.
KV>Т.е. читая мои сообщения, ты во мне не увидел профессионала либо личность, либо и то и другое, я правильно понимаю?
Я не увидел сообщений по делу (форумы то для программистов). Ну, может я не все видел. Юмор оценил.
KV>Влад, если я тебя как-то задел этой шуткой — искренне и здесь же приношу свои извинения, т.к. это не было целью того сообщения. Это я себе тоже могу позволить
Я воспринял эти слова как оценку моих слов в техническом плане. Я конечно могу что-то забыть, но все же с виндой я с тех пор когда она еще была 3.0 и всю историю НТ и 9х я прошел на собственной шкуре. И когда мне намекают, что я несу точно такую же чушь как мой оппонент, то я действительно обижаюсь (уж извиняюсь за очередную грубость).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Хм это конечно интересное историческое дерево, но его как-то не видно на форумах (я не заметил), да и история ОС не офтопом будет разве что в философии или вообще о жизни. Ладно, проехали. Я действительно был несколько обижен, и сотоветственно груб. Приношу свои извенения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
VD>Может ты что-то и подразумевал, но это осталось у тебя в мозгах. А на поверку получилось, то что получилось. Надеюсь я понятно выражаюсь?
VD>Что касается резкости, то согласен. В конце я был резок. Но ёрш тваю меть (с) я перед этим несколько сообщений кидал ссылки (долго роясь в гугле чтобы их найти) и объяснял вполне доходчивым и мягким языком. Но упертость оказалась потрясающая. Даже, казалось бы, прозрачное описание подвергалось реинтерпретации в совершенно причудливой форме.
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно RRM>Собственно вопрос — что дальше? что делать с этим прототипом?
Надо смотреть индивидуально. Но вообще по моему лучше писать заново, и в случае целесообразности портировать некоторые куски кода в рабочую версию. Обычно после написания прототипа возникает куча новых идей, взгляд на ряд вещей существенно меняется и желание дорабатывать прототип пропадает само собой. Обычно портируется только самый тупой код, который скрывается за каким-нибудь фасадом с пометкой "переписать когда нибудь" .
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Это уже отдельный вопрос. Самое ужасное, если вы перестарались и прототип работает . Тогда начальство может встать в позу "типа рабочая система, нафига переписывать". Причём даже после согласия на переписывание может переодически тыкать на каждый баг/недоработку, что мол вот была рабочая система, вы зачем то настояли на переделки и теперь у вас куча ошибок.
C>теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
Это старая теория. Потом придумали рефакторинг и эволюционное прототипирование. Всё течёт, всё изменяется.
Но бывают случаи, когда прототип настолько абстрактен или нетехнологичен, что его проще выбросить.
Иногда прототипируют на бумаге. Такой прототип сложно использовать в продукте
AP>Основной аргумент против доделок — прототип делается, чтобы быстро дойти до работоспособного варианта, а не до рабочего. Объем доработок и/или исправлений может быть сравним или превысить объем работы необходимый для полного переписывания прототипа.
Это тоже устарело. Не пишите на таком языке, на котором страшно делать прототип. Ибо мазохизм.
Здравствуйте, VGn, Вы писали:
C>>теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
VGn>Это старая теория. Потом придумали рефакторинг и эволюционное прототипирование. Всё течёт, всё изменяется.
Нет ничего лучше хорошей выдержаной теории
Так что ничуть ни устарело.
Прототип лучше писать на легком гибком языке (например python, schema или haskell) и нисколько ни думая о реюзе. Рефакторинг кстати придумали не для этого.
VGn>Но бывают случаи, когда прототип настолько абстрактен или нетехнологичен, что его проще выбросить. VGn>Иногда прототипируют на бумаге. Такой прототип сложно использовать в продукте
.
