编写代码的两个侧重点——功能开发与效率开发

写在前面

前几天，小妹家又添了一个男娃；于我而言，又多了一个喊舅舅的孩子，加起来总共有四个了。

GitHub - chalvern/simplate: simple template of golang 一个简单的golang模板库，把所有的模板文件加载到内存中，并以map（称为哈希或字典）的方式组织模板。

上周花了整个周末的时间读了一下瑞·达利欧的《原则》，认识到了很多问题，思想上得到了一次大补给；加上最近团队内部分享讨论的风气比较优越，和身边的各位大佬切磋比较多，于是产生了一些新的觉悟。

这觉悟不仅仅关乎代码，还关系到生活的其他方面，不过只有代码方面的思考能够直白地描述，因此这里就简单写写它：编写代码的两个侧重点——功能开发与效率开发。

平日里我工作的主要内容就是编写代码。在DevOps小组做基础架构，平时主要涉及一些公共服务的开发。最近出现一个紧急需求，于是投了一些精力做业务开发。

应该说，无论做基础架构的服务，还是做纯业务的需求，都不是那么容易。而作为一个优秀的开发者，总能站到一定的高度思考并解决问题。我相信，这种“解决问题、获取成长、继而引发进一步思考”的过程是一名高级开发者与一名初级开发者的重要区别。

根据自己编写的代码性质，我把它们分成两类，一种涉及到功能的开发，另一种涉及到效率的开发。当然，这二者所占的比重是不一样的，前者占用了开发者大概80%的时间与精力，而后者只占到开发者剩下20%的时间与精力。

在我迈入职场生涯的第三个年头，编写代码已经变成一件得心应手的事情。不过，编写代码永远不是一件轻松的事情，尤其在需求不定的时候，尤其在没有产品经理帮忙梳理业务逻辑的时候，尤其在业务决策不定而需要开发者推动进度的时候。

如果仔细观察会发现，平时程序员的大部分交流都是围绕着业务展开的（假如聊的不是互相吹捧的话），而对于编程语言的语法特性、架构设计等交流的频次则很少。其实，如果工作时能和同事聊到编程语言的语法特性或者架构相关的事情，心态上要轻松很多。

那么，作为一名程序猿，应该如何在解决繁杂业务问题的时候提升自己呢？我先把问题摆在这里。不过基本可以向着这个方向考虑：多了解需求，成为梳理并拆分庞大需求（对应繁杂的问题）的人。

在编写代码相关的工作里，相对于功能开发，效率开发发生的几率要少很多。在参加2017年在杭州举办的Ruby开发者大会时听到一种说法，”只有成功者才会跑数据看性能“。一年过去了，在经历了几个项目后发觉此言不虚。

一次调用耗时为50毫秒还是200毫秒，同等内存与CPU资源条件下跑2000个并发还是1000个并发，等必须要做这一层优化时，说明相应的项目已经成功了；而在此之前，大部分项目的主要矛盾是功能的开发。

最近半年的时间里，我逐渐意识到另一个层面的效率问题——开发效率问题；比如如何让团队里的成员更好更快地上手新项目，接手老项目，直到最近才想清楚该如何面对或解决。此事一定程度上涉及到工具研发的内容，比如：编写通用的工具库，抽象更方便使用的库，制造开发工具，编写易懂详细的开发文档等等。

作为一名程序猿，如果能涉及此部分的内容且喜欢这部分的内容，则可以奔着技术管理或技术专家的方向发展。

在我未毕业时，心气一直是很高的，觉得凭着自己的聪明才智，可以很快地完成一些牛逼的事情。而随着对职场的进一步了解，随着对社会的进一步了解，发现自己当时的想法是多么地稚嫩。有些东西，若非亲身经历过，头脑再聪明都只能是纸上谈兵，而纸上谈兵是很难获取真正的胜利的。

对此，我能想到的是《三个火枪手》里达达尼昂的老爸在达达尼昂出发闯荡前给他说的话：”去闯荡，去犯错，去战斗，去爱，去挣扎“。只有如此，才有可能成为一个真实的英雄。

加油，年轻人。