一个工程师的成长过程，总是惊人地相似，曾经我也和大家一样，一直想解决程序如何写能更好这个问题。
全局变量太多难管理，看起来是个小问题，要想解决其实背后涉及很多东西，否则不如你直接加注释来得更直接。
变量确实要用，你省不了，你只能通过别的方式去规避乱的问题，比如说一些编程技巧和思维。
后面经过无数项目洗礼，我个人领悟是：一个程序写得好不好，主要看程序算法和程序架构。
先来说说算法好了，算法不是刚需。
很多新手以为程序要想写得好，跟英语和数学水平有关系。
今天我给大家交个底，并不是，最多数学好算法能做得更优，大多数产品算法都不复杂，单片机能做多复杂的运算是吧？
很多算法，难在前端公式剖析，不管再复杂的项目都好，最后体现在程序里的都是加减乘除，与或等这些简单运算。
举个例子：
请给出能够计算出结果等于8的公式。
不同的人，计算出来的公式可能是不一样的，比如以下几种公式都能实现。
公式1：(1+1)*(2+2);
公式2： 1<<3
很明显，公式2的计算效率更高，主要是体现在汇编指令更少，机器周期自然更短，所以说算法更好。
实际上真正的算法比这个要复杂得多，这里只是举个例子而已。
像这种公式，一般我们在小笔记本上先算好，最后转成用加减乘除之类的公式用程序写出来。
大多数情况，只要产品实时性要求不是特别苛刻的，公式1和公式2你看不出任何区别。
并不是每个行业的产品都需要算法，每个行业的算法肯定也是不一样。
哪怕你数学很差，都没关系，你找个数学厉害的人，告诉他你要算什么。
让他用加减乘除、与、或、移位运算帮你算出一个最佳解题公式，你带入到程序直接用就行了。
所以我们在做产品的时候，不要过度去追求程序执行效率，只要能满足需求就好，并不是刚需。
研究算法是很浪费时间的，通用性也不强，反正就是性价比很低。
下面再来说说程序架构，这个实用性和通用性极强。
而且可以说不懂架构中大型项目绝对做不来，不是做不好，而是做不来！
可能很多人工程师做了几年，已经碰到了瓶颈期，一直想提升，又无能为力。
比如说，变量多了，函数多了，程序总是乱糟糟的，一整合起来一堆BUG。
这个功能好了，影响了别的功能，改了别的功能，这个功能又不行了。
最后马马虎虎把代码好不容易整合起来实现完整的产品功能了，也没BUG了。
挨千刀的老板又跟你说要改功能，在刚开始做研发那几年，我就最怕增加功能、改功能。
哪怕只是把LED改成每秒闪1次，又或者说增加一个按键这么小的功能，如果架构不好的话，都有可能花上你一周甚至更长。
那程序架构到底是什么？
我认为是一种成熟的编程思维，是经验的总结，比如RTOS就是属于一种程序架构，STM32固件库也是一种程序架构。
不同的人，编写出来的程序架构都不一样，有大的有小的，最重要是够用就好。
而全局变量多导致程序乱的问题，就可以用程序架构的模块化编程特点来解决。
|
楼主
标题置顶
标题高亮
