手把手教你写程序
手把手教你写程序<br />内容：从最简单的程序入手，手把手教你写程序，让同学们拿到一个复杂的程序或者任务，能快速找到切入点，写出程序，再在此基础上优化程序。当拿到一个单片机任务时，不要急于动手写程序，先仔细分析它的以下几个点：<br />1、它要单片机整体实现什么功能<br />2、功能细分（模块化），先干什么，再干什么，最后干什么<br />3、画初步流程图，（把几个模块画出即可）<br />4、模块之间的分析：一个模块到另一个模块之间，怎么变换，怎么连接（优化流程图）<br />5、单个模块分析：每个模块要做什么（流程图细化）<br />6、所有模块结合连接，细化所有流程图<br />7、分析单个模块每步要用到的方法或者指令<br />8、总流程图定型<br />9、纸上写程序，对照流程图分析其可行性，若不可行则返回<br />10、上机调试，加注释<br />以上十步，缺一不可（小程序列外）<br />切记：流程图的确定很重要，需反复修改<br />大忌：拿到任务，不仔细分析就写程序。即使是小程序，我们也要养成良好的编程习惯，不要一味的追求结果。写小程序可能比别人快，若是大程序，一旦出现思维混乱，或者出现程序调试不出结果，那么你花在调试上的时间，要比别人的多。 !!!!!!磨刀不误砍柴工!!!!!!<br />程序的优化：属于后期工作，只有调试出来后，才去优化，如果一开始优化和写程序同时进行，一是加重你的思考量，二是出现问题无从下手。无疑增加了写程序的难度。对于一个初学者，写一个程序，本身头脑就处于紧张的状态，思考的问题就很多，如果此时把优化程序也考虑进去，你脑袋的负荷无疑加重，若你头脑精明，你可以把优化的地方，先在纸上记下来，等到调试结果正常，再把你想到的，优化的地方加进去。<br />呵呵
你未必非要按照楼主那十条一条一条来，但是要了解楼主传达的思想：做设计前要做好文档工作（包括基本的流程图、时序图以及文字说明）。很多工程师都忽略这一点，认为文档工作浪费时间。你写个几十行的代码，可能不需要流程图，但是关键是要养成良好的习惯。因为你不可能总写小程序。<br />我工作中主要用FPGA，我们设计的每个子模块都要有文档：接口信号定义，模块功能介绍，详细设计实现思路，详细的时序图（因为是FPGA，很底层的东西，所以要精确到每个周期）。开始项目经理让我这样做，我也觉得很烦，很麻烦，可是做了几次，发现了好处：<br />首先，写文档、画流程图和时序图的时候，就是在思考和设计了，文档写完了，其实设计已经完成了一多半，而之后写代码、仿真和调试，只是对先前设计的验证。我喜欢用visio画图，主要的设计时间也花在了画图上。图画完了，也想清楚了，剩下就是把图插到文档里，添上文字和表格，思路再清晰一下。之后就是照着文档写代码了，写代码这部分我认为是不用太费脑子的，我有时会拿回家听着音乐，聊着QQ做。而在调试过程中遇到的问题，追溯起来也很方便。实践中，我感觉这样反而是省时间的（当然，别拿小程序说事，一辈子总写小程序也没啥出息）。<br />其次，维护和升级成本大幅度降低，技术交流也很方便。我现在写一个模块，可能几个月后让我加入新功能，那时可能很多东西都忘了。而有文档就好了，当时怎么想的，某些功能是怎么实现的，在哪里改代码比较合适：一清二楚，省去很多时间。更何况有时候这种升级、维护工作可能要交给别人去做，谁也不想自己写完模块半年甚至更长时间之后还让人追着屁股问这问那吧？那么文档是最好的方法，从个人角度说你省了事；从公司角度说，人力成本大幅度降低（他问你，浪费的是两个人的时间成本）。<br />为什么很多工程师不喜欢写文档呢？一则可能是嫌麻烦吧。我觉得吧，虽然现在我们是工程师，可能只负责一块，但是要试着去从更高的层次去思考和看自己的工作，这是有利于个人成长的；二则可能是有技术保密的考虑吧。很多人还是怀着“教会徒弟饿死师傅”的思想，怕自己很容易被替代，总喜欢保持神秘感。其实技术是学不完的，放宽心态，与其盯着自己现在的这点东西，不如多丰富自己，让别人永远追不上自己，那才是真正不可替代的。这对自己和团队都是有益的。你将来的高度，取决于你的心的宽广程度。<br />以上是我的一点体会，有不对的地方欢迎指正。 这就像写作文，有些人不写提纲、草稿就写不出好**，会写的一团糟；
而有些人可以不写提纲、草稿就写好一般的小**
（但对于大部头还是必须要写提纲的）
不写提纲、草稿并不是代表**没架构，只是架构暂时保存在大脑里而不是纸上罢了（小**、小程序）；
对于大的程序或者需要和他人协作的项目，还是必须要有详细的文档和流程的，不然肯定出岔子。
再就是，对于编程语言，实际上就和外语相对于母语一样，写程序也就和中国人用英语写篇**一样
只要够熟悉，对于熟手，编程语言理解上是没有障碍的，可以直接和逻辑语言相互转化，
所以不需要用中文流程图描叙一遍再用编程语言再写一遍。
当然，不管多高的高手，设计复杂的东西前先画个蓝图、框架并记录下来 都是必要的，但并不仅限于流程图
流程图能表达的东西很有限，并不是最好的草稿、备忘录方式，老x更喜欢用状态迁移图、迁移表一些
毕竟对于嵌入式控制系统，任何系统都可以抽象成有限元状态机