Дано:
1) последний оставшийся разработчик большой и сложной програмной системы собрался на пенсию через 3 месяца
2) систему вешают на меня
3) документации нет вообще, но есть несколько сот тысяч строк кода на good old plain C (for Solaris) and GUI (Borland C++ Builder)
4) коммуникация с уходящим товарищем крайне ограничена и затруднена
Надо:
Разобраться с системой, чтоб фиксить баги и добавлять новые фичи по желанию потенциальных заказчиков.
Вопросы:
- Существуют ли какие-то методики, подходы, народные приметы и urban legends для такой ситуации ? (ссылки на ресурсы are welcome)
- Кто-то может поделиться собственным опытом в подобной ситуации ?
Как принимать системы ?
-
- Уже с Приветом
- Posts: 991
- Joined: 09 Sep 2001 09:01
- Location: The Earth
Как принимать системы ?
Best regards,
Michael Popov
Michael Popov
-
- Уже с Приветом
- Posts: 3640
- Joined: 13 Sep 1999 09:01
- Location: Canada
-
- Уже с Приветом
- Posts: 991
- Joined: 09 Sep 2001 09:01
- Location: The Earth
yocto wrote:Может, просто плюнуть по появления первых запросов?
Минималистский подход: нет заявок - нет проблемы.
Можно. Но тогда фирма может продолжить логическую цепочку и развить ее до знаменитого принципа: "Нет человека - нет проблемы."
С другой стороны, не пытаться найти решение проблемы - заранее признать поражение. Это скверно сказывается на карме.
Best regards,
Michael Popov
Michael Popov
-
- Уже с Приветом
- Posts: 3640
- Joined: 13 Sep 1999 09:01
- Location: Canada
Michael Popov wrote:Можно. Но тогда фирма может продолжить логическую цепочку и развить ее до знаменитого принципа: "Нет человека - нет проблемы."
С другой стороны, не пытаться найти решение проблемы - заранее признать поражение. Это скверно сказывается на карме.
Нет, Миша, ты не совсем меня понял. Я имел в виду, что перед начальством изображать бурную исследовательскую деятельность. Каковую отложить до первого запроса. Ну, или вести в фоновом режиме, потихоньку.
Если, конечно, тебе не надо отчитываться за проент освоения каждые сколько-нибудь.
Ну ещё можно попытаться разобраться в пользовательском интерфейсе, чтобы знать, откуда начинать трассировать цепочки функциональности.
Так можно будет всё приложение хотя бы на абстрактные логические блоки разбить. Чтобы впоследствии не шарить в потёмках.
-
- Уже с Приветом
- Posts: 815
- Joined: 23 Nov 2003 02:29
- Location: UA, VA
у меня недавно было похожее
получили готовую систему на которую надо было довешивать кой-чего. оригинальный исполнитель запросил дорого и это дело скинули более дешевым парням - нам
с оригинальным исполнителем понятное дело особо много общаться не приходилось
1. сначала почитал _USER MANUAL_ на систему чтоб понять а чего там вообще такое. начертил основные блоки системы с точки зрения пользователя (типа там ввод данных, отчеты, стадии движения документа и тп)
таким образом система разбита "вертикально" - на куски функциональности
2. потом полез в код. поверхностно определил какие куски отвечают за UI какие за модель , какие за persistance, etc
таким образом система поделилась на "горизонтальные" уровни
3. потом просматриваем горизонтальные куски, пытаясь выявить то, чему (какому принципу, подходу) старался следовать девелопер когда делал систему
4. потом идем вертикально по функциональностям моделируя в голове "в чего тут происходит"
после пунктов 1+2 можно встретится чтоб уточнить все ли вы правильно поняли и ухватили
главное - понять архитектуру. тут надо обязательно после того как решили "о, понял" поговорить с девелопером чтоб убедится что "таки понял"
получили готовую систему на которую надо было довешивать кой-чего. оригинальный исполнитель запросил дорого и это дело скинули более дешевым парням - нам
с оригинальным исполнителем понятное дело особо много общаться не приходилось
1. сначала почитал _USER MANUAL_ на систему чтоб понять а чего там вообще такое. начертил основные блоки системы с точки зрения пользователя (типа там ввод данных, отчеты, стадии движения документа и тп)
таким образом система разбита "вертикально" - на куски функциональности
2. потом полез в код. поверхностно определил какие куски отвечают за UI какие за модель , какие за persistance, etc
таким образом система поделилась на "горизонтальные" уровни
3. потом просматриваем горизонтальные куски, пытаясь выявить то, чему (какому принципу, подходу) старался следовать девелопер когда делал систему
4. потом идем вертикально по функциональностям моделируя в голове "в чего тут происходит"
после пунктов 1+2 можно встретится чтоб уточнить все ли вы правильно поняли и ухватили
главное - понять архитектуру. тут надо обязательно после того как решили "о, понял" поговорить с девелопером чтоб убедится что "таки понял"
-
- Уже с Приветом
- Posts: 144
- Joined: 05 Mar 2001 10:01
Michael Popov wrote:<...> 3) документации нет вообще, но есть несколько сот тысяч строк кода на good old plain C (for Solaris) and GUI (Borland C++ Builder) <...>
Мне в сходной ситуации помогло следующее: в условиях отсутствия документации, но наличия доступа с исходному коду, для лучшего понимания потоков управления/данных можно организовать простейший "tracing": добавить в голову и хвост _каждой_ функции printfы вида "Вошел в функцию Function1"/"Вышел из функции Function1" и погонять программу для разных "Use Case"-ов.
И еще из личного опыта : морально готовьтесь переписывать целые куски кода "под себя", иногда это окажется единственным способом избавиться от бага или внести изменение.
-
- Уже с Приветом
- Posts: 18906
- Joined: 30 Aug 2001 09:01
- Location: 3rd planet
Re: Как принимать системы ?
Michael Popov wrote:Вопросы:
- Существуют ли какие-то методики, подходы, народные приметы и urban legends для такой ситуации ? (ссылки на ресурсы are welcome)
- Кто-то может поделиться собственным опытом в подобной ситуации ?
Была такая же фигня - 200к С-сорскода с математикой (простенькой к счастью) без единого коммента... Дебаггить, дебаггить и дебаггить. Ну и ковырять архитектуру - я б попробовал UI засунуть в Rational Rose, чтобы получить представление что от чего етс (если UI не совсем тривиальный).
Тупизна как Энтропия. Неумолимо растет.
-
- Уже с Приветом
- Posts: 4379
- Joined: 20 Jun 2001 09:01
Try doxygen: http://www.stack.nl/~dimitri/doxygen/index.html
"You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically. "
"You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically. "