接手一个新的项目的开发 持续更新中...

本身作为一个JAVA 开发人员，目前在公司已做了一年前端，最近部门一个参与重要任务的前端开发人员离职。他的很大一部分工作转交给了我。现在还在交接期。写博文记录整个交接过程。

计划：

1. 了解代码，了解业务，整理文档

            收集了相关的需求文档，简单看了一下，一头雾水。然后按照代码结构。自己用Excel画了一个自己的理解的改项目架构图。主要目的是加强自己对需求和代码的理解。对代码结构有了一个初步的理解。    --2018.7.30

            在测试的环境上面部署项目，实际操作该应用。和交接人交流了解业务流程，参考代码 的逻辑实现进行咨询。   对代码结构 有了一个比较深入的里了解，能够基本明白每个模块的功能，在实际应用中对应哪块实现。对实际业务有了一个初步的理解。 可以在测试的环境上配置主体功能   。-- 2018.7.31

           这几天开发任务增多，没有太多时间了解交接的工作。而且公司又有新的同时离职了。心态也比较浮躁。今天让交接人整理了一份代码结构说明文档。打算明天以此为基础再深入了解代码   。-- 2018.8.6

           这两天重新让交接人给自己讲了一遍代码的逻辑。具体到每个模块的细节。一边说明，自己也会提出一些问题。昨天开了需求会议，大致了解了这个项目几乎未来半年的需求（无语......），又参考这个需求文档提问，对该项目和未来的需求多了一些了解。然后自己以前做的项目又有一批故障走过来，事情真多。 -- 2018.8.8

          交接人已正式离职，这段时间主要是故障驱动了解，配合后端和测试了解代码结构，也会寻思为什么交接人的代码会什么按照这个结构写。总结起来交接人的编码水平还是很高的。至少一些新增的需求都不会需要大批量去修改代码。虽然功能很复杂,代码逻辑也比较清晰，简洁。未来需要再研究下代码里面的逻辑结构，学习优秀的代码是怎么写的。--2018.8.14

2. 故障驱动加强

         处理了几个简单的故障，例如：自动化测试没有给组件添加ID，没有做某个简单的参数校验。--8.8

        处理故障：残损业务修改前在前端添加校验；某个参数格式下发错误，和传统项目，后端开发，需求设计人员讨论统一的规范。--8.10

        处理故障：有需求报文格式定义错误导致的故障，有可用性不好提出的故障，有很多故障都不是纯粹的代码逻辑错误，需要配合测试，后端开发，需求人员，开发经理一起讨论处理。--8.14

3. 着手新功能开发

       接收新功能开发：设置某个参数为自动配置，需要修改：界面展示，参数校验，报文下发。分配工作量：3天。实际开发：2天。--8.14

经验和总结：

       交期器算是正式结束了。半个月的过渡期。对这次新项目接手的经验是：

       1. 对项目结构宏观的认识还是很重要的，包括具体的应用层面和代码层面。一定要将项目运行起来。自己多实际操作几遍。这个过程可能需要多与测试人员，交接人，项目的其它开发人员多沟通。

       2.通过故障驱动开发，以及处理一些简单的需求对于了解项目的细节很有帮助。在处理故障的过程中慢慢熟悉交接人的代码结构。

      3. 这次交接没有涉及到新的技术，主要是业务层面的。如果涉及到新技术的交接。需要以后再积累经验。