嵌入式架构设计思考

嵌入式架构设计思考

• 1.嵌入式架构设计是否必要？
• 2.嵌入式架构设计的方法
• 3.嵌入式架构设计的工具
• 4.嵌入式架构的适用性
• 5.嵌入式架构总结

1.嵌入式架构设计是否必要？

对于嵌入式系统的定义就是以应用为中心，软硬件可裁剪的低成本的系统。

然而随着嵌入式的不断发展，特别是芯片性能的不断提高，嵌入式系统也逐渐复杂起来了。以前的单片机系统逐渐被更加成熟和性能更高，价格更低的高性能芯片取代，随之而来的便是技术上的分层和专业的分化。嵌入式的要求也越来越高，嵌入式的专业性也越来越强，一个人做全套硬件软件的解决方案的时代也会逐渐的被团队化的开发模式取代。

在独立做项目的过程中，自我约束就可以了。系统设计方案、软硬件的配合、整体项目的测试与交付，这些对于一个有着项目经验的老工程师来说，可以独立完成一点没问题，需求输入，产物输出，中间过程自己把控。但是这种开发模式在如今复杂的嵌入式系统上，个人开发的风险与投入太大了。

第一是项目工程人员的水平有高有低，第二是配合上也是需要经过很多的磨合。一个好的嵌入式架构设计可以大大减少这种投入与沟通成本，从而让大家都非常的明确自己的工作任务与输入需求、输出目标。嵌入式有着灵活性强的特点，中间过程可自由发挥，保证功能的耦合性与扩展性以及性能的完善即可。

我认为，一个嵌入式项目，从需求明确->立项->设计架构->编码->测试->文档梳理->交付，这一些列的流程应该要有保障。需求是明确输入、输出、以及当前的资源和获利的多少，而立项则明确大概的时间节点和任务细化。到设计架构、编码、测试，如果该部分有80%的工作量，我认为合理的分配应该是设计架构(30%)，编码（20%），测试（30%）。当我再次review项目一个流程的时候，会总结出来，其实很多事情在架构设计上就出现了问题，导致代码不停的重构、在找bug的时候，一边一边review代码却无所得。当时间的教训、项目的压力一次一次的抗在肩上的时候，才会反思，如果事先做好了充足的考虑，也不会因为bug问题加班到深夜，也不会因为在产品进行最后交付的时候，担惊受怕。

另外，在团队合作上，架构设计是指导方向，在进行项目开展讨论的时候，应该以此为准则达成一致意见，犹如一张鱼骨图，头部为需求、中间为时间节点、鱼尾为项目产物、鱼刺为细节分支。只要大的方向不错，我相信对于解bug，调驱动、就让工程师各显神通。其实最后还有每个模块的api列表，这些都是鱼刺上的更加细节的分支了。随着开发的推进，也需要完善起来。最后产品交付一定是一个清晰的、大家都心里有底的项目。

2.嵌入式架构设计的方法

在我做嵌入式这些年里，遇到过许多的嵌入式工程师，要么就是需求一过来就开始调试代码，然后在现有的代码里融合新的需求，功能实现就万事大吉，因为领导也不会关注你的实现细节，只要可以用就行了。之后又要去掉这个模块了，又痛苦的把代码修修补补，终于有一天，自己看不下去了，要重构。老板也不懂，认为能用就可以了，其实自己心里清楚，这样修修补补的代码，迟早一天会出bug，自己心里都没底了。

那这时候该怎么办、只能顶着压力重构，加班加点，然后又重新再来一遍测试。没问题后又开始享受着兵来将挡水来土掩的补丁式开发模式了。

正所谓磨刀不误砍柴工，一个好的设计其实可以减少很多工作量，由于嵌入式方案的变化较大、所以耦合性的设计正是需要一直需要注意的。

我一直认为，如何把一个问题说的清楚明白，往往是对话<文字<图片<视频。当然，表达的难度也是逐渐增加的。最简单的就是通过对话来说自己脑子里的想法，让别人理解。当然这样的表述方式大家当时可能明白了，但几天后，又忘记了，可能连当时讲话的人都不知道自己讲的什么。然后就是文字表达，文字表达的技巧在于梳理清楚事情的来龙去脉，通过因果关系的证明来清楚表达意思，就算时间久了忘记了，再看一遍也能够想起。图片则更加复杂，但是其表达的方式则更加的精炼，要想画好一张图，首先自己要非常的清楚，然后精炼提取，形成架构。视频表述则是三者结合，也最容易为人所接受。

我有幸遇到了一个图画的很好的同事，让我感受到、事物的因果关系、数据的流向、以及时间与事物发展的规律都是有迹可循的，而非顺其自然。

嵌入式架构设计上，从大的框架上来说，比较关键的就是表达出输入、输出、数据的流向、模块的耦合、调用接口的层次、以及时间节点的把控。具体细节的设计就是包括API的列表、测试的方法、以及使用流程的梳理。其中最关键的就是思路清晰，表达明确。

3.嵌入式架构设计的工具

工欲善其事必先利其器。好的思维方式自然必不可少，但是缺乏表达的形式也是徒劳，只能自己思考却无法提出集思广益。所以能够找到最高效最明确好用的表达自己的思想的工具十分的必要。

关于文字的表述，可以用Markdown或者Word文档，当然，各有优劣，Word用的好也是非常得力的工具，但是Markdown对于程序员来说更加的简单和高效，排版也十分不错。而写Markdown的工具又是Typora软件我认为最佳。截图一般与文字并存，图文并茂才是赏心悦目的。这里我觉得Snipaste截图工具非常好用。有了图文工具，在线笔记我用的是为知笔记，虽然现在已经收费了，但我还是认为这是一个非常优秀简洁的在线笔记，可以记录自己的思维、日记、当前所思所想等等，只要坚持、量变终会质变。

关于图的表述、draw.io网页版和客户端均是不错的工具，各种流程图，时序图，架构图、数据流向图。只要自己善于表述、都可以整理成想要的图形。图的难度要比文字大，也是一个长期总结积累的过程。

4.嵌入式架构的适用性

我也时常反思自己的项目经历，也会偶尔翻看半年前或者几年前做的项目，总结成功与失败的教训。从刚开始的一头雾水，让别人去安排任务，询问项目进度，催着干活，到自己可以大概评估项目的用时时长，也能够预测其风险之后，逐渐的也对产品流程有了更加的清晰的认识。对于一个项目来说，如果是自己接的朋友项目，做好项目笔记，画好项目草图、做好风险预测就可以开始做事了，并不需要特别的流程，这样是最快也是最让人进入项目和完成项目的，按时保质量交付最为关键。交付完成后，自己做做项目总结，做好记录，下次也可以复用此法。

如果是公司合作项目、或者多人合作项目、一定不能够独断专行，固执的要求他人也这样做，每个人的开发方法、开发习惯都不一致。所以也不能够要求别人按照自己的方式进行开发，但是需要配合该怎么办，前提一定要有设计，这个设计并且是大家认可的，每个人负责自己的部分，减少工作的耦合与重叠。并且在遇到问题的时候，即使在分析项目进度的时候，也能够准确的找到项目在哪个环节上遇到问题，大家集思广益，相互协助，促进开发进度的高效和谐的进行。当然这里就会遇到项目细化程度的问题，也就是鱼骨图上鱼刺的分支问题，这个可以根据人员的情况自行进行细枝末节裁减与工作细化，但是最后出来的一定是一个完整的图。这样给老板交代任务、给新人做培训也能有迹可循。诚然这种方式将会是老板和自己都能得利的最好工作方式。

5.嵌入式架构总结

最好的设计就是没有设计，如果没有设计架构也能够非常好、质量高的完成项目，那是高手。对于一般的工程师，如果有一定的工具和技巧作为辅助，并以此养成好的习惯，相信也能够节省不少时间，提高工作和学习的效率。上文的表述并非是说嵌入式一定需要做架构设计，而是如果在做事之前，多做设计考虑，将会极大的避免后期维护带来的巨大压力和时间。

随着嵌入式设计复杂度的增加、独立开发模式、个人独揽一个项目的开发方式也会渐渐的远离，此时更加的优秀的工作方式、更加合理的思维模式可以减少自己的工作压力与工作时间上的投入，将更多的时间用于提升自己和享受生活。