ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
20 мая
92977 Топик полностью
Evgeny_CD (01.07.2007 12:40, просмотров: 1) ответил bialix на "3. Уменьшение затрат времени на превращение кода в товарный продукт. Написал человек модуль. Писать доку ему лень, а при помощи такой технологии он быстро превратит код в юзабельный продукт." -- если человеку писать доку лень, то и такой системой он
Категорически не согласен! Мое понимание философии "Thinking in VIM", так сказать. Если пользоваться традиционной технологией, то при написании драйвера для чипа с багом надо: 1. Описать баг своми словами 2. Описать, как он исправлен. И то, и другое - полный маразм. При практической разработке новые баги в серийных контроллерах встречаются не часто, как правило, они уже задокументированы. И нафига мне делать ту же работу, которую атмел сделал??? Понятно, что облом, который не дает 90% людей писать такие каменты - это здоровая защитная реакция природы. Ибо если бы ее не было, все программеры потраили бы все силы на написание каментов, а как бы они тогда размножались? :) Иправление бага. Если понятно, в чем состоит баг, и из кода непонятно - как его исправили, то надо сменить либо пишушего код, либо читающего. Либо обоих сразу :) Только иногда для полной ясности нужно добавить всего несколько слов "человеческого" комента. Если воспользоваться проектируемой технологией, то: * для достижения того же результата нужно сделать гораздо меньше нажйтий на клавиши * качество редультата будет лучше (ничето не заменит фирменную доку) * вроде как просматриваетеся совместимость со всеми редакторами. Итого резюме: * при традиционной технологии описание борьбы с багами - это написание стека TCP/IP на асме. Можо, но нафига??? * при проектируемой технологии все будет быстрее и проще.