• 作为程序员最痛苦的事情:接手别人的项目
  • 发布于 2个月前
  • 112 热度
    3 评论
  • Kion
  • 3 粉丝 1 篇博客
  •   
项目好与不好,它就在那里;架构优雅或者丑陋,它就在那里;注释有或者没有,它还在那里;文档乱或者不乱,它始终都在那里。不论它是什么样子的,线上就那样跑着。
一般来讲,项目分为两种:

1、为业务服务的项目,比如公司内部项目、电商项目、各种 app 项目;
2、为技术服务的项目,比如开源中间件项目(dubbo、spring cloud、各种数据库中间件、各种缓存方案等);

首先说第二种项目,它专注于提供某一个或几个特定的功能。相对来说,这种项目技术实现上可能需要对这一领域有比较深的要求,但职责单一,目标明确。而且这种项目都是面向开发人员的,所以设计文档、接口文档、使用文档都会比较齐全。而且这种项目一般都会承担比较核心、比较重要的功能,并且还会在公司内部开放,甚至直接开源到社区。所以要经得起考验,代码都会写的比较规整。

开放出去,如果架构和代码不规整,就不会有人在 github 上 star,也不会有多少人使用。没人用事小,被人骂事大,让团队和公司丢脸更了不得了。所以这种项目比较容易接手,因为在文档和代码都比较规整的情况下,只需要在技术上下功夫就可以了。

本来项目应该有齐备的文档的,而现实中的好多项目往往不是这样的。由于各种各样的原因,比如框架比较老,人员变动,业务变动等,可能造成项目结构变的比较混乱。那么当我们应该如何快速的接手这样一个项目呢。

1、首先需要了解项目的的表现形式,什么是表现形式呢,就是说这个项目是提供 web 端服务,还是提供 App 端服务,还是其他形式的服务,又或者是混合了多种形式。我们比较容易理解具体的东西,而对于抽象的事物理解起来有一定的难度。所以看到项目最终的表现形式,可以对应到我们的项目结构中,这样一来,对于理解项目就比较容易了。

2、了解项目的部署架构。部署架构包括从客户端一直到数据访问层。这其中包括服务器系统版本,后端服务器软件类型(tomcat 、jetty 等),负载均衡配置,配置了多少台,用的是 nginx 还是 HA ,有或者是其他的。前后端交互方式,缓存是用到什么方案,是 redis 还是其他的,单机主备还是集群方案。数据库用的什么,有没有集群,有没有异地。数据库中间件用的什么框架等等。这个时候,最好有部署架构图拿来看一眼,如果是比较复杂的项目,肯定开发和运维会有部署文档的。如果没有完备的文档,建议要了解清楚之后,自己手动画一下部署架构图。

3、了解项目的代码架构。其中包括项目使用的基础框架,比如是 Spring mvc ,还是 Spring boot ,又或者是其他的框架,有没有用到 Netty 等其他的比较大的框架。有没有用到分布式 SOA 或者是否使用了微服务。用到分布式方案是 dubbo 还是 spring boot ,其中重点关注这些框架所用的版本,有些框架的版本可能比较老旧。

4、了解项目功能模块。到这里就和业务有关了,功能模块的划分一般和业务有关,比如注册登录模块、用户管理模块、订单管理模块、财务相关的服务模块等等。以及模块之间的依赖关系,是不是存在项目引用,是不是存在 RPC 调用或 http 服务调用关系等。这个时候,最好有完整的模块或服务依赖结构图,如果没有,最好在了解了项目结构之后,自己手动画一张。

5、最后,就是要理解具体的业务了,然后根据业务查看、调式对应的代码以及数据结构。

总体上要遵循从整体到细节,从高纬到低维的一个过程。如果能做好以下几点就最好了:
1、如果项目不是很复杂,最好可以有测试环境或者本地环境搭建起完整的项目架构。
2、如果项目很复杂,至少要保证自己负责的部分可以通过一些方法能在本地搭起来。
3、如果要在项目上做功能扩展,要遵循团队或项目的规范,不要独树一帜,这样会给后期维护带来麻烦。
4、修改功能之后,要维护好对应的文档。

想到哪儿写到哪儿,好多东西没写到位。
用户评论
  • 林永贵
  • 接手别人的项目,有文档先看文档. 但是前提是这个文档是比较新的, 不会把人带坑里.没有文档就去问领导, 通常领导就算不知道具体代码, 也会清楚大概的需求和框架, 很可能也会有其他人也了解这个项目, 这样他能指定个同事帮你理解代码.要节省时间, 我的经验就是: 不要费力去从代码里找why. 除非你手头的是self-documented的高质量代码.有困难, 找领导. 要时间, 要文档.因为, 人员离职之后留下的东西没人看得懂, 是他的责任。
  • 2018/4/19 10:02:00 [ 0 ] [ 0 ] 回复
  • 羊肉串
  • 熊大的熊二  2018-04-17 09:22
    对于一个程序员来说,接受一个别人的程序还不如自己重新开放一个来的快
    那说明你们公司的规范做的很不够,每人一种代码风格和命名风格当然会把人搞疯,如果公司有统一的开发规范,大家都照着这个规范进行开发,自然大家的代码都差不多,也就不会有接手难的问题了
  • 2018/4/18 9:26:00 [ 0 ] [ 0 ] 回复