最近一直有这样的感触，
软件项目或许应该看成是把信息重新组织，然后调库实现的过程。
即使人们眼中的“纯技术项目”，也是如此。
很少有项目会从零开始，大多数项目都是采用现有的实现，
是否调整现有的方案，取决于在使用过程中是否遇到了问题。
没有遇到问题，就不要重新造轮子，因为投入产出比太低。
比起社区中现有的成熟方案，
自己写的新代码，很难考虑的足够周全，
只有经过多轮修正之后，才会变得稳定可靠。
没有看清当前到底要解决什么问题，
或者容易将问题解决与个人成长相关联，
是人们很容易掉入的陷阱。
带着问题去行动，始终明确自己的目标，
才能让工作更有成效。
编码的层次
在编码之前，我们应该先明确编码的目的，
不相关的代码，不要写。
为了编写商品展示页面，没必要重写一个双向绑定库，
为了搭建工程脚手架，也没必要重写一个数据流框架，
为了创造新的构建工具，更没必要重写一个语法解析器。
为了实现目标，没必要转而去考虑另外一件没问题的事情。
我们得时刻保持清醒，知道自己在什么位置在哪个层面进行工作。
现实中，有不少人在做某件事情的时候，容易被其他事情所吸引，
这经常会被错误的解读为更强的好奇心，或者能举一反三。
这是自欺欺人。
技术的深度
很难说技术的深度和广度哪个更重要，
不过，很少有人会单纯以技术广度作为自己的核心竞争力。
没有深度的广度，将没有意义。
如果做事的时候，不够专注，总是容易被其他事情所吸引，
那么在技术深度上，就难有建树。
因为不论在什么时刻，我们总是不清楚当前最重要的事情是什么。
如果使用 webpack，会导致我们研究源码，
研究源码，又会导致我们学习 acorn（parser），
学习 parser，我们又会被编译器设计所吸引的话。
这个链路中的每一个环节，我们都很难有深度。
因为我们不清楚自己的目标是什么。
我们到底是学习使用 webpack，还是学会 webpack 的实现方式？
到底是学习具体的 parser，还是学会通用的编译技术？
每一个领域，我们都浅尝辄止了，学了个四不像。
问题导向
因此，我们应该围绕着技术深度，拓展广度， 带着问题学技术。
我们得清楚的知道，当前的目标是什么，
而对其他相关事情的了解，也不是多多益善的，不要乱点技能树。
如果我们想学实现原理，那么就专注的看源码，
不要转而去学相关的理论知识。
如果当前的目标是补充理论知识，那么就别再转而去学基础数学。
不断的挖坑而不填，是一种不良的学习习惯。
这并不是说不要钻研，而是应该有意识的限制自己向下钻研的程度，
够用就行了。
结语
独孤求败在剑冢中埋了几把剑，
（1）利剑：凌厉刚猛，无坚不摧，弱冠前以之与河朔群雄争锋。
（2）紫薇软剑：三十岁前所用，误伤义士不祥，乃弃之深谷。
（3）玄铁重剑：重剑无锋，大巧不工，四十岁前恃之横行天下。
（4）木剑：四十岁后，不滞于物，草木竹石均可为剑。
这也反映了一个道理，目的是首要的，手段次之。
年轻时确实应该不断的磨炼技能，为了能做更多的事情，为了“横行天下”，
可一旦到了某个阶段，再追求技能本身就意义不大了，
应该考虑怎样快速的达成目的，“草木竹石均可为剑”。
所以，工程还是要跟科研区分开的，即使做的是创新项目。
创新项目之所以创新，主要是覆盖了全新的业务场景，
并不是用了鲜为人知的高端技术。