高级系统架构师培训心得

高级系统架构师培训心得

刘元生，升腾软件&服务研发六部

在3天的培训中，谢新华老师的理论部分给我感触最深。其实在公司现有的软件产品开发中，很多问题已经困扰我很久，但确一直没有找到合适的解决方法。本次培训，受益颇多，很多培训中介绍的方法可以运用在实际的工作中。下面是一些培训心得。

（1）产品功能只占产品价值很小一部分，产品质量和服务才是软件产品真正的价值所在。论功能而言，iphone和普通手机、宝马和奇瑞QQ，在功能上没有本质区别，但是在价值上却相差很大。

在目前部门软件产品开发中，我们非常关注软件产品的功能本身，功能全而大，但却忽略了产品的非功能性需求，如稳定性、可靠性、性能和易用性等产品的质量属性。由于对产品质量属性的忽略，导致产品开发出来后，碰到性能瓶颈、易用性差和不稳定等问题也就不足为奇。因此在今后产品规划阶段，就要重视产品的非功能性需求。

对于产品的非功能性需求，必须要有衡量和测试的手段，如果没有衡量和测试的手段，那么这些产品的质量属性相当于空谈（目前在我们客户的需求中，存在太多的易用性好、可靠性高、性能好这些的空洞字眼）。举个例子，如何测试产品的易用性？可以采用提问的方式，产品是什么？要求易用性的真正原因是什么？怎么测试？需要项目经理根据客户的实际情况提出测试建议。

在架构设计时，在关注质量属性的同时，往往容易忽略成本属性，这个在案例的数据库方案介绍部分深有体会，这也是目前部门软件在农行应用的真实案例。

在挖掘项目的需求上，也不是要做得太而全，需要项目经理找出客户的关键需求，哪些需求点存在风险（在需求沟通阶段可以将存在风险的需求进行规避），项目经理可以采用反向思维方法去找出客户的关键需求，如可以这样问客户，所有需求中，哪些需求没有实现客户是不能接受的？通过这种方式去找出项目需求中的优先级，那么在架构设计和开发中，会将重心放在这些关键需求上。我们现在做的都是产品，而不是项目，产品的需求比项目的需求更难把握，但我们也应该经常问问，哪些是产品的关键需求？把设计的重心和主要精力投入到这些关键的功能点上。

（2）在软件产品的架构开发模型部分，给我感触最深的是，基于测试驱动的软件增量开发模型，如下图所示。首先搭建软件产品的架构，将接口和规则定义清晰，架构必须是可

以测试和验证的，在做需求分析时，也不要想着一次就可以做好、做全，做到可以开始下一步即可，即将接口定义清晰即可，不要出现分析瘫痪，在做需求时，就应该要编写测试用例。接着是模块的增量开发，每个模块都是一个完整的过程，并且是可以在架构中进行验证的，每个模块开发完成标志版本的发布。产品的架构师，在项目架构实现时，必须和开发人员一起编码，验证架构的可行性，同时帮助开发人员理解架构本身和规范开发人员开发行为，只有开发人员理解整个架构，产品架构师才可以离开去做别的项目。（一般架构师需要带领团队完成20%左右的编码工作量）

在公司目前的产品开发中，我们遵循的是一种线性开发模块，从需求分析、概要设计、详细设计、编码、集成、产品测试这样的线性流程进行开发。会存在以下问题：

a)产品的项目时间和风险不可控，由于整个开发过程周期很长，产品的需求在开发过

程中存在变更，在开发人员和设计人员能力都不是很强的情况下，很多产品的问题只能在后期才能被发现，这时往往由于接近发布时间，导致很多问题被无限期搁置，形成一种恶性循环，投入的精力很多，但产品的质量却没有得到本质上的提升。而基于测试驱动的软件增量开发模型，在每一步都是可验证和测试的，如果在架构或某个模块存在问题，会很快在产品的初期阶段就被发现并修正。项目时间是可控的，每次迭代开发过程，都表示一个版本的发布，可以增加客户、领导和项目团队人员的信心。而客户在看到产品的原型和最初版本后，会反过来增加对项目或产品需求的理解，而这些需求变更很可能在产品开发的前提就被发现，从而降低了产品的开发风险。

b)产品质量没有保障，由于很多问题只有在产品的测试阶段才能被发现，所以在现实

情况下，经常听到开发人员抱怨，这是机制问题，要解决这个问题改动非常大。做为团队的项目主管，这时候也往往无能为力。要么投入更多的资源解决这个问题，

导致产品一次又一次延迟发布。要么做为历史遗留问题，最后导致软件产品历史遗

留问题日积月累，做到后面大家一起完蛋（破窗原理，千里之堤毁于蚁穴）。另外

产品质量问题越多，对开发人员信心也是一种打击和折磨（做软件的加班是最多的，

大家都在干吗？修BUG和做重复劳动，这在公司不是正常现象吗？）。

其它的问题我就不在枚举。如产品需求变更、测试团队和开发团队无休止的争吵等等。

在项目时间的控制，我觉得有一点也是值得学习的，在项目或产品开始规划时，产品或项目的时间预估是极其不准确的，需要逐步反馈修正和调整，使计划越来越精确。建议将项目周期划分为12段，设立一个个里程碑，每个里程碑为一次交付。例如半年的项目，可以按2周一个节奏进行交付，而项目经理需要严格控制好这些交付里程碑。

关于产品测试，还有一点培训中说得也有一定道理，可以借鉴，在现在公司的产品开发流程中，编码和测试是一个非常独立的阶段，导致测试阶段发现的BUG，开发人员很可能已经忘记之前写这段代码的思路（甚至这段代码根本就不是修复人员写的），导致BUG越改问题越多。因此必须建立测试驱动的软件开发模型，一段代码开发完成，立即测试。（培训中老师举了个例子，上午编码、下午测试，当天将测试问题立即修复）。

（3）实现设计部分，主要讲解了UML和各种设计模式，主要的收获就是依赖倒置原则在框架中的应用，所有这些设计模式或原理在之前都已经理解和熟悉，但是在平时设计和编程中都不自觉的会忘记（编程的日子已经很少了，真怀恋做自己做设计和编程美好时光）。而这些设计模式在产品中或多或少的会用到。关键问题是，我们在做完一个软件产品或项目的时候，很少有人去总结产品或项目中的精华，将这些精华成为今后工作的财富，如文档、可复用的组件，或者很少主动去认真分析产品中存在的问题，没有思考就不会有提高，不善于总结，就不会提高团队成员的能力。因此关键是如何运行这些知识去解决现实开发中碰到的问题，灵活应用，总结自己开发过程中成功的经验或碰到的问题（失败乃成功之母）。

另外在现实的开发过程中，我们需要多教育和提高开发人员的能力，但在现实中，而主管由于时间关系，基本上没有精力去帮员工纠正设计和编码中存在的问题。培训中谢老师有个建议还不错，主管制订好规范以后，由同级员工之间相互审核，领导说这个东西不好，员工可能觉得可以接受，但同级的员工说他做得不好，他可能面子上挂不住，长久以往，大家能力就渐渐提高了，另外其中任何一个人生病、离职，另外一个人立马可以顶上去，大家都相互非常熟悉。

（4）产品文档的重要性谢老师举了一个实际的例子，一个公路收费系统，由几个非常聪明软件工程师开发，没有任何文档，所有的东西脑袋都可以记清楚，做得也非常好，项目