最近有几个小伙伴反映说自己写程序感觉很乱，不知道怎么去规划，想到什么就写什么，全局变量满天飞，代码一多就出现好多问题。

而且如果自己写的程序不加注释的话，过几个月发现看不懂了。

一个工程师的成长过程，总是惊人地相似，曾经我也和大家一样，一直想解决程序如何写能更好这个问题。

全局变量太多难管理，看起来是个小问题，要想解决其实背后涉及很多东西，否则不如你直接加注释来得更直接。

变量确实要用，你省不了，你只能通过别的方式去规避乱的问题，比如说一些编程技巧和思维。

后面经过无数项目洗礼，我个人领悟是：一个程序写得好不好，主要看程序算法和程序架构。

先来说说算法好了，算法不是刚需。

很多新手以为程序要想写得好，跟英语和数学水平有关系。

今天我给大家交个底，并不是，最多数学好算法能做得更优，大多数产品算法都不复杂，单片机能做多复杂的运算是吧？

很多算法，难在前端公式剖析，不管再复杂的项目都好，最后体现在程序里的都是加减乘除，与或等这些简单运算。

举个例子：

请给出能够计算出结果等于8的公式。

不同的人，计算出来的公式可能是不一样的，比如以下几种公式都能实现。

公式1：(1+1)*(2+2);

公式2： 1<<3

很明显，公式2的计算效率更高，主要是体现在汇编指令更少，机器周期自然更短，所以说算法更好。

实际上真正的算法比这个要复杂得多，这里只是举个例子而已。

像这种公式，一般我们在小笔记本上先算好，最后转成用加减乘除之类的公式用程序写出来。

大多数情况，只要产品实时性要求不是特别苛刻的，公式1和公式2你看不出任何区别。

并不是每个行业的产品都需要算法，每个行业的算法肯定也是不一样。

哪怕你数学很差，都没关系，你找个数学厉害的人，告诉他你要算什么。

让他用加减乘除、与、或、移位运算帮你算出一个最佳解题公式，你带入到程序直接用就行了。

所以我们在做产品的时候，不要过度去追求程序执行效率，只要能满足需求就好，并不是刚需。

研究算法是很浪费时间的，通用性也不强，反正就是性价比很低。

下面再来说说程序架构，这个实用性和通用性极强。

而且可以说不懂架构中大型项目绝对做不来，不是做不好，而是做不来！

可能很多人工程师做了几年，已经碰到了瓶颈期，一直想提升，又无能为力。

比如说，变量多了，函数多了，程序总是乱糟糟的，一整合起来一堆BUG。

这个功能好了，影响了别的功能，改了别的功能，这个功能又不行了。

最后马马虎虎把代码好不容易整合起来实现完整的产品功能了，也没BUG了。

挨千刀的老板又跟你说要改功能，在刚开始做研发那几年，我就最怕增加功能、改功能。

哪怕只是把LED改成每秒闪1次，又或者说增加一个按键这么小的功能，如果架构不好的话，都有可能花上你一周甚至更长。

那程序架构到底是什么？

我认为是一种成熟的编程思维，是经验的总结，比如RTOS就是属于一种程序架构，STM32固件库也是一种程序架构。

不同的人，编写出来的程序架构都不一样，有大的有小的，最重要是够用就好。

而全局变量多导致程序乱的问题，就可以用程序架构的模块化编程特点来解决。

具体怎么做？

1.以不同的层次不同的文件区分

一般在写STM32级别项目，我都会分为两层：硬件层和应用层。

硬件层主要负责单片机的相关外设配置和一些功能驱动。

拿我们无际单片机编程的wifi报警主机项目来举例。

硬件层有临界管理、喇叭PWM驱动、EEPROM存储、按键检测、LED特效功能、OLED屏驱动、无线数据软解码、定时器矩阵、串口数据收发这些功能。

每个功能都是单独的.c和.h文件，这样更好区分和管理各个不同功能模块代码。

如果把这些都写在一个.c文件里，那涉及的函数和全局变量非常多，很混乱，查找也不方便。

2.我一般会把不同功能模块的全局变量、数组定义到对应的.c文件里。

这样定义以后，只要你不搞extern声明，别的.c文件基本是访问不了你这些变量或数组的，一定程度上起到保护的作用。

还有一点就是，如果你在不同的.c文件定义了同一个变量名，编译器一般也会报错。

还有一种方法，可以解决这种可重名问题，就是用static关键词。

这样就明确告诉编译器，我这些数组的作用域仅限于该.c文件，变量也是一样的道理，这样修饰以后你在别的.c文件也可以定义名字一样的变量，两个是相互独立的。

还有一个很重要的细节就是，对于那些不需要给外部调用的函数，我都用static关键词修饰。

这样可以增强可读性，方便后期维护，你一看就知道哪些函数是本文件内使用，哪些是外部的接口。