可能不管新手老手有些程序员,接手一个项目之后都会多少有些迷惘。
以下是本人总结出来的一点小心得,如果错误希望大家给我留言,一起讨论:
如果你总是看见代码多就发愁,看见代码脏乱差就诅咒埋怨,看见代码逻辑复杂就头疼,搞不清调用关系就放弃,那你可能永远也变不成代码的主人,只能一次又一次被代码蹂躏。
所以,其实交接代码最重要的事儿,就是:
不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹,现在就开始读,立刻,马上,坚持十分钟,再坚持十分钟,你就能妙悟真谛。
【注意心态】:不要以追求完美的心态去接手项目,不要试图搞懂整个项目。
千万不要找到对应的控制器方法,一行一行读代码!!!!因为过去的功能已经完成了,需要修改该功能时,你才需要读过去的代码,方便修改。即使遇到不会使用的框架也不要紧,你知道业务逻辑后,可以直接写原生。
要的是结果(老大要功能以最快的速度做出来),以任务为第一。让自己的价值先绽放出来,而不是自己的研究学习能力。否则,会出现,你研究了整个项目的框架结构,熟知了所有的技术要点,却被无情的踢了出来,因为你的价值并没有表现出来。先站稳,再向上爬。必须对即将进行的阶段学习有个预估
1.项目维护有三宝:沟通 、文档 、代码跑。目标:了解业务逻辑流。
这三点很好理解,初步接手要请教前辈给你点一点业务重点、难点,让自己熟悉下;接着就是看系统的文档了,可以让自己迅速的了解整个项目的方方面面;最后就是走代码,因为前辈的指点可能有误,文档的书写可能有漏,作为一个优秀的程序员只相信自己走的代码,用自己的代码去验证文档,才是最正确的做法。文档只是给了你方向。走代码才能真实的了解具体的业务逻辑
2.重点***:数据结构+ER模型。目的:熟知项目的数据结构关系。
其实从事多年的老鸟可以发现,不管是C/S或者B/S,怎样的开发最后都是无非是底层数据库的数据排列筛选好后传递到前台。所以对待一个新的项目,去研究它的数据结构和库表是很有效的。这就要求我们对数据结构这块进行深入研究。
项目出活四部曲,跟、改、理、测要一起。
总结:要不停的试,不停的改
1、找nginx的配置文件,看看项目放在服务器的哪个地方(由于是接手多个项目,都是以虚拟主机来放的)| 5分钟
2、找对该项目熟悉的产品经理或同事(也包括测试)给你演示一把怎么用,顺便请教下主要功能。 | 30-60分钟
分开问,软件不会用,讲逻辑找产品;
某些技术、代码看不懂,问搭档;
整体项目的把控问项目经理;
3、小试牛刀:先熟悉软件的前后台各种操作,能体验的都体验一把(尝试修改某个功能,有好多个环境,在本地改)。
4、记录项目中该领域的专业词语,找机会和同事请教,弄懂这个词在这个领域是个什么概念
思路1的具体步骤(从上而下):
5、打开f12看network找他前后台菜单中对应的控制器(有的请求是在html中用a标签跳转的)。找到每个功能的对应的【增删改查】或每个功能对应的方法名称。如有没见过看不懂的罕见写法,查该版本的手册,切记,统一框架不同版本的同一个方法用法可能都不一致
6、看他每个功能对应的控制器方法中的sql语句的构成
7、通过echo打印原生的sql语句(TP框架,拿sql语句的对象->getLastSql()),看查出来的结果是什么,及通过视图渲染到页面的数据
8、看他的数据库设计,先在心里把表分个类(如 用户的、商品的),然后找外键关系
9、不要看完就了事,看完是记不住的,过俩天也都忘了。在旧项目中新建个控制器,模拟个功能点,模拟人家写的方式,自己写套增删改查操作数据库,展示给页面
思路2的具体步骤(从下而上):
1、先看公共函数库,传正确和错误的参数,分别测试,看出来的是什么东西。不要看函数中的每一行代码
2、多层继承的话,看他父类,父父类中,大概都有哪些方法,这些方法是做什么的,在心里记个大概
3、看控制器方法中,打印最后的结果,然后看视图层,是怎么展示的