我作SE的那点事

  离开XXX项目已经快半年时间了，其实早就想写点什么分享一下在这个项目中作为SE的一些感触，但又总是不太想再提及这个项目，也许就是那么一点没有达成而不甘的情绪吧(在这个项目转验收测试阶段后，被安排一个出差任务，从而脱离了该项目)。现在半年时间过去，回过头来再看这段经历，心里更多的是幸运和感激。其实一直蛮幸运自己能有机会参与这个全新的开发项目，更加幸运自己能担任SE这个难得的角色，也是这个项目让已经5年多没有接触代码和项目开发经历的我又重新燃起了对技术的热情，也是这个项目让我那点部件/模块级的开发经验初步提升到了系统产品级。总而言之，机遇难得，获益良多。

  其实在这个项目之前自己在SE这个角色方面并没有什么经验，所以这个项目中自己其实是有不少教训的。其实犯了错并不是什么可怕的事，我相信经历过才会快速成长。

  1，作为SE，不要迷信或者轻易相信自己不熟悉的技术方案

  这个项目是由一家合作方按照我们的需求来开发，凭借合作方十几年在这个领域的经验积累和知名度，我们之前非常看好他们的技术实力。合作方自己积累的两个基础开发平台（一个是电信领域的底层基础平台，一个是IT领域的应用开发平台）也曾经一度被当成他们技术方面领先其他厂家的一个重要因素。就这样，在项目设计和开发阶段，很自然的认可了合作方基于原有架构和平台进行设计和开发的思路，尽管在讨论方案的时候对此也出现了一些质疑的声音，但却没有谁否决掉这样的思路，毕竟项目初始阶段大家对合作方技术和架构的了解都非常有限，而且项目的技术主体是合作方他们自己。而正是这样的轻信，导致了项目后期出现了架构调整和重构问题。

  为什么会出现这样的问题呢？ 其实原因也很简单，十年前左右做软件产品其实还较难找到第三方的开源框架和基础库借鉴，要做产品就得自己封装，注意技术积累的公司就会形成自己公司内部的基础开发平台或开发库。然而这些年开源项目的飞速发展已经改变了这种局面，大量优秀的第三方开源项目涌现出来，并被广泛应用，无论从结构合理性，规范性，稳定性方面一般都强过这些公司的私有技术。

  所以SE对技术方案一定要有自己的了解和判断，需要积累丰富的技术经验，迷信或者轻信自己不熟悉的技术方案实际就等于是放弃了SE在项目中最关键的职责。

 

  2，设计环节不可缺失。作为SE，要确保设计和方案切实落实到具体的实现中去

  以项目的方式运作，很多情况下都是强调短频快，把需求分析完，把模块一划分，开发人员就领着自己负责的模块去Coding去了。然而有意思的是，在开发过程中如果你和开发人员去深度交流，往往发现那个模块的设计是缺失的，即很多开发人员在自己没有想清楚，甚至需求都还没理解透彻的情况下就开始凭着直觉和经验动手去实现了，也不管原来的经验是否适合现在这个项目，这样做的风险不言而喻。

  设计不一定要求是详细的设计文档说明，但设计一定要能够表述出来，交流其实也是一种方式。架构师也不是把系统架构一定，把设计规格一写就完事了，作为架构师必须要确保设计和方案切实落到具体的实现中去，所以开发过程中架构师必须多和开发人员交流，甚至根据开发人员的代码实现反过来评估是否符合设计要求。

  在这个项目中的开发阶段，虽然自己一直也在参与，但都主要精力都分配在辅导需求理解，具体产品要求，开发质量方面，诚然这些关注点也是保障项目成功必不可少的，但这其实都只是过程保障，和SE最核心的职责还是有些偏离，这也多多少少导致自己缺少精力深入到具体实现中去。直到发现设计环节的缺失问题，开发人员自己都讲不清楚实现方案(经不起推敲)的时候，自己才开始深入一个核心模块，根据代码实现反推那个模块设计（其实这个过程也很快），得到的结果让自己一下凉了一大截。这个项目的实际情况也是那个原来用C++开发的核心模块后来第一个被用Java仓促地重构了。

  所以SE需对系统模块的重要度，技术风险有清楚的认识，虽然这些模块不是SE去亲自实现，但SE必须要对这些模块的实现了若指掌。在开发阶段，SE需按照模块的重要/难度顺序，多和各个模块的开发骨干进行深度交流，了解开发人员的设计思路和实现方法，只有把设计定下来了，实现才不会偏得太远。某定而后动，就是强调一次把事情做对，这样才是高效的做事方法。

  3，作为SE，往往都希望追求完美，但SE却要清醒的认识“罗马不是一天建成的”

  因为将这个项目的第一个版本就定位成产品的商用版本，而商用版本除了基本的功能特性要求外，对于电信级产品还要满足可服务性和可靠性要求。其实这么多要求放在一起是很难保障这些要求都能按时实现的（实际度量第一个版本代码量达到15W行），架构师必须对这些要求进行关联和优先级排序。对于产品或者版本当前没有能力做好的特性，架构师要敢于砍掉或者重新规划，宁缺勿滥。

  这个项目中合作方因为具备十几年电信级产品的开发经验，其产品的可维护性理应是他们的优势和亮点，也许也是我们要求较多然而投入有限（只有1人负责），在项目后期虽然已经察觉到管理模块的粗糙问题，但错在自己没有去决策，而是把这个问题提出扔给了合作方的项目经理，结果版本在测试阶段可维护性方面成了重灾区，本该成为优势和亮点的产品可维护性反而成为了鸡肋，而不得不砍掉几个不太重要的特性

  这个项目的问题其实还远不止上述这些，这里就仅从SE的角度总结了一下，这些问题导致的后果就是这个版本在3轮验收测试后又不得不安排一个月的时间进行结构调整和重构。那么，这个项目中又有啥正面的经验值得总结呢？ 

  1，吸取成功经验。

   虽然这个项目在一些模块的设计上出现了一些问题，但整个系统的设计在项目初期借鉴了一些专家提供的经验和建议，所以在系统层面的设计没有出现大的失误，后续的重构和调整基本也没有涉及到系统的核心和基础设计，系统的业务流程，处理性能方面符合设计目标

  2，采用正确的解偶方法

   该系统的业务逻辑要求比较高的定制性，那么很容易想到的一种做法就是把这块独立出来，即解偶。在讨论设计方法的时候有两种意见，一种意见是把这块业务逻辑封装成jar包，然后部署到各个模块中去，各个模块利用这个jar包即可独立完成一些相关业务逻辑处理，但这个方法有个问题就是升级的时候涉及的模块较多；还一种意见是实现一个独立的模块集中提供业务逻辑服务，这样升级的时候只需要更新这一个模块即可，但这个方法有个问题就是多了一层交互通讯，业务处理流程也变长了，相应可靠性风险也大了。这个项目还是听取了一些专家的意见，采取了第一种方式，毕竟这种方式模块部署简单，集成度高，而只是少许牺牲了一些可维护性方面的代价。

  3，设计原型验证

  这个产品设计为满足上千万用户的系统，对数据库的性能要求比较高，所以在项目初期有考虑采取内存数据库的方式，减轻物理数据库的压力。但引入内存数据库无疑也增加了系统的复杂性，所以在项目初期就针对这个设计安排进行了一些原型验证，结果发现效果其实并没有预期那么管用，于是果断放弃了这个设计，现在想想这个决策非常关键。

  

  4，测试打造设计

   其实在敏捷开发中就非常强调测试驱动，肯定有其道理。这个项目也是深刻体会到了“测试打招设计”的含义，这个项目中也正是单元测试的要求在开发阶段早期就发现了原平台和架构方面的问题。为何这么说，这个项目我们从启动开发就要求进行单元测试，但却发现这个单元测试很难做起来，开始还以为只是开发人员的意识问题，后来深入了解才知道原来是使用的原平台太厚重了，层层依赖导致测试一个单元函数都非常困难。测试手段其实就像模拟一个用户来检验这个系统，同样也能检验这个系统的设计，所以测试不是在开发完成后交给测试人员再开展的活动，SE和开发人员需多从可测试的角度来设计和实现。