|
|
Вот два примера.
Приходит ко мне заказчик и говорит: "Хочу 5 шт таких-то девайсов. Главное, чтобы работали, и снаружи смотрелись ОК (если внутри будет eval борда с проводками, меня не волнует). Полгода тестируем - далее 100 шт/мес в течении года. Вот договор.".
Составляем ТЗ и я вижу, изделие довольно сложное, но 80% софта этого девайса было сделано в разное время в других проектах. И надо взять LPC2ххх, написать эти 20%, прикрутить остальные 80%, и получить деньги за 5 коробочек. Будет договор на 100шт/мес - хоть на асме для 51 перепишем. Но сейчас надо 5 штук сделать с маленькой прибылью (или в 0, но не в -), чтобы не было обидно, если вторая часть договора не получится.
Смотрим на 80% - и офигеваем. Писались они в течении 5 лет, разными людьми, почти все на AVR, но под разные компилеры, на асме, в разном стиле и т.д. Кто-то из программеров уволился, рад переработать код, но только по выходным. Другой вообще по другую сторону Атлантики нынче живет, и ему это уже не интересно.
Мои действия:
1. Считаем себестоимость разработки девайса "почти по новой". Почти наверняка пролет по деньгам.
2. Пытаемся "по-бырому", глядя во все эти разношерстные исходники, переписать все на С. Без ошибок не получится, значит надо тщательно тестировать. Если этого не сделать - из-за глюков заказчик почти наверняка не пойдет на вторую часть договора (или вообще стрелку забьет). Если сделать - себестоимость разработки почти как в П.1
3. Хоть раз в жизни, потратить время и деньги, и заложить нормальную философию. Чтобы код портировася под разные компилеры (даже с разной индианностью), и был хорошо структурирован.
4. При приходе большого заказа переписывать с С на АСМ, а не на оборот (тем более, я просто убежден, что это придется делать не для всего проекта, в для нескольких функций).
На вопрос "Водка, девочки, LPC" отвечаю: цена LPC (LPC как класс, SAM64, ARM от ST т .д.) как кристалла несущественно (для партий до 10 штук) отличается от всего остального; если говорить о плате (тектстолит, пайка, резюки/кандюки), то отличие можно увидеть только под электронным микроскопом. Так зачем выбирать худшее, только потому, что к нему привык?
Пример №2.
Есть у нас изделие - пейджинговый терминал. На входе некий протокол по RS-232, на выходе POCSAG в виде битового потока на пине, и Bell 202 с "добавками" по каналу тональной частоты.
Сделан этот замечательный девайс был в 1995 году на 51FA от Intel, в 1996 году был переделан под 51GB (тогда это был самый крутой кристалл - от него дух захватывало). Писалось все на асме.
Все бы хорошо, но некоторые желтопузые пейджеры как-то по своему трактуют стандарт POCSAG, и код его генерации пришлось править на протяжении почти двух лет. По мелочи, но это были очень тонкие глюки, которые присходили редко, и в лаб. условиях нам их не удавалось повторить. Тоже касается протокола TRC (тот самый Bell). Выправили. __В течении 5 лет на 1000+ работающих изделий (24/7/365 - связь все-таки!)_ не было найдено ни одного бага.
И вот уже лет 5 мы с содроганием занимаемся некрофилией (одно добывание 51GB чего стоит!). Тираж сейчас - несколько десятков в год. Снять с производства - жалко, все-таки деньги (тех процесс производства доведен до автоматизма). Переписать - не окупится.
Сейчас есть закзачик, который хочет этот терминал + еще набор фич. Самое время перевести его на LPC (фичи касаются всяких коммуникационных протоколов, включая PPP, так что LPC самое то, PIC/AVR/51 немного не то (есть PPP и для них - но это не знавит, что эти платформы надо юзать)). Но как вспомню процесс отладки (а у нас уже нет коллекции пейджеров) - так страшно становится. Опять же, сейчас нет возможности продать первые терминалы заказчику в "10 концов", и окупить все и вся.
Вот и хочется мне хоть раз в жизни построить процесс разработки "по уму". И я убежден, что если я сам этому научуть - смогу и остальных членов команды "совратить" на это.
E-mail: 
info@telesys.ru
