简短来说，就是要战略上藐视它,战术上重视它。正视这份工作，尽量不要有心理暗示：这个功能不好搞，写起来比较复杂。实现细节上，可以慢慢规则，个个击破，最后整个拿下。
近阶段的功能开发就是一个很了的例子，拿出来跟大家分享下。项目情况是时间紧，任务重【而且往往是这种情况，呵呵】。大部分开发人员工作时间比较短，经验少就很容易造成需求理解不顺畅，功能开发效率不高的情况。伴随着而来的就是成本沟通成本的急剧升高，往往一遍还不行。
有的只关心视图展现，有的只关心局部功能，有的想让自己这块尽量简单而忽略背后牵扯的额外逻辑等等，在我看来，都不是一种顺利开展工作的好苗头，而是后磕磕绊绊中前行，效率以及质量可想而知。
之前有整理过此类文章【我只负责编码实现，这个你去找业务】，在之前的项目中我也是一直跟大家强调，一定要树立全局观，虽然在一个项目中，个人的任务点可能仅有那么几个，但一定要把业务逻辑理顺，数据走向理通，涉及到系统间交互的，也要把数据交互流程捋顺，不然真正编码开始，会举步维艰，一个问题接着一个问题，虽然有时候理解透彻了还是会有问题出现，但这完全是两个层面的问题。大局观有了，看项目的角度就会不一样，对项目的理解上自然比零散的功能组合更加深刻透彻，其实对自己的商业思维也是一种锻炼，难道你要一辈子敲代码？就没想过自己创业到老板？
上面扯了这么多，对编码究竟有何益处？想必有过经历的都有体会，搞清楚上面提到的，编码思路会很清晰，coding起来很顺手，甚至不用与其他人过多交流，开发效率非常高。
当然了，自身技术实力得过硬，要不然业务再熟练，巧妇也难为无米之炊啊！还得加强内功训练。所谓训，就是要在理论层面提升。所谓练，就是结合理论进行实战锻炼。两者结合，才能相得益彰。提升自身技术实力渠道很多，在之前的文章中也有提到过【IT码农如何保持竞争力】,国内的技术分享环境也比之前好了很多，也是一个好现象，笔者也身在几个技术交流群中，受益匪浅。
总之，行此文的主要目的，就是希望能帮助到朋友们认识到业务掌握、主动意识、全局观念等对编码影响很大，虽说不是硬技能，但算的上是软实力，技多不压身。
