2017年工作总结

      2017年的新年伊始，从老家重新回归上班，3、4月份的时候，正当跳槽季，公司已经开始有人陆陆续续离职，自己心里也是蠢蠢欲动，入职时给了一个北京的集体户口，却被绑了三年，2017年终于可以离开了。

      然而今年的1月3号，和老婆领了证，定了五一结婚。因此离职的事情也拖到了五一之后。离职的过程并不愉快，从邮件通知离职到办完手续整整拖了一个月的时间，每天基本都加班，终于把手头的项目算是了结了。然而最终加班费也没有要回来，鄙视一下某某领导和公司。

    从20140217至20170627，3年4个月，毕业后第一份工作。时间够长久，总结一下：

    1、从小白到现在，算是在这里入门，在这里积累，能够混口饭吃的本领也是在这里习得，有了一些解决问题的思路和方法论，这是应该感谢的；感谢它的包容和机会，让我成长。

2、环境比较压抑，同事间的关系比较冷漠，跟大北京一个基调，对自己也造成了一定的影响，更加理性、现实、冷酷；

3、待遇并不理想，三年没怎么涨过工资，心里有时不甘却也无可奈何，最后工作状态已经比较消极，没有动力；在一个公司时间久了，就会被这个小环境所同化，眼界也会局限；感觉是长期被压制的，包括自信心；

4、三年多的大好青春，换来一个北京集体户口，不知是否值得；2年的公租房生涯，算是最正确的决定，当时从沙河地铁的自建房公寓率先搬进公司申请的公租房，一个人三四百块住个90多平的三居室，也是逍遥自在；

 

      自20170821入职新单位，整整四个月有余，总结一下入职以来的工作内容和心得：

1、基础工具的使用

入职以后，M项目尚未上线，仍在火热进行中，由于新入职和对业务板块不熟悉，负责各个版块的截图测试工作；工作性质量大重复，暴露了对于excel表格使用的不熟练，导致效率不高，根本原因，使用少，缺乏常用技能的积累；在以后工作中，尤其对于数据、问题等的统计分析、工作汇报形式，注意积累；这类事情，技术要求不高，但很重要；

2、复用和新开发的取舍

后来负责MH和XTBG项目的开发和测试。从项目的角度上来讲，两个板块之前都有一定的代码基础，类似于二期开发，对于代码的复用和新开发需要一定的判断。

    首先，MH版块有一定的代码基础，包括表结构，接口等，有50%左右的接口进行了复用，数据库表结构也复用了之前的；新入手的项目，毕竟对之前业务逻辑和项目背景不能完全了解，开发之前的设计思路也难免左右摇摆；想放手一搏，完全不复用之前的数据库表结构和业务定义，这样，从零开始，思路是顺畅的，一切自己定义，灵活可控，心里上不忐忑，整个项目功能逻辑想清楚了就是慢慢实现的过程。但无疑，会大大增加工作量，基础数据表结构设计，实体类定义，service方法，controller接口，所有从零开始，带入的是大量单元测试；这样做的另一个问题就是，增加大量新代码，同整个门户板块的代码相独立，没有耦合，必然出现重复逻辑和代码，不利于整个版块的维护。

    如果说一个项目，从无到有，就是写的过程；但二期开发，必然是一个读和写的过程。首先要去读，了解之前的项目背景，业务逻辑，去读别人的代码。了然于心之后，再去考虑如何复用在自己的业务需求里面；尤其到代码级别，首要原则就是不要影响以前的功能，尽量增而不是改；通过子类继承重写父类方法来扩展业务逻辑；这样，使用别人的方法和接口，虽然，心理上失去一定的控制感，但会节省一些代码级的工作量，利于整个版块的维护和扩展；

 

    对于公司级别的开发来讲，会考虑后期项目的维护和新项目可复用性，就像T基础平台的打造，一般成熟的公司都会搭建自己的技术框架和平台，当类似功能和应用场景的项目到来时，能够快速孵化出对应的产品，从而节省开发成本和提高产出效率。因此，适用到代码级别，必须进行整体设计，充分考虑代码的可扩展性和易扩展性。优秀的代码，是容易扩展和复用的，所以，对自己的代码质量负责，写优秀的代码，也是造福后人的。

    3、与第三方协作

 XTBG版块，涉及到第三方厂商ht的oa 办公系统；我们的数据通过webservice的方式从ht获取，我们生产的数据需要回写到 ht的oa 系统。涉及到第三方，必然增加沟通成本和项目风险；跟第三方合作，首先要降低期望，做最坏的计划；一般原型出来后，接口先行；接口定义方要再三审核接口文档，尽量做到整体逻辑无误，参数定义清楚，没有歧义和未定义，尽量避免后期的再修改，提高效率，降低成本。因为接口文档是双方协作的重要沟通方式，定义不清，缺少必要的描述，就会增加额外的沟通，甚至造成理解偏差，增加开发

成本；甚至双方协作受阻，责任不清，相互扯皮，大大延误工期；同时，作为接口文档的接收方，要充分理解接口定义和描述，感觉理解有歧义或定义不清的地方，要及时电话沟通确认，逻辑或定义有问题的地方，要及时和对方沟通修改；文档如需修改，要督促对方完善文档，出新版接口文档；接口定义方维护好接口文档，确保双方信息的对等和思路的一致；协作，除了原则性的东西，自己尽量往前多走一部，多做一点。例如， XTBG项目中，垃圾数据的处理，是需要 ht维护处理的，他们为了节省人力成本，提出要把库和表告诉我们，让我们自己来维护。这显然是不合理的，属于原则性的问题。因为数据库就像源码，是 ht来维护的；我们对他们的业务逻辑没有代码级的了解，就不能轻易的操作数据库数据；如果我们操作了，出了问题，是说不清楚的，是会扯皮的；对他们来说，也是不安全的，可能给自己带来不必要的麻烦，属于权限滥放；如果项目是己方的，对于一些交叉的不具有原则性的工作量，自己可以多做一些，自己能做的，尽量不让对方做；因为己方做的越多，项目就越可控，从而降低项目风险；如果项目是对方的，做好自己的工作，做好测试，保证自己代码的质量，避免出现太多问题，导致对方频繁的打扰，影响工作效率；另外，双方沟通过程中的任何变更，包括需求变更，接口调整等，都要保存好会议纪要、变更点、新版文档、双方确认往复邮件等，当双方扯皮时可以作为证据和砝码；

4、测试

由于项目提测前需要自测报告，自测就是项目组内的测试，项目组没有专门的测试团队，部门没有专门的测试人员，直接提到品控部门，因此，项目组开发人员要兼职测试工程师了。开发阶段，本来只负责后台接口，包括同第三方和前台的对接；工作内容，就是第三方接口的调用和测试，将第三方接口的问题反馈给他们，并督促他们修改，同时，负责后台接口的编码和测试，确保提供前台正确的数据和接口；和第三方的对接，就是大量的测试，督促、修改、验证的不断迭代，工作效率一定程度上依赖第三方接口对接人的能力和品德;其实就是测试的工作性质，帮别人发现问题；另一部分，就是后台提供给前台的接口，多是对第三方接口数据的再一层封装和整理加上后台IM通知的一些逻辑；后台开发编码使用时间很短，后面就是大量的单元测试和集成测试；进入和前台的集成测试后，负责整个版块的测试。流程测试、系统测试、统计bug 、需求确认、修改后台bug、验证bug，不断迭代；整个过程持续了相当长的时间，占据项目周期的一半左右；在此，总结下经验教训：

1. 产品定义的需求要明确，没有歧义，原型和UI要尽可能的体现整个产品的所有必要逻辑，不要把这个工作量扔到开发人员手里；开发人员遇到后必然频繁找产品确认需求，影响开发效率；开发过程中的需求变更，需要及时更新到需求文档中，并通知所有相关人员，保证需求文档和开发的系统功能所匹配，便于以后维护；

2. 开发人员遇到需求不明确的逻辑，一定要找需求确认，不要想当然的冒然写代码；一旦和需求不一致，就要整体推翻重新，增加大量工作量；

3. bug统计要做好状态标记，便于验证和回归；

4. 修改bug的质量要提高，尽量自己要做代码级的验证，防止一个bug 多次reopen ，浪费测试人员时间，降低迭代效率；

5. 既然没有专门的测试工程师，自己要控制自己的代码质量，自己多测试；都是开发，没人想去测试；

6. bug出现后，先进行判断，前台的问题，还是后台的问题，判断不了的时候，就一起排查，不要拍拍脑袋就说不是自己的问题，要看日志或抓包，拿出证据，才能排除自己的问题，就像犯罪嫌疑人自证清白。