在学编程的时候，都是一边抱着书，一边敲代码，这样的小孩学舌的方式学习，慢慢的就把书变成字典，需要的时候再查查，去开发小工具，基本都是一边写，一边解决问题，程序可以跑了，就是算完成了，这样作坊时的学习办法在学习期间是经常用到的，但到了工作中，这样做就不行了。
在最开始的工作中，我还是依靠自己的习惯去开发，任务布置完毕，风风火火的就打开了VS并建立了工程，然后不停的敲代码，不停删代码，直到把这个任务完成，提交，然后组长取代码审核，并告诉你补上文档，然后修改bug，增加需求，重构，如此迭代下去，直到这个工具看来算靠谱了，就可以用了。但随着工作时间延续，对代码质量要求的提高，重构和修改bug的次数越来越多，组长的检查点也不光是代码，还包括框架结构，数据结构，实现方法，工程进度安排等，这个时候，作坊式的开发方式就遇到了瓶颈，突破瓶颈的办法就是：做计划，做总结。
在接受需求的时候，要充分理解，这点相信写程序的人都知道，当理解完毕需求后，就要安排计划，画流程图，画数据流图（有些不需要），定义数据结构，安排进度，时间点细化到小时（需要循循渐进，最开始安排到天就可以了），定期总结，安排与需求人见面的时间等等，然后跟需求人对一下，同意后在开搞，按照计划，按照流程图去写代码，遇到瓶颈，可能会耽误进度，那么就需要重新制定计划，根据自己的实际能力重新分配时间，该加班就加班，如果需要延长计划时间，那么就要跟需求人沟通。定期总结，把这段时间做了什么，遭遇了什么问题，如何解决，下次如何避免等等的记录下来，这些都是经验的沉淀，就是工作经验。
说是简单的，做就难了，光说花流程图的事情上，其实就是对自己能力和经验的考验，流程图不是随便画的，对功能点不理解，对技术困难没有预计到，都会导致进度的延误，但这也没有什么捷径，只有努力和坚持的去做，时间长了，就有效果了。
我现在就在这条路上。