正文
大家好，我是bug菌！
今天回到了深圳，开始了今年最后4个月的工作，一年的时间真的过得挺快的，2021年又只剩下三分之一了，在返程途中思考了很多，有对未来的憧憬，也有担忧~或许人生也跟代码中的bug一样需要边写边解吧。
bug菌比较习惯集中抽出一些时间交流一些问题，所以在途中跟很多朋友聊到了学习、技术和生活上的一些事情，同时也对比了一下自己之前走过的路，所以就有了这篇关于软件开发设计经验与心得与体会:
1、思路不清晰，不要轻易敲代码
个人觉得代码这些东西，都是思维的产物，更何况现在也出现非常多的非代码类语言，比如labview等等。
刚开始学习编程的我也一直认为代码是敲出来的，一旦有新的软件需求，就噼里啪啦代码敲个不停，然而逐渐的发现这样敲出来的代码不仅质量不咋样，以后多半会遭到“无情的抛弃”。这也是很多朋友"敲三行删两行"尴尬场面的重要原因。
思维指导行为，这些都是学校学习哲学、马克思老师经常提到的，如果你手上还有这些指导思想的书籍，闲暇十分可以回味一下，会发现很多设计思想都有诸多相似之处~
2、状态机与流程图
既然要理清楚思路当然记忆力和逻辑思维足够强大，也是没有问题的。
一般人应该做不到，还得借助一些工具，简单点的话那就纸、笔，画个大体的框图等；复杂一点的还是需要借助专业的工具，比如思维导图，统一建模语言UML等。
特别要跟大家介绍的是UML，它对于嵌入式朋友们可能还有点陌生，其采用一种面向对象的方式来为系统建立一个模型和描述，其主要是图形的方式表述，类似于进行控制器设计前需要建立一下系统的控制模型，同样软件编码设计也需要这样一个模型，那么bug菌推荐UML。
有了这些辅助工具来设计软件，这样就能从整体上把控软件的脉络和组织，对后续软件功能的增、删、改都能有一个比较清晰的把握。
同样状态机也是必不可少的，一个功能分哪些状态，每个状态该如何转移，似乎看起来没什么难的，毕竟状态机的实现文章多如牛毛。
其实状态机的难点并不在于状态机的如何编码实现，难点在于一个功能如何更加合理的把所有状态和各状态的转移条件分好，状态分太多，没有意义，影响运行效率，程序冗长；状态分得太少，每个状态相对比较复杂，不便于模块化，不好维护。
那问题来了，如何把状态和状态转移区分好呢？这个问题有点难回答，针对不同的项目和需求，需要结合自身对该部分功能的理解和抽象，以及未来对此部分功能的扩展等综合考虑。
3、编码习惯与版本把控
所谓"没有规矩不成方圆",编码习惯bug菌也是在之前的文章中反复强调，因为直到现在我还时不时受到以前老项目的维护之苦。
我们得承认编程语言都一个样，不过编程的思路和方式却千差万别，不同的人编码习惯或者风格差异太大，犹如两个互相不懂其语言的外国人，而文档、注释就是这中间的"翻译官"。
而版本把控主要是为了各种文档、设计资料的变更，类似于git这种分布式版本管理系统还是非常有必要的。
像我司要求负责开发项目的同事至少一天上传一次设计资料及代码，因为每个人粗心大意是难免的，经常有后面的设计远不如之前的情况，所以为了降低这块的风险，版本的管控在软件开发中是非常有必要的。
4、多参考官方资料
大部分软件开发工程师都属于应用型工程师，更多的是站在巨人的肩膀上来应对一些新的需求，所以很多成熟的、官方的技术知识更多的是详细了解其如何使用，而非花太多的精力重复造轮子。
如今网络化时代，文档资料也是鱼龙混杂，然而把官方、权威的文档资料放在旁边作为参考才会让人更加安心。
最后
好了，bug菌大致就总结了这些吧，觉得有所收获，记得点个赞哦~
推荐专辑 点击蓝色字体即可跳转
☞ MCU进阶专辑 
☞ “bug说”专辑 
☞ 专辑|手撕C语言
☞ 专辑|经验分享
6760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
