前两节描述的所有功能都来源于用户需求，如能实现这些功能，此时已是一款可用的产品了，然而，可用的产品并不一定是好的产品。
产品的“好”有两方面，针对用户和针对研发人员。乔布斯眼中的苹果手机，一根指头改变世界，就是对用户友好性最极致的追求。用户友好型不属于本书讨论内容，我们侧重于如何让产品对研发人员友好。
本书第一章已经描述过许多传统产品研发模式的困局，假设现在我们启动研发过流和变压器差动两款继保设备，有哪些好的策略让我们的产品是对研发人员友好的呢？
1. 严格分层的软件架构：
我们做产品时，看似每个功能都是一个个独立的模块，但如果细细观察，会发现这些模块之间有着数不清的互相调用，而恰恰是这些调用最终导致一个产品的很多模块是混杂在一起的。
此时，经常会出现一种现象：我们增加或修改一些功能时，需要修改多处代码，即使小心翼翼，也容易犯错。我早起工作经历，就经常会面对刚发布的程序就被反馈一堆问题的尴尬。
因此，架构设计首先需要的就是模块之间解耦。为了解耦，可能需要增加一些回调函数，可能需要采取一些程序技巧，但相对于整个架构的清晰，这点小小的代价是非常值得的。
模块和模块总是有一定的调用关系的，解耦并非完全砍断各模块之间的调用，而是梳理他们之间的关系。此时，我们会自然的发现模块会聚集并形成层次结构，一般都是上层调用下层，下层调用上层的较少。
此时，如果能加强层之间的调用关系，仅允许上层调用下层，不允许下层调用上层，好似一些优秀的类库，并不会去调用我们自己写的代码一般，此时，清晰的架构结构开始隐现了。
这种策略，后续我们称之为严格分层的软件架构。
2. 增加抽象层，对可变部分进行封装
我心目中经常有一种贪念，将某款产品仔细做完后，就可以不停的卖下去了。愿望虽好，可惜经常被现实打脸，今天不是某个芯片停产了，明天就是某个os不让使用了，后天又有某个规约要升级了，然后大家就被折腾的狼狈不堪。
计算机行业有一句名言：“没有什么是不能通过增加一个抽象层解决的”，这类问题的最佳策略就是增加抽象层。
芯片更新换代是嵌入式行业工程师经常面对的事情，即使不停产，也会通过增加价格或供货期恶心你，抵触是没用的，顺应潮流才是上策。为了程序便于移植，我们可以构建硬件抽象层，可以将需要改动的代码限制在一个较小的范围内。这种策略会极大缓解嵌入式工程师工作量。
实际上，作为架构设计师，需要深入理解行业，梳理经常发生变化的模块，并适度增加抽象层，然后在后续产品维护阶段，才不会因整日被用户牵着鼻子走而忙忙碌碌狼狈不堪。
3. 概念化提炼，构建可复用模块的基石
抽象层仅可以解决一些问题，但并非所有问题都可凭薄薄一层抽象层来解决。
很多工业产品都有一块小巧的操作液晶，不同于我们经常使用的手机或电脑屏幕，其功能比较固定，因此经常采用硬编码来实现。这导致其代码不仅庞杂，而且包含很多硬编码位置信息。
很不巧，lcd也经常面临各种替换升级。如有时需要一款漂亮的大液晶以突显高端大气上档次，有时又需要小巧便宜的屏幕来走量。此时，虽然可以通过抽象层快速解决不同液晶显示的驱动问题，但大量的液晶界面硬编码程序会让人疯狂。
解决策略很简单：控件化抽象，对控件编程而对非液晶位置编程。用控件隐藏所有位置信息，不仅简化了界面程序，而且也让界面程序变得可移植了。
类似这样的例子还有很多，如os抽象层容易构建，但要让软件模块可跨越os和前后台复用，就需要增加一些动态执行框架模块。
让人惊喜的是，经过这种概念化提炼后的软件模块，复用性一般都非常强，是构建可复用软件模块的基石，如GUI，如动态执行框架。
4. 配置软件，区分数据和接口，仅对接口编程
我们需要研发两款产品，过流保护和变压器差动。这两款产品的遥测、系数、定值，几乎所有的数据模型都差异颇大，准确来说是完全不一样，难道真的要做两款产品吗？
如每款产品都需要一个对外规约，难道也做两套，那液晶程序呢，维护软件呢？
实际上，这两款产品虽然数据本身差异很大，但他们的组织结构是一致的。如果我们能分离数据和接口，仅对接口进行编程，液晶、维护、规约，甚至产品中的大部分软件模块都变得可复用的。
而为了分割数据和接口，需要增加一个新模块：配置软件模块。
5. 元件化和脚本，几乎是模块解耦的通用策略
软件产品天然具有强耦合的特征，你稍微不注意，多个模块就紧紧耦合在一起了，而且很难拆开。
我研究过很多优秀的产品架构，发现大家进行模块解耦，最后几乎都心有灵犀的采取同一种策略：元件化和脚本。
每个模块将需要使用的外部接口进行虚拟化，然后通过脚本将这些虚拟化的对外接口连接起来。此时不仅各模块功能单纯耦合少，而且整个产品的适应性很强。
6. 虚拟化，是高维世界漏下来的一缕光
嵌入式产品研发有一个困难之处，软件研发工作依赖于硬件。样机还没做出来，程序无处安生。但困难的在于等样机制作成功了，时间也已经过了大半。
为了缓解这一困局，我们构建了一个虚拟设备的概念，可以使软件工作基于虚拟设备研发，这样软硬件工作可以同步进行，仅需要最后移植调试即可。
后来我们惊奇的发现，虚拟设备好似给我们打开了一扇新的窗户，不仅能让软硬件工作同步，而且凭空增添了各种妙用。如一些在真实设备中无法进行的测试用例，如一些对硬件的比对研究等。
我个人特别喜欢数学中的复数概念，她像精灵一般，仅仅出现在解题过程中，在答案出来之前就消失的无影无踪了，好似高维世界不小心漏下的一缕光，是上天眷顾人间的礼物。
虚拟化策略，也经常让我品尝到同样的味道。
7. 产品可靠性
嵌入式产品的可靠性可能无论如何重视都不为过，不然你只好让工程人员用辛苦出差来补，让营销人员用酒桌拼酒来偿，更悲惨的是，你可能失去利润，大家辛苦一场空悲切。
然而，产品的可靠性不是靠领导的三令五申就可以提升上去的，加人加班也经常是徒劳无功。产品的可靠性是一点一滴做出来的。
不同于其他软件模块，产品可靠性工作虽然重要，但不容易看得到，领导看不到，用户看不到，而且即使付出很多成效也不容易看得到。
怎么办，将质量工作内化到每一步研发工作中可能是最易执行的策略，代码审核、工作流、测试用例、状态机等，都可以潜移默化的提升软件产品质量。
我们都是普通人，因此我们会犯错，流程也并非尽善尽美的，因此最终交付的产品难免会出现各种各样的问题。
此时，如果能在产品内部构件质量检测模块，即使出了问题，也有策略去快速应对，持续迭代下去，问题就会越来越少，这可能是破解长期质量问题的关键所在。
◇◇◇
上面描述了一些架构师眼中的策略，虽然这些策略对用户是透明的，但能帮助研发人员更好的做产品，最终都会反哺用户。
产品总是在动态生长的，一个好架构师眼中的产品，也会自然的生长。现在，我们已经有了两款可用的产品毛坯，让我们开始随着产品一起成长吧！
——————————————
我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如感兴趣可加个人微信号nzn_xiaomaer交流，需备注“异维”二字。
