什么是架构设计 如何进行架构设计

什么是架构设计 如何进行架构设计

这可能是一个有争议的话题，到底需不需要，还是要结合实际情况。

什么是架构设计

我的理解是大概有下面2个原因：

（1） Web开发：百家争鸣，没有统一的标准和老大 这些年得益于移动互联网的发展，前、后端开发岗位的需求量大增，而且各种框架层出不穷。 如何利用这些框架来为用户提供高性能的服务并没有一个统一的标准，于是百家争鸣，相应的设计师岗位也就层出不穷。

在 Linux 操作系统层面：那些大神们已经把内核和驱动层设计的很完美了，很少需要开发人员做大量的修改。

在应用程序层面：开发人员如果没有什么追求，只为了实现规格书中定义的功能即可。 而老板呢，也只是重视产品功能是否能正常实现，至于什么可移植、可扩展、执行效率等等，不会想到这个层面。

即使产品需要更新换代，让开发人员重新实现即可，反正只需要功能OK就行。

因为拿到了源代码，客户肯定很开心啊，因为只要吃透了代码，其他类似的设备都可以自己开发了。

过了一段时间，我问客户：上次那个产品的功能修改怎么样了？ 他说：还没搞定呢，上次你给的代码我丢了，会把人看死的，现在正从头重新写代码呢。

故事是真实的。 代码都是字符组成的，有些代码看起来赏心悦目，有些代码看起来怀疑人生。 没有架构设计进行指导的代码，有这些缺点： （1） 代码不能复用，移植很麻烦。 （2） 当需求发生改动时，不能快速调整代码。 （3） 对于已有的代码：不敢改、不想改，牵一发而动全身。

（4） 调试bug很头疼。

相反的，如果架构设计的好，对各方面都有好处：

对于项目来说：

(1)项目周期可控

(2)代码可读性好

(3)功能可扩展

(4)修改单一模块不会影响其他功能

(5)并行开发

(6)单元测试方便

对于开发人员来说： (1)节省开发时间 (2) 全局视角，提高开发大型项目的能力 (3)debug轻松、快速

如何进行架构设计

我的建议是： 无论项目的大小，无论项目周期的长短，一定要有设计文档，设计文档的详细程度就需要根据项目的实际情况进行灵活把握了。 在设计文档中，就要把架构方面的设计体现出来。在实现的过程中，严格按照文档中的要求来做。 取乎其上，得乎其中；取乎其中，得乎其下。

2. 程序文件的物理模型

（1） 分层设计 业务层 功能模块层 驱动层

3. 进程与线程的选择 在嵌入式系统中，实现产品的功能，可以通过多个进程相互配合来完成，也可以用多线程来实现，这个选择没有固定的标准，视项目的具体情况而定。

我一般的做法是： 如果产品功能不复杂，尽量用多线程来实现； 如果产品设计到的功能比较多，那么就把强相关的模块放到独立的进程中。

（1） 使用进程 各模块独立编译，不会相互影响。 出现类似 SegmentFault 问题，很容易定位到肇事者。 方便分布式部署。 代码安全：除了整合人员，其他人只需要 clone 自己负责的模块代码，没有权限、也不需要访问别人的代码。 但是：需要考虑到进程之间的通信问题，比如：IPC调用、socket通信、总线。（我一般都会采用在本地系统内使用一条MQTT总线来挂接所有的通讯模块）

（2） 使用线程 创建线程成本低。 线程之间共享全局变量（换个角度，这也是一种缺点）。 模块之间调用方便，因为函数地址直接可见。

4. API设计 可以把一个模块看成是黑盒，给定一个输入，就会返回确定的结果，或者执行确定的功能， 模块之间只需要定义好这个API接口函数就行。 至于模块内部是如何实现的，大家各显其能。 另外，如果你是API设计人员，一定要注意要让调用者用起来很舒服。就像你递一把剪刀给别人，一定是把手给对方。 另外一个经验，在项目设计初期，尽量不要把API的函数设计的太死板，容易给自己下套。 例如： （1） 可以设计带有 char *的变量，使用json格式的字符串，来传递任意长度和类型的数据。

5. 文件目录的设计 这部分容易理解，职责不同的文件要存放到相应的目录中：头文件、库文件、可执行文件、相关文档。如果这部分组织的不够好，当你把项目移交给其他同事时，肯定会被其他人在心中默念一千遍：F-U-C-K Y-O-U！

6.编译脚本的设计（构建工具） 当我们接到一个嵌入式项目时，在确定方案之后，程序运行的平台都是确定的，大部分情况就是嵌入式Linux，或者是一些变体。 在开发阶段，我见过有些开发人员每调试一个功能点，就把代码交叉编译后放，然后通过NFS远程挂载，或者scp远程拷贝，在真实设备上执行。我看着都比较累。

Demo说明

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。