前几天听同事感叹了一句，说web前端的东西还是挺多的，每一个东西要弄明白用起来都得花上一些功夫。真可谓远行无轻担，看起来好像是那么回事，做起来是另外一回事，所以也就间接让我会感觉到我啥也没干。

不管具体是怎么做的，做的好不好，代码写得优美不优美，这些在从0到1的过程中不是最紧要的因素，最紧要的就是设计和功能提炼。

这里所说的设计是基础的架构，就好比水手要出海捕鱼，是划一个小渔船，还是一艘大船，前期的基础设计不佳，在后面接入业务的过程中就很快遇到瓶颈，如果业务都跑起来了，然后大改，那这个影响可就大了，可能原来几行代码的事情到后面得迭代很多的验证步骤，分阶段分批来最终满足需求。当然也不能让自己的系统设计的过于庞大，一下子成了航母级别，每张表都很不得放一个单独的数据来存储，管场景里面用到了没有，但是开源技术方案要多要炫，这样也是不好的。

高屋建瓴，最终不落地，脱离了实际，也就脱离了价值。

然后是功能架构，这个部分的工作其实就有些偏产品经理了，因为需要明白需求的通点，需要分门别类的对需求进行功能抽象，最终想的和看到的产品能够衔接起来。至少不会出现太多别扭的界面操作或者是有歧义的细节。

这个部分的重点工作之一就是按照优先级来梳理。哪个阶段做哪些事情，按照一定的方式来组织起来，最终就会呈现出一个日程和计划来。

做这些事情还是希望形成闭环，要不分门别类，面铺的大，但是很难看到一些连接或者闪光点。就好比一个看起来比较基础的功能，如果大家看了以后，发现这个东西好，那么都愿意去接入，都会把一些基础的功能需求激发起来。

技术工作者的一大价值就是解决问题，解决的问题越多，才会得到成长。

这些工作做好之后，目前已经接近尾声，我计划尽快实现闭环，当然实际和自己预期的还是有差距，而且越深入了解，发现差距越大。

所以这个工作不得不放入一个并行的过程。接下来需要考虑实现的几件大事，主要有脚本管理，不能的功能模块和业务类型可以对应不同的脚本，比如shell,sql,python等，总之脚本需要管理起来，算是脚本化的一个开始。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2152326/，如需转载，请注明出处，否则将追究法律责任。