怎样接手别人的大型项目的代码

【怎样接手别人的大型项目的代码】 通常代码都为实现业务需求而存在的,所以,在看懂代码前,你得先弄懂业务逻辑。就算一时半刻没办法完全撑据所有需求细节,也得有个大概,如里面有哪些业务实体(如订单、库存交易、走货单诸如此类可以独立反映一个业务实体的概念)和业务逻辑(如一个走货单状态变为“已走货”,库存交易就会新增一笔)。这样你看到一些代码里实现的逻辑,通常都会在脑海里有相应的需求场境可以与之对应,再循这个业务需求,去理解这一整块的代码逻辑,会比你一头钻进代码里容易。没有业务基础你一头钻进去,很容易出现混乱。我也接过很多奇葩的二手代码,有些还真的一点文档都没有,包括业务需求文档和代码文档,这个时候如果系统不大,就只能啃了(通常系统不大,说明它对应的精力逻辑、流程也不会太复杂太长)。如果系统太大太复杂,还是得先对需求有个大体了解。没有文档怎么理解需求?找上级协调,找关键用户了解,如果安排得好的话,通常会请求用户给你业务方面的培训(我是说企业应用方面的系统),了解好业务方面的概念,再去啃代码,就容易得多了。其实如果上一手的代码写得好,你无须深入去啃熟每一行,只需要理解代码中每个业务实体类、它们之间的业务关系、实现这业务逻辑的每一个业务类或方法,就可以知道一个大概的业务实体属性、结构和业务逻辑的代码实现了。也就是先从整体理解这个系统每一个模块的职能,然后再针对每个职能进行细化理解;或者在出现Bug要修复、有新的业务需求需要修改/扩展原来的代码时,才去细看每一行都不迟。

■网友
你问与不问,代码就在那里
■网友
先看懂代码结构,哪部分是数据访问,哪部分是业务逻辑,哪部分是界面然后看出一个大致的业务流程然后根据你要改的地方去往细节里看
■网友
有文档先看文档. 但是前提是这个文档是比较新的, 不会把人带坑里.没有文档就去问领导, 通常领导就算不知道具体代码, 也会清楚大概的需求和框架, 很可能也会有其他人也了解这个项目, 这样他能指定个同事帮你理解代码.要节省时间, 我的经验就是: 不要费力去从代码里找why. 除非你手头的是self-documented的高质量代码.有困难, 找领导. 要时间, 要文档.因为, 人员离职之后留下的东西没人看得懂, 是他的责任.


    推荐阅读