因为刚来公司，很多时候都是做需要，而这需要对业务体系十分熟悉，所以公司的一个师兄，做需求十分的快，并且很多时候，我们碰到了解决不了的问题，都会去询问他。
前段时间，刚来公司的时候，CTO跟我说，碰到不懂的就问，导致的结果就是我很多时候，不该问的也问了。CTO说的这个不懂应该是指具体实现上不懂，而不包括其他
这几天接了几个比较麻烦的需求，花了不少时间，经常被我询问的老大因为实在太忙了，所以也不好多意思去问，就自己去硬看代码，结果就是当你真的理清思路的时候，一切都变得简单了，很多时候并没有想象中的那么复杂。
以下是这几天的一点体会：
- 接到一个需求或者任务的时候，第一件事情要做的不是写代码，而是弄清楚需求。
- 第二件事情也不是写代码，而是思考整个业务逻辑流程。
- 第三件事情是看原来的代码，而不是写，当然了，如果是个新的东西，那么最好也要理清楚头绪。
- 如果你思考了整个需求的流程，那么其实开始写的时候，并不会多么的麻烦，感觉如果不思考，直接开始写，一是代码质量很烂，二是你永远不会得到成长，因为大脑很可能会形成惰性。
- 在google也帮助不了你的情况下，再去问人。
- 很多时候，再多思考一点，多尝试一点，也许结果就出来了。
以上的几点，以前只是知道，现在才体会到，我想，几下来的成长会更快。