正如前面提到的，这个项目的开发周期只有半年的时间，但是其开发的内容其实还是挺多的，在我个人看来，如果能够安排一年的开发时间，那么我们就可以有更多的时间在细节上进行更加细致的推敲，包括添加单元测试代码，单元测试可以保证在开发的过程中，及时监测到产生的功能退化问题，避免产生更多的bug，至少可以保证bug数量能够降一个数量级，这点在项目的后期尤为重要，实际证明没有单元测试的保证，后期确实产生了很多bug，甚至因为bug数量过多，差点耽误了项目的按时交付。言归正传，下面我们开始对整个开发过程进行简要的梳理，过程没有对错之分，同样的项目，在不同的人员手里可能也会产生不同的动作。
- 技术选型
该项目在开始的规划中是部署在云服务器上的，使用人员可以通过浏览器访问系统，所以该系统在设计上是一个Web站点，开发语言是Asp.NET下的MVC框架，与现在富客户端的实现方式不同，那个时候Web端的MVC框架在当时还是很流行的；在控件的选择上采用了DevExpress控件开发库，这个开发库在我第一家公司时使用过，只是那次是关于桌面端程序的，这次是Web端的；数据库采用微软的SQL Server，大概是因为我们公司是微软的合作公司的关系吧；云服务器使用的Azure云服务，是由世纪互联运营的。 - 模块划分
根据需求分析人员收集整理的业务信息，我们将系统的整个流程分成了具有特定顺序的几个模块，前一个模块录入的数据经过处理后传输给后面一个模块，如此顺序进行直至传输到最后一个模块，完成整个业务流程的闭环管理，当然结合具体的用户权限，在各个模块中对访问权限进行了设置和管理。 - 开发人员分组
在开始的开发过程中，大约前2个月的时间，我们六个开发人员都是在负责人XK的安排下各自做各自的事情，然后在开发的过程中，发现有些地方是通用的，比如前端的消息对话框，后端的某些模型类，这些公用部分在没有开发完成时会阻碍其他开发人员的开发进程，在这方面，我还负责开发了几个公共模块，正如我当时在阿斯利康项目所做的那样。
随着模块实现的增多，QA发现的bug也逐渐多了起来，整体的开发进度被bug慢慢的拖慢了，而且在修bug的时候，负责人大概很难确定该把bug分配给谁修复，因为大家都在开发，完成一个又一个的功能点，但是当分配bug的时候，就不太好确定当时这个bug是谁引入的了，另外在讨论问题的时候，负责人总是会把大家聚集在一块讨论，这也显然拖慢了开发进度，因为对于一个问题的讨论，可能最终给分配给其中一个人，另外的人员因为旁听而耽误了自己手里的开发任务。负责人权衡下来，把六个开发人员分成了2个相对独立的开发组，各设置一个开发组长，而我也很荣幸成为了其中一个组的开发组长，另外一个组的组长是TYJ, 在项目结束后的岁月里，在微信中，我们偶尔还会联系一下。 - 添加短信发送功能和一个手机APP
在业务的需求中，有一个功能点是需要发送短信的，该系统是一个资产管理系统，对于系统中的每一个资产在实际生活中是有具体的资产使用方的，该短信的功能就是把某些信息发送给这些资产使用方，比如这个月该交租金了，金额多少之类的。在该功能的实现上，我们注册使用了中国电信推出的企信通短信平台。
业务需求中的另外一个需求点是开发一个手机APP，在该APP上可以实现图片上传，某些数据的存取功能，在该APP的技术选择上，领导层选择的是微软的Windows Phone系统，那个时候Windows Phone系统已经推出一段时间了，还有诺基亚的几款手机搭配了该系统，这个APP是由公司的第三个项目组完成的，我们这边的开发人员都没有参与过。只是到了现在，谁知道该系统早就掩埋在历史的尘埃中了，连同搭配该系统的诺基亚手机。 - 后期交付准备
在该项目的后期过程中，时间大约到了11月份，天气越来越冷了，而我们却忙得越来越热乎起来，因为在UAT之后，客户提出了一些问题和改进方法，也有太多的bug需要处理，bug多了那是开发人员的问题，对于需求的改变，更多的人归责于需求分析人员，显然在需求的收集和整理过程中，需求分析人员没有想象的那么专业，bug比较容易修复，需求的改动意味着我们可能要推翻一些之前已经实现的功能，这其中的代价是很大的，另外因为没有单元测试的保证，很难保证我们在修改现有的功能中，不会引入更多的bug。这一段时间，大家都变得沮丧起来，连空气中的气氛都变了。
可能公司的管理层也意识到了问题的严重性，派了一个救火的项目经理S过来，项目经理应该是与客户公司达成了共识，把一些功能移到了后期维护工程中，总之在我们紧张的一段忙碌后，该项目最终算是可以成功交付了，值得一提的是有一天晚上，因为回去比较晚，37路公交车上只有我一人，算是坐了一次VIP公交车。
在交付的组织方式上，客户方公司还召集了在全国各个分公司的业务人员出差到上海，在另外一个大的会议室，由客户和我们双方关于该系统的功能完成了一次公共的培训。 - 项目交付维护
根据双方的约定，项目交付后，负责人XK把开发过程中的材料都整理发送给了客户，关于后期维护人员，公司选择我继续后面的维护工作，包括一些bug的修复，现有业务数据的导入，负责人也把一些数据文件转发给了我，包括Azure各个机器的配置、地址和访问方式。
至于为什么选择我，这其中还有一个小故事，在客户公司的规划中，他们计划招聘一个开发人员过去实行长期的项目维护，这种情景在职场中经常发生，比如乙方公司的谁谁谁在某个项目中就转到了甲方公司。所以当负责人在询问我的想法时，我也是答应的。
只有一个人的项目维护，那是相当的艰难，这意味着你要掌握整个项目的功能点，对于数据的导入，还需要你把现有的数据根据数据库各个表的定义进行拆分，写小工具完成各个特定表的数据导入功能。项目维护大约进行了一个多月时，到了2015年的1月份，客户公司在外面招聘了一位新的开发人员来接替我的工作，显然客户选择了一个更适合他们的人，项目的交接还是比较容易的，大约花了两天时间，我把整个项目给那个人通讲了一遍，然后把现有的文件和工作也交接了过去，至此该项目算是完结了。
现在看来，当时未转到对方公司也未必不是件好事，作为一个开发人员，还是在软件开发类的公司待着比较好。
发表回复