软件|Mobvista蔡超:一名优秀架构师需掌握的8大窍门( 二 )


史蒂夫·乔布斯曾说过“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. To be truly simple, you have to go really deep.”
真正的简单方法往往是来自于对问题和技术的更深入理解 , 简单可以说蕴含着一种深入的巧妙在其中 。 下面我来举一个例子 。
据数据显示 , 在一款软件系统的生命周期中 , 成本消耗占比最大的部分往往在于维护 。 因此如果能简化维护部分 , 对于整个项目将具有全局性的意义 。
软件|Mobvista蔡超:一名优秀架构师需掌握的8大窍门
图片

我们曾经为移动运营商开发过一个系统设备管理系统 , 移动运营商期待通过该系统管理移动设备 , 因此 , 系统需实现包括设备的自动注册 , 固件和软件的同步等管理功能 。 这些功能可通过一些管理系统与移动设备间的预定义的交互协议来完成 , 过程中 , 电信专家们会根据业务场景及需求来调整和新增这些交互协议 。 起初我们采用了一种容易实现的方式 , 即团队中的软件工程师根据电信专家的说明将协议实现为对应代码 。
软件|Mobvista蔡超:一名优秀架构师需掌握的8大窍门
图片

但很快我们便发现这样的方式不仅没有让项目更容易 , 反而让我们的工作变得更复杂 。
“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”--Martin Fowler
正如软件开发大师Martin Fowler所说“沟通”往往是导致软件项目失败的主要问题 。 这个项目最大的问题是在系统上线后的运行维护阶段 , 电信专家和开发工程师之间会不断就新的协议修改和增加持续沟通 , 而由于双方的知识和词汇存在很大区别 , 导致了沟通效率低、系统维护(协议的修改)变得十分艰难 , 协议更新上线慢等问题 。 同时 , 由于软件工程师对于电信协议的理解程度有限 , 很多问题往往在实际上线后才暴露出来 , 导致了很多交换和反复 。
针对这一问题 , 我们和电信专家一起设计了一种协议设计语言(并提供可视化的工具) 。 这种设计语言使用的是电信专家所熟悉的词汇 , 然后通过一个类似于编译器的程序将电信专家定义好的协议模型转换为内存中的Java结构 。 整个项目的运行与维护因此变得简单高效 , 省去了低效的沟通和不准确的人工转换 。
软件|Mobvista蔡超:一名优秀架构师需掌握的8大窍门
图片

不难看出 , 一开始按电信专家的说明直接实现协议看似更为容易 , 但放在整个软件的生命周期中 , 这却并非一个简单高效的方法 。
永远不要停止编码
架构师也是程序员 , 代码是软件的最终实现形态 , 停止编程会逐渐让你忘记作为程序员的感受 , 更重要的是忘记其中的“痛” , 从而容易产生一些不切实际的设计 。 在亚马逊 , 高级副总裁级别的distinguish Engineer , 如被称为Java之父的James Gosling等每年的编码量均不低于10万行 。
风险优先
架构设计很重要的一点是识别可能存在的风险 , 尤其是非功能性需求实现的风险 。 因为这些风险往往没有功能性需求这么容易在初期就被发现 , 但修正的代价却比修正功能性需求的代价大很多 , 严重时甚至可能导致项目失败 。
因此 , 我们应该在原型或早期的迭代中确认风险 , 并通过合理的架构解决风险 。 绝对不要把风险放到最后 , 就算是一个项目要失败也要让它快速失败 , 这也是一种敏捷 。
从“问题”开始 , 而不是“技术”
技术人员对新技术有着一种与身俱来的激情 , 总是乐于学习新技术和使用新技术 。 这容易导致一个通病 , 就是“当我们有一个锤子的时候看什么都是钉子” , 因而使用一些不适合的技术去解决手边的问题 , 导致简单问题复杂化 。


推荐阅读