高级系统架构师培训心得

1、高级系统架构师培训心得刘元生， 升腾软件&服务研发六部在 3 天的培训中，谢新华老师的理论部分给我感触最深。其实在公司现有的软件产品开发中，很多问题已经困扰我很久，但确一直没有找到合适的解决方法。本次培训，受益颇多，很多培训中介绍的方法可以运用在实际的工作中。下面是一些培训心得。（1）产品功能只占产品价值很小一部分，产品质量和服务才是软件产品真正的价值所在。论功能而言，iphone 和普通手机、宝马和奇瑞 QQ，在功能上没有本质区别，但是在价值上却相差很大。在目前部门软件产品开发中，我们非常关注软件产品的功能本身，功能全而大，但却忽略了产品的非功能性需求，如稳定性、可靠性、性能和易用性等产品的

2、质量属性。由于对产品质量属性的忽略，导致产品开发出来后，碰到性能瓶颈、易用性差和不稳定等问题也就不足为奇。因此在今后产品规划阶段，就要重视产品的非功能性需求。对于产品的非功能性需求，必须要有衡量和测试的手段，如果没有衡量和测试的手段，那么这些产品的质量属性相当于空谈（目前在我们客户的需求中，存在太多的易用性好、可靠性高、性能好这些的空洞字眼）。举个例子，如何测试产品的易用性？可以采用提问的方式，产品是什么？要求易用性的真正原因是什么？怎么测试？需要项目经理根据客户的实际情况提出测试建议。在架构设计时，在关注质量属性的同时，往往容易忽略成本属性，这个在案例的数据库方案介绍部分深有体会，这也是目前

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

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

5、在公司目前的产品开发中，我们遵循的是一种线性开发模块，从需求分析、概要设计、详细设计、编码、集成、产品测试这样的线性流程进行开发。会存在以下问题：a) 产品的项目时间和风险不可控，由于整个开发过程周期很长，产品的需求在开发过程中存在变更，在开发人员和设计人员能力都不是很强的情况下，很多产品的问题只能在后期才能被发现，这时往往由于接近发布时间，导致很多问题被无限期搁置，形成一种恶性循环，投入的精力很多，但产品的质量却没有得到本质上的提升。而基于测试驱动的软件增量开发模型，在每一步都是可验证和测试的，如果在架构或某个模块存在问题，会很快在产品的初期阶段就被发现并修正。项目时间是可控的，每次迭代开发

6、过程，都表示一个版本的发布，可以增加客户、领导和项目团队人员的信心。而客户在看到产品的原型和最初版本后，会反过来增加对项目或产品需求的理解，而这些需求变更很可能在产品开发的前提就被发现，从而降低了产品的开发风险。b) 产品质量没有保障，由于很多问题只有在产品的测试阶段才能被发现，所以在现实情况下，经常听到开发人员抱怨，这是机制问题，要解决这个问题改动非常大。做为团队的项目主管，这时候也往往无能为力。要么投入更多的资源解决这个问题，导致产品一次又一次延迟发布。要么做为历史遗留问题，最后导致软件产品历史遗留问题日积月累，做到后面大家一起完蛋（破窗原理，千里之堤毁于蚁穴）。另外产品质量问题越多，对开

7、发人员信心也是一种打击和折磨（做软件的加班是最多的，大家都在干吗？修 BUG 和做重复劳动，这在公司不是正常现象吗？）。其它的问题我就不在枚举。如产品需求变更、测试团队和开发团队无休止的争吵等等。在项目时间的控制，我觉得有一点也是值得学习的，在项目或产品开始规划时，产品或项目的时间预估是极其不准确的，需要逐步反馈修正和调整，使计划越来越精确。建议将项目周期划分为 12 段，设立一个个里程碑，每个里程碑为一次交付。例如半年的项目，可以按 2 周一个节奏进行交付，而项目经理需要严格控制好这些交付里程碑。关于产品测试，还有一点培训中说得也有一定道理，可以借鉴，在现在公司的产品开发流程中，编码和测试是

8、一个非常独立的阶段，导致测试阶段发现的 BUG，开发人员很可能已经忘记之前写这段代码的思路（甚至这段代码根本就不是修复人员写的），导致 BUG 越改问题越多。因此必须建立测试驱动的软件开发模型，一段代码开发完成，立即测试。（培训中老师举了个例子，上午编码、下午测试，当天将测试问题立即修复）。（3）实现设计部分，主要讲解了 UML 和各种设计模式，主要的收获就是依赖倒置原则在框架中的应用，所有这些设计模式或原理在之前都已经理解和熟悉，但是在平时设计和编程中都不自觉的会忘记（编程的日子已经很少了，真怀恋做自己做设计和编程美好时光）。而这些设计模式在产品中或多或少的会用到。关键问题是，我们在做完一个

9、软件产品或项目的时候，很少有人去总结产品或项目中的精华，将这些精华成为今后工作的财富，如文档、可复用的组件，或者很少主动去认真分析产品中存在的问题，没有思考就不会有提高，不善于总结，就不会提高团队成员的能力。因此关键是如何运行这些知识去解决现实开发中碰到的问题，灵活应用，总结自己开发过程中成功的经验或碰到的问题（失败乃成功之母）。另外在现实的开发过程中，我们需要多教育和提高开发人员的能力，但在现实中，而主管由于时间关系，基本上没有精力去帮员工纠正设计和编码中存在的问题。培训中谢老师有个建议还不错，主管制订好规范以后，由同级员工之间相互审核，领导说这个东西不好，员工可能觉得可以接受，但同级的员工

10、说他做得不好，他可能面子上挂不住，长久以往，大家能力就渐渐提高了，另外其中任何一个人生病、离职，另外一个人立马可以顶上去，大家都相互非常熟悉。（4）产品文档的重要性谢老师举了一个实际的例子，一个公路收费系统，由几个非常聪明软件工程师开发，没有任何文档，所有的东西脑袋都可以记清楚，做得也非常好，项目非常成功。但有个竞争对手，也是做公路收费系统的，虎视眈眈，但一直没有机会，竞争对手想到一招，说只要把挖某*墙角，那个项目肯定完蛋。在我们开发的软件产品中，文档确实也是最被我们忽视的一块，在产品开发时，经常抱怨文档缺少，维护和修改别人的代码太痛苦了，只看到局部没有看到整体，导致在修改和维护过程中出现更多

11、的 BUG。且我们 IT 类企业离职率比较高，如何接手离职人员工作是主管不得不面临的伤痛。因此文档很重要，但是如何写好文档和维护文档是我们最头疼的一件事。a) 文档不清晰，描述不清楚，废话一堆。文档要清晰、简明、实用，垃圾话一句都不要写，另外大家都没有经过文档编写的培训（那么多人想去老师那边索要格式模板和具体项目模板，可以看出大家确实不知道如何写好文档）。b) 文档缺乏审核，没人审核怎么能帮助开发人员提高写文档水平和发现设计中的错误。c) 文档同步和维护更新非常麻烦，前期写的文档，后期由于开发的变更导致，导致文档没有同步更新，这是非常头疼和现实的问题，这也是我发现部门前面写的一些文档，现在基本上已经没有看的价值和必要。（5）大象和猴子的故事，大致的原意是指基于规范框架基础上的敏捷，故事讲的是大象定的是前进的方向，猴子在大象的背上左蹦右跳，将道路两边的果子摘下来，放在篮子里。猴子再怎么跳，也不会脱离前进的轨道。反思到现在的产品开发中，部门的技术支持人员和市场人员应该是猴子，而公司的战略、领导定的产品方向、研发部门开发的产品应该是大象，如果产品的方向不定，那底下一群人在左右摇摆，想必也是非常壮观的。（6）项目管理a) 做个阳光型的领导，激励员工的士气和尊严，相信员工，相信每个人的欲望，如果能够激发员工的尊严，员工干劲会特别