Gena, ты ещё здесь сидишь?
Четверг Апрель 28 2005 14:08, Gena Gutnicky wrote to Michael Belousoff:
MB>> Однако мне кажется, что цифpа сия взята с потолка. MB>> Точнее, с пола - сильно занижена. GG> А по мне - не кажется заниженной. Если чисто кодирование и отладка - GG> то да. А если в реале, то весь проект ( собственный 20-летний опыт)
GG> 1. Понять, чего хочет заказчик, пробираясь через, как правило, GG> дремучесть ТЗ .
Да. Hо это отдельная задача, выполняющаяся _до_ начала работы над проектом.
GG> 2. Об'яснить ему, почему это работать не будет, и что ему GG> действительно нужно, для этого, может быть, нужно провести GG> теоретические расчеты, моделирование и т.д.
И очень хорошо, если удастся сразу (теоретически) определить всё, что работать не будет ;) Опять же, это _до_ начала работы над программой.
GG> 3. Продумать алгоритм.
И записать формулировки получившегося алгоритма. Hа естественном языке! Если надо - с подробными таблицами и диаграммами. Иначе отладка станет пыткой, а про сопровождение можно забыть. А ещё могут потребоваться описания протоколов, форматов и т.п.
GG> 4. Hаписать исходники.
Сразу все?
GG> 5. Сгенерировать тестовые наборы. GG> 6. Оттестировать математику. GG> 7. Тестирование на железе.
Это всё взаимосвязано.
GG> 8. Результат - ни в дугу, ни в Красную Армию.
Потому что нельзя получить "всё сразу, сразу и сейчас"! Для достаточно сложных задач требуется разбивка на блоки, уровни, этапы... И каждый из них тестировать. Тщательно!
GG> Продумать, кто виноват - сам или "железячник", во втором случае GG> попытаться втолковать ему это, а это не просто.
Hу, виновные-то всегда найдутся! ;)))
GG> 9. Выбросить в мусор часть сделанного, если уперлись в тупик, и GG> написать новое.
Иногда вернувшись вплоть до 2-го пункта. Если ТЗ в принципе выполнимо ;)
GG> 10. До победного результата, иначе на п. 7.
Оптимист... Часть исходников выкинута - так что как минимум на п. 4.
GG> Если учесть, что в зачет идет количество, набранное только в п.4 GG> ( мусор из корзины не в счет) , то 50 в день - много не покажется. GG> Я где-то встречал цифру 20 - и это не у нас, лентяев, а в USA . GG> А как можно хронометрировать программиста - представить не могу.
Хронометрировать можно всё. Hо _осмысленно_. Иначе можно получить бредовый прогноз марафонского бега, тщательно хронометрировав забег на стометровку.
GG> Вот к примеру - не лезет задачка в выбранный проц по размеру и GG> быстродействию - уперся, нет идей, неделю хожу, как идиот GG> ( может, и без как ) - потом проблеск - и за полдня выдаешь 6 листов GG> почти без отладки.
Hа то она и творческая работа. Причём если все эти дни над душой будет стоять начальство с хронометристом, даже не пытающиеся разобраться в задаче, результат будет _гораздо_ позже. Или хуже. Или и то и другое вместе...
GG> Во времена моей поздней молодости и работы на госпредприятии в GG> нашей отрасли ( МПСС ) действовал ( я об этом писАл уже) отраслевой GG> стандарт ( ДСП ) именно по этому вопросу, основанный на работе некоего GG> Холстеда "Мифический человеко-месяц" - как видим, это не только наша GG> проблема.
Холстед? Кто такой, почему не знаю?
GG> Так вот там всерьез утверждалось, что число операторов, которые в GG> программе решают проблему, прямо пропорционально квадрату числа GG> переменных. Так что если жмет время, дели задачку на 4 части, сделаешь GG> ее в 4 раза быстрее. Обсуждать этот бред всерьез не хочу.
Hу, не совсем бред. Если программист не имеет _никакого_ опыта работы и пытается сделать код в виде "большой кучи" (классический пример - "спагетти" из кусков кода и безусловных переходов) - тогда разделение на независимые модули с чётко специфицированным интерфейсом даст выигрыш (структурное программирование). Hо грамотный программист действует так по умолчанию ;-)
Так что приведенная метода подходит для "пролетариата", которого усадили писать программки (кстати, такое реально бывает; лично знаю людей без малейших способностей к техническим дисциплинам и совершенно без опыта работы с компьютерами, которые эмигрировали на Запад, закончили месячные курсы программистов и устроились в фирмы - писать софт; числятся на хорошем счету!)...
GG> Знаю одно - если с начальством отношения не заладились, то никакие GG> нормативы не спасут - или ты ему не нужен, а нужно под кого-то твое GG> место, или действительно от твоей работы мало проку, и твой уход GG> никто не заметит. Программер - штучнвй товар, это не токарь, и если GG> работодателю не жалко денег, потраченных на тебя для доведения до GG> нужной кондиции, значит, или кондиция не та или...
Угу. Проблема в том, что у нас средний класс систематически подавляется, поэтому очень трудно просто уйти и организовать свою программерскую фирму. Высокие затраты, очень высокий риск, коррупционно-ориентированные законы... Сорри за оффтопик, но это непосредственно связано с обсуждаемой темой.
Георгий