如果拿到一个已完成的项目需要二期的开发，你会如何去了解这个项目？

[yinsuxia]

如果你拿到一个已完成的项目需要二期的开发，你会如何尽可能快的去了解这个项目？
分不多，大家来说说看。

[yinsuxia]

自己顶一下。。。。

[饕餮123]

引用 1 楼 XiNanHeiShao 的回复:

如果前面有业务文档，就先看业务文档，先把业务弄清楚，带着业务，去操作哈系统，再看数据库结构，最后去看一些主要的代码

+1

[dongt1]

有文档看好,没有运行自己搞。（运行着看，半成品是杯具）

[西南黑少]

如果前面有业务文档，就先看业务文档，先把业务弄清楚，带着业务，去操作哈系统，再看数据库结构，最后去看一些主要的代码

[以专业开发人员为伍]

如果有人把“项目”扔给你让你自己熟悉，你最好还是走吧！

[以专业开发人员为伍]

大部分“需求”和所谓“详细设计”文档，其实都是不断重复用户的表述。这些文档只有一点启发意义，因为真正的需求在用户，你应该不断去跟用户打交道。文档只不过是记录而已，不是需求本身。 然而一旦文档弄得繁琐了，很快不出几个月就成了垃圾。有些人不太会编程，结果把精力都丢在“读文档”上了，这样耗了小一年，坑爹老板一年的银子，然后没有什么建树。这样的人怎么识别？就看其看文档的方法——他是把文档当作启发呢？还是当作借口？

[以专业开发人员为伍]

比较靠谱的方式，也许稍微高一点要求的方式，就是你不应该胡乱纠结什么是非。因为此时没有是非，只有方法。如果不找方法，那么任何是非其实都是装神弄鬼的。因为此时根本就是再一次创造性的活动，甚至可能比第一次更麻烦。 那么比较便捷的方式，就是尽量去重复第一次开发时的工程中的关键过程。比如说第一次是怎样保证系统集成的？怎样保证持续发布的？怎样保证让各部门用户无话可说的？怎样将各种性能指标定义出来的？怎样确定架构的？ 说到底，就是要重新对原来的产品进行一次外科手术，一边诊断，一边改造。如果必要，那么你应该考虑重构。

[qvbzyx]

看代码....

[Black_Light]

引用 1 楼 XiNanHeiShao 的回复:

如果前面有业务文档，就先看业务文档，先把业务弄清楚，带着业务，去操作哈系统，再看数据库结构，最后去看一些主要的代码

+1,直接看代码的是最慢的

[yyl8781697]

先看原项目需求文档,设计文档 然后自己跑跑看,看看功能否是都已有, 然后简单的看几个页面的代码,看下他的代码风格以及习惯 最后对照者二期开发需求看看改,蛋疼的改

[H_Gragon]

先看原项目需求文档,设计文档

[Kim_Du]

比较快的方法，就是在了解整个项目模块框架的基础上，按照大致的功能点操作一遍，然后结合二开的需求再详细了解和二开相关的功能模块，当然这是建立在尽可能快的完成工作的基础上。

[青春code]

把系统里面所有的功能业务操作一下。让后针对自己开发的业务进行系统的了解

[喂大的程序员]

引用 8 楼 yyl8781697 的回复:

先看原项目需求文档,设计文档 然后自己跑跑看,看看功能否是都已有, 然后简单的看几个页面的代码,看下他的代码风格以及习惯 最后对照者二期开发需求看看改,蛋疼的改

[phoebuswei]

需求文档,设计文档，看来大家都是高端人士啊 我也见过不少，罪著名是用友，我感觉他们就是哄弄鬼 我感觉这种东西如果弄的好的，就写成字典形式想必是极好的 要不然，真的，说真的，吧程序跑起来F10走一遍，然后找业务聊一下 用时1~3天基本完成，一班程序都有一个套路了解后往下走就快了

[ycproc]

架构上尽量详细了解。 业务上流程正确即可。 增加沟通时间和频率。 此类型项目的迭代周期与你对他的了解程度成正比。