Средства и методы разработки

"Неправильно ты, дядя Федор, бутерброд кушаешь!" Моск - слишком мощная штуковина. Использовать его надо аккуратно. Блин, програмная писанина получилась - просто предвыборная программа кандидата от партии "Эмбеддеры России" :))) 1. Писать доку в классическом варианте - взял исходник и начал писать, как он работает - полный маразм. Манагера в фтопку. 2. Дока скорее нужа внешним (по отношению к модулю) людям. Самим себе она нужна, чтобы разобраться спустя время. 3. Полностью написанная дока автогенератором типа doxygen - нужна не всегда, а только при суровой оптимизации кода. Как учит теория TDD, такая оптимизация нужна только тогда, когда станет ясно, что именно в этот модуль все и уперлось. Для этого надо хотя бы каркас проекта до конца написать. Чтобы доксиженовские коменты не парили моск, делаем custom colorer, чтобы он его коменты "засеревал", например. Мешать будет гораздо меньше. 4. Полностью автоматическая генерция доки - красиво, но либо очень сложно, либо хреново. Вполне можно сделать полуавтоматом. * парсим файлы ctag * сортируем сущности, выделяем в нем "яркие точки" (то, что важно для логики работы модуля и его отношений с внешним миром) Все внутренние второстепенные вещи должны быть скрыты до поры ло времени. * вокруг этих ярких точек чуть-чуть текста (в иделе название яркой точки должно говорить само за себя) * рисуем графы -- выбранные яркие точки в виде лист бокса -- связь между выбранными точками -- Граф строится далее специальным скрпитом. 5. Закладываться на одну ОСь и молиться на ее API перед обедом - неверно. Менять ОСи как перчатки - типа сегодня модно писать под... - тоже. IMHO, как минимум, надо иметь в виду 4 класса осей: * tiny (что-то типа FreeRTOS, scmRTOS, TaskLib Crossworks) * mid-range (uCOS, TNKernel) * POSIX-lite (RTEMS, eCos) * POSIX-full (Linux, BSD) Добиваться полной совместимости всех модулей со всеми ОСями - полный маразм, но в общем и целом должно быть пространство для маневра. Без необходимости в модулях не стоит использовать специфические для каждой ОСи сущности. Стратегически важно, чтобы все эти оси имели синтетический порт для Win32. Тогда процесс отладки по многом (очень во многом! Я сам этого долго не понимал!) можно проводить без железа. Как следствие, программер может сидеть где угодно. 6. Вообще, главное, освободить моск от дурных шаблонов. Чтобы при написании чувствовать себя свободно. Не потому, что нифига не знаешь, а потому, что знаешь варианты действий во всех случаях. 7. Test units. Я не знаю пока до конца, как это сделать, но чувствую, что должен быть способ очень быстрой разработки оных. И их надо делать обязательным стандартом. Написал функцию - тут же на некоем языке описал, как ее тестить. Сам framework (как C часть, которая дрочит модуль, так и генератор -анализатор воздействий) должны генериться автоматом! При современной инфраструктуре симуляторов и эмуляторов прогнать тут же этот тест в фоне (пока пишешь другую функцию) и понять, что ты такое написал в коде и тесте - это должно быть так же естествено, как потянуться, сидя за рабочим столом. Синтетические порты сильно помогут! 8. В рамках компании нужно стандартизовать не так уж и много вещей * SVN * набор компилеров и сред - именно набор! * тулзу для сборки проекта - Scons, например. Она должна быть одна! * автоматизацию всех действий - на python, например. Способ должен быть одни! * основные сущности при рисовании графов модулей. Можно не следовать UML, важно, чтобы все понимали, что эта загогулина значит. Обязательно иметь инструкцию, и выделять время для ее регулярного обновления, как создать рабочую среду у себя на рабочем месте. Со всеми тулзами :). Это важно как для новичков команды, так и для старичков, который рещат уйти в отпуск. В общем и целом, придерживаться некоей системы организации директорий. Одна на все проекты! 9. Самое главное! При применении реальной концепции на практике, отслеживать 4 вещи: * затраты усилий на достижение цели проекта * затраты усилий, чтобы достичь цели проекта не противореча концепции * затраты на разработку и тестирвоание новой концепции, риски ошибок на этом пути * затраты на переделку всего в рамках новой концепции или адаптации старой работы под новую концепцию. И в каждой точке делать вывод о необходимом следующем шаге. 0000. Учить скриптовые языки. Форматировать моск для того, чтобы везде, где только можно, использовать автоматизацию. Выделять время для совершенствования своего искусства в выбранном языке. Оно окупится сторицей! Лично я пока знаю только два кандидата на эту роль - Python и Ruby. Лично я пока далек от совершенного владения скрпитовыми языками. :(