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