刚进公司负责一个用于数据同步Windows服务模块，业务逻辑相当复杂，如何尽快熟悉？

  由于没有详细的项目说明文档，且模块的特殊性(Windows服务)，不像BS或CS程序一样是可以直观的看到的数据的呈现，由于用于同步数据，牵扯的面太多，前后涉及的数据库中的表多达上百张，且在代码里掺杂了极其复杂的业务逻辑，设置了断点跑了一遍又一遍，一个一个的函数流程图画了下来，都画崩溃了，貌似搞明白了这边，前边的又忘了，问老员工，像一点一点剂牙膏一样，问一点，答一点，还不保证能都听懂，而且老员工也有自己的手头工作忙；
   小弟弟我是新人，各位大神能否指教一二？求点拨，求教育。。。。。 --------------------编程问答-------------------- 1.写邮件告诉大家，你碰到的困难，请求帮助，抄送领导。
2.等候回应
3.邮件没有回应，就跟你没关系了。
4.邮件有回应了，按照邮件里的指示做。 --------------------编程问答--------------------

引用 1 楼 shencb 的回复:

1.写邮件告诉大家，你碰到的困难，请求帮助，抄送领导。
2.等候回应
3.邮件没有回应，就跟你没关系了。
4.邮件有回应了，按照邮件里的指示做。

OK，领导说了，这个模块就是我的了，咋办。。 --------------------编程问答--------------------

引用 2 楼 warrior051210 的回复:

引用 1 楼 shencb 的回复:1.写邮件告诉大家，你碰到的困难，请求帮助，抄送领导。
2.等候回应
3.邮件没有回应，就跟你没关系了。
4.邮件有回应了，按照邮件里的指示做。

OK，领导说了，这个模块就是我的了，咋办。。

你搞不定的问题，总得有人带你吧。
让领导给个交待呗，要么找人带你，
要么你搞很长很长时间。 --------------------编程问答-------------------- 这种问题基本无解，没有文档没有人带你根本就不行 --------------------编程问答-------------------- 除 --------------------编程问答--------------------
盲目的一头扎进代码调试要不得。
先搞清楚业务流程，作为一个有上百张表的系统，我想应该有用例和业务流程图
再搞清楚系统架构和方法模块什么的。

基于此，你会觉得清楚很多。 --------------------编程问答-------------------- 设置了断点跑了一遍又一遍，一个一个的函数流程图画了下来，都画崩溃了，貌似搞明白了这边，前边的又忘了，问老员工，像一点一点剂牙膏一样，问一点，答一点，还不保证能都听懂，而且老员工也有自己的手头工作忙

1. 自己真的理清楚业务了么？ 如果清楚了就不会忘了。这里要多用心。
2. 向他人提问前，自己是否明确自己的问题与目的？如果自己还是比较模糊的，别人自然不愿意回答你。
解决这个问题的根本之道，还是自己静下心来仔细理清头绪，做到业务有条理，问题有条理，只要你的思路清晰，一切都会迎刃而解了 --------------------编程问答-------------------- 怎么像我们公司的项目呢？？？ --------------------编程问答-------------------- 数据库表一张张打印出来（当然只要打印前20行就行），然后每张都写上与其它表相关联的字段，对后面帮助很大 --------------------编程问答-------------------- 1、先把表之间的关系搞清楚，至少每个表有什么数据，数据的流向都弄明白了，你没说是什么数据库，建议用跟踪监视之类工具看执行的sql语句，这个最直观方便了。
2、可以加大量的log，把每个关键的分支都加上log，这样你可以明白了解代码执行的流程。
3、一遍一遍又一遍的仔细看，核心逻辑的源代码，弄清楚。
4、然后你就是这个项目的大牛了。。。。 --------------------编程问答-------------------- 针对这种情况，首先要了解项目的基本业务流程，然后就是熟悉每个功能模块了，最好做个笔记，前两个星期是云里雾里很正常，到后面就慢慢好了! --------------------编程问答-------------------- 就怕这样的，没文档，乱

知道的人多，知道全的人不多。

你要是能把这个模块搞定，领导就不小看你了。

重写可以吗，呵呵。。。。。。。。。。。。。。。 --------------------编程问答-------------------- 基于“文档”是太想当然的。经过你自己的手去维系一堆不是“垃圾”的文档来搞，我倒是很想学习一下先进经验呢。

简单地去画流程图也是不对的！你要先想出一个测试用例，然后才画与它相关的流程图，并且保证每天都测试100遍，连续3个月测试5000遍以上。这样做了50个测试用例，你就对重要的东西在自己心理打好了个“蓝图”。如果想成为开发能手，那么你要把这个数字从50再扩大至少5、6倍，你才能比较有勇气去负责重构一个产品。

每天，你应该仅仅把注意力放在当前要实现的用例和了解的流程上，不要浪费精力去前思后想那些最近2、3天根本不会涉及的东西。这样才能加强记忆里，避免夸大自己的工作。

仅仅画流程图，浑浑噩噩地去画，是不对的！ --------------------编程问答-------------------- 一切都“基于文档、归咎于文档”是一些公司里的一些人的想当然的做法，我可以理解的是：这些人除了这，估计也想不出别的“好办法”了。 --------------------编程问答--------------------

引用 2 楼 warrior051210 的回复:

OK，领导说了，这个模块就是我的了，咋办。。

赶紧考虑跳槽吧。当你遇到“某个代码规模人所有”的小作坊时，你不但被贬低（而不是抬高）了，而且可能落的这个公司最低开发水平的“标杆”的结果。在一个好一点的项目组中，开发水平会渐趋平稳提高，特别是不会有这种“这个模块就是你的了”的现象出现。 --------------------编程问答-------------------- 不用在意，你干不了多久 --------------------编程问答--------------------

引用 13 楼 sp1234 的回复:

基于“文档”是太想当然的。经过你自己的手去维系一堆不是“垃圾”的文档来搞，我倒是很想学习一下先进经验呢。

简单地去画流程图也是不对的！你要先想出一个测试用例，然后才画与它相关的流程图，并且保证每天都测试100遍，连续3个月测试5000遍以上。这样做了50个测试用例，你就对重要的东西在自己心理打好了个“蓝图”。如果想成为开发能手，那么你要把这个数字从50再扩大至少5、……

大神听大神的话就如同醍醐灌顶。。。 --------------------编程问答--------------------

引用 16 楼 dpcrman1987 的回复:

不用在意，你干不了多久

目前为止基本搞定了。。。 --------------------编程问答--------------------

引用 18 楼 warrior051210 的回复:

引用 16 楼 dpcrman1987 的回复:不用在意，你干不了多久

目前为止基本搞定了。。。

相信我 --------------------编程问答--------------------

引用 19 楼 dpcrman1987 的回复:

引用 18 楼 warrior051210 的回复:
引用 16 楼 dpcrman1987 的回复:不用在意，你干不了多久

目前为止基本搞定了。。。
相信我

相信你你又不给饭吃。。相信你有什么用。。 --------------------编程问答--------------------

引用 14 楼 sp1234 的回复:

一切都“基于文档、归咎于文档”是一些公司里的一些人的想当然的做法，我可以理解的是：这些人除了这，估计也想不出别的“好办法”了。

当然是一切基于文档,所有的开发行为都是由文档驱动,
没有能力管理文档,让"文档领先",这是生产能力落后的表现,

我所说的文档指的是一套团队自主开发的专门用于软件生产的设计文档管理系统,
也可以和自己的开发工具集成在一起
而不是传统意义的word,excel之类的文字或图表
--------------------编程问答-------------------- 没啥好说的，要么自己加班加点多花心思在这上面搞，要么就离职。指望别人帮你理清问题，很难。我就是基本快崩溃的边缘上咬着牙挺过来的。 --------------------编程问答--------------------

引用 6 楼 fengyarongaa 的回复:

盲目的一头扎进代码调试要不得。
先搞清楚业务流程，作为一个有上百张表的系统，我想应该有用例和业务流程图
再搞清楚系统架构和方法模块什么的。

基于此，你会觉得清楚很多。

赞同。
在接管一个新项目之前，你首先需要了解的是他的业务流程。在了解业务流程的基础上，熟悉其系统架构。接着就可以着个击破各个因而不熟悉而带来的不解。
请记住一点：大多项目，只要你了解他的业务流程以后，接下来的事情都会迎刃而解！ --------------------编程问答-------------------- 先把数据库表关系理清了 --------------------编程问答-------------------- 跨年问题了，业务(含buisness case)-〉数据ER-〉类关系 -〉测试用列

补充：.NET技术 ,  分析与设计