扫码关注
今天继续转载小号一篇原创内容，这个问题写过几次，但是有时候想得没那么周全，这个问题也是成长必经的，所以又写了一篇，如果对老铁们有帮助，麻烦点下面小卡片关注一波。
每个攻城狮的成长经历，目标总是相似的。
刚开始学习这门技术的时候，希望自己能独立做出各种各样智能的产品。
有了这能力，更有竞争力，也更挣钱，在越来越智能的时代不至于被抛弃。
可惜并不是每个人都能走到终点。
很多人学着学着就学不动了，最后遗憾放弃
有些人虽然走了很多弯路，凭借惊人毅力一样挺了过来。
这一路有太多的瓶颈需要突破，每一个都可能决定你是天选之人，还是淘汰者。
对于刚入行的工程师来说，有一个瓶颈非常难突破。
那就是如何让自己写出来的程序更专业。
有很长一段时间，虽然功能自己都能写出来，但是总是觉得自己的程序写得乱七八糟。
上图是我刚从事单片机开发1年写的程序，不知道大家看出什么问题没有。
我来给大家分析下：
1.整个项目程序都写在main函数里
2.全局变量过多
3.没模块化思维
就是这个项目程序逻辑，调到我快崩溃了。
其实产品也不复杂，就是一个太阳能热水器的控制板。
不过一组合起来，功能之间就会相互冲突得很厉害，导致改了这里，那里又出问题。
一出问题所有功能又要重新测一遍。
如果你没经历过这种问题，你不会理解程序架构的重要性。
程序架构的好坏会影响整个程序的方方面面。
比如说全局变量，后面我也意识到了这个问题。
就是全局变量多了，程序大了会掌控不住。
第一个是要避免全局变量名字重复，第二个如果哪个变量没做注释，1个月后干干净净。
特别是你把整个项目功能的全局变量定义在一起的时候，简直就是灾难。
但是，不用全局变量肯定也是不可能的。
只是要用得合理，这时候就比较考验工程师的经验了。
我是怎么做的？
拿我们无际单片机编程物联网网关那个课程项目来举例。
我采用了模块化编程的思维，从整体架构上分硬件层和应用层。
一般来说还有中间层，比如解析一些协议之类，项目中间层的代码不多，被我简化了。
每个功能模块的全局变量，都定义在各自的.c文件里。
跟我做的那个太阳能热水器控制板的程序对比，虽然全局变量的数量可能没变，但是很明显模块化的写法更加清晰。
当然，这不是让代码看起来更清爽这么简单，还有功能可扩展性强，可移植性强的优势。
可扩展性强，听起来是一个专业术语，可能很多新手不是很理解什么意思。
你试想一下，好不容易产品功能代码完成，测试也没问题了，交付给客户测试。
客户测试完，说要改功能，来来回回改个7,8次，你是不是离职的心都有了？
这是常态，客户对于技术是一个小白，他并不知道他的一句话的背后，你需要付出多少。
有经验的工程师，从学会有能力偷懒开始，再急的项目，你做完还有空闲时间那才牛逼。
这就是代码可扩展性的重要性。
下面再来说说可移植性。
可移植性是相对单片机(硬件平台)来说的。
比如说这个项目以前我在STM32单片机上做的，现在芯片涨价了，老板要求换成GD32的替代。
这个时候就考验你程序的移植性了。
有经验工程师写出来的程序，一般只需要改改硬件层的外设接口，应用层的产品逻辑功能代码基本不用动。
而菜鸡可能就要重写整个代码了…
一个全局变量的问题，看似简单，要想解决，还是得站在整个程序架构的角度去思考。
如果，你离这个阶段还很远，还有一个比较便捷的方法。
就是用结构体。
用面向对象的思维，把同类的变量统一定义成结构体。
比如说时间分为年、月、日、周、时、分、秒。
如果用单独全局变量的形式，比较零散，也比较难管理。
这种，就比较适合用结构体了，因为这些都属于”时间”这个对象的参数。
类似的还有很多，比如说GPIO也算一个对象，参数有端口号、引脚号、输入模式、输出模式、频率等。
可以看看STM32固件库，就是很典型的面向对象编程思维。
