由于没有详细的项目说明文档，且模块的特殊性(Windows服务)，不像BS或CS程序一样是可以直观的看到的数据的呈现，由于用于同步数据，牵扯的面太多，前后涉及的数据库中的表多达上百张，且在代码里掺杂了极其复杂的业务逻辑，设置了断点跑了一遍又一遍，一个一个的函数流程图画了下来，都画崩溃了，貌似搞明白了这边，前边的又忘了，问老员工，像一点一点剂牙膏一样，问一点，答一点，还不保证能都听懂，而且老员工也有自己的手头工作忙；
小弟弟我是新人，各位大神能否指教一二？求点拨，求教育。。。。。
------解决方案--------------------
盲目的一头扎进代码调试要不得。
先搞清楚业务流程，作为一个有上百张表的系统，我想应该有用例和业务流程图
再搞清楚系统架构和方法模块什么的。
基于此，你会觉得清楚很多。
------解决方案--------------------
设置了断点跑了一遍又一遍，一个一个的函数流程图画了下来，都画崩溃了，貌似搞明白了这边，前边的又忘了，问老员工，像一点一点剂牙膏一样，问一点，答一点，还不保证能都听懂，而且老员工也有自己的手头工作忙
1. 自己真的理清楚业务了么？ 如果清楚了就不会忘了。这里要多用心。
2. 向他人提问前，自己是否明确自己的问题与目的？如果自己还是比较模糊的，别人自然不愿意回答你。
解决这个问题的根本之道，还是自己静下心来仔细理清头绪，做到业务有条理，问题有条理，只要你的思路清晰，一切都会迎刃而解了
------解决方案--------------------
基于“文档”是太想当然的。经过你自己的手去维系一堆不是“垃圾”的文档来搞，我倒是很想学习一下先进经验呢。
简单地去画流程图也是不对的！你要先想出一个测试用例，然后才画与它相关的流程图，并且保证每天都测试100遍，连续3个月测试5000遍以上。这样做了50个测试用例，你就对重要的东西在自己心理打好了个“蓝图”。如果想成为开发能手，那么你要把这个数字从50再扩大至少5、6倍，你才能比较有勇气去负责重构一个产品。
每天，你应该仅仅把注意力放在当前要实现的用例和了解的流程上，不要浪费精力去前思后想那些最近2、3天根本不会涉及的东西。这样才能加强记忆里，避免夸大自己的工作。
仅仅画流程图，浑浑噩噩地去画，是不对的！