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

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

解决方案 »

  1.   

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

  2.   

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

  3.   

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

  4.   

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

  5.   

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

  6.   

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

  7.   

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

  8.   

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

  9.   

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

  10.   

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

  11.   


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