我一个业余的选手，主要爱好就是搞博客主题，自己写后端和前端，程序设计时会写些算法的流程图帮助自己分析和分布解决问题。但是我这个流程图真的就是算法的分析，不是正规的程序流程图，请问各位大大你们写代码时是写规范的流程图还是按自己的方式写“流程图”？
我没有资格以自己的经历回答这个问题，所以引用Brooks博士《人月神话》中的关于流程图的说法：> 流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图。
作为前端，我几乎没有画过和算法相关的流程图（必须要承认我的算法很差），也不知道该怎么画这样的流程图。我通常就是一张纸和一张笔，然后把问题大大的写成标题，接着开始拆分问题：竭尽自己所能一层层的把大问题拆成小问题直到无法再拆开或是没有必要再拆开为止。
在这个过程中，我往往能够发现或认识到自己最初的想法是有问题的，可能是方向有问题，也可能是细节考虑的不周全。如果问题本质上很复杂，我会从拆分出来的点中寻找一些 hint point，比如说：哪些问题是可以用第三方库来解决的，是否需要封装？（根据当前项目所用的技术栈来定）哪些问题是必须自己开发解决方案的，是否需要重用？扩展？
不知道这样的方式算不算画流程图，不过在我看来这的确是在梳理自己解决问题的思路和流程。等到全部的问题点都已经确认无疑之后，就开始为哪些心里没底的解决方案去寻求答案，文档、谷歌、Github、SO……这些都是寻求答案的宝地。
一切就绪之后，开始写测试；这一步不是必须的，但只要事件允许我一定会写，因为在你不确定问题是否可以得到解决之前，很有可能要面对重构或改写。测试的目的就是保证所有的问题可以用代码的方式来验证，一旦你开始重构，测试可以保证你不会偏离既定的目标和方向。
一般来说到了这一步很少会有解决不了的问题了，最后就只是代码实现而已，最终写的好不好那要看水平和经验，但是就解决方案本身来说已经是相当好的了——有理有据，条理分明，还有测试保障。
然而除此之外，我的确画过很多交互方面的流程图，和具体的代码无关，是 UX 层面的事情，但我觉得这才是前端应该经常去做的事情。