不能为了敲代码而敲代码

        在公司实习了一年，接触了不少项目，但是基本都是做后半期的事情。由于本人还是菜鸟，心思都投入在怎么写好代码上去了，所以对业务上的事情基本是一问三不知，同事都对我有点。。。。哎，我都惭愧死了。好在带我的人了解我的情况，业务上的问题基本都是他帮我答了。我也逐渐发现了自己的这个不足，但是由于技术还是不够好，所以重心还是没怎么放在理解业务上。直到上周和公司高层聊了以后，才发现理解业务是多么的重要。

        在快要正式入职的时候，我被带我的人指派负责云计算项目中的负载均衡部分。一开始他跟我讲了整个项目的架构设计，我也基本上理解了。不过却没有说负载部分的架构是怎么样的，而我也没有去关注。他也说了我的主要任务就是将负载配置持久化并且启动/停止haproxy和重启nginx（haproxy和nginx是啥大家不清楚的就去查查吧），我一开始觉得这个挺简单的么，也没太在意其中的问题。所以在拿到他写的接口设计以后，我就着手写实现了。但是写着写着出了不少疑问，比如：一个haproxy上挂两个app还是两个haproxy负载一个app，这问题直到上周我才搞明白。诸如此类的问题还有不少，也还好他写的接口业务含义都比较清晰明确，不过这也是必须的，要是接口没表达清楚业务那这接口就白写了。

        前两天，我正在测haproxy的启动和停止，这时带我的人的领导，也算是公司高层领导了，过来问我正在做的负载均衡。我跟他把具体的负载配置和业务都说了一遍，他就问了一个问题：对于haproxy的启动和停止，具体是一个什么执行过程？我想了想，就直接说把某个负载应用的haproxy都停掉然后再重启。他又继续问到：那假如我要访问应用的时候，都停掉岂不是不能访问了？确实，这问题我没有考虑到，正确的做法应该是一个一个停，确认停掉的重新启动以后，再去停另外一个。然后又看我的代码，就是向我之前说的，全部都停掉并且都重启。然后他就叫我自己在看看。。。。

        其实项目进展的这一个月，我也发现要理解业务不需要花太多时间。平时工作时间敲代码，中午吃饭休息的时候就可以看看文档和之前写的代码理解下业务。如果文档和代码写的好，理解起来真不是什么难事。这是我这段时间的总结，新人总结都会有不足之处，还请前辈们指点。理解业务还有一个办法，就是测试。代码写的差不多了，总得测试下吧。基本的功能性单元测试完成以后，就得进行业务性测试。这么多天我一直在进行业务测试，因为是从外部测试业务接口，我又能看到实现，所以对某一个业务流程从代码上就能看得一清二楚，要是有不理解的再结合文档看看，基本上测个几遍就能明白了。但是像haproxy启动/停止这种很关键的点，说真的，这些问题并不是文档里能看到的，而是要经过很多的磨练，对业务的深刻理解，结合程序的运行情况，才能考虑到的问题。

        做咱们这行的，一定不能为了敲代码而敲代码。也许像我这样比较早就接触相对复杂的系统，接口都是别人写好的，自己就写写实现。虽然纸面上的业务也许不需要考虑，但是具体实现的某些业务细节，也是不能忽视的。而对于已经负责某一功能的程序猿来说，各方面的业务知识都是必须要掌握的，不然你觉得不理解业务的人写出来的代码，能用得放心么？我个人比较痴迷技术，以前对业务也是不以为然的，就决心认真的钻研技术，希望自己能发明某个新技术让大家使用。但是现在看来，再怎么钻技术，也不能脱离业务。可能脱离业务的技术能研究出来，但是当面对现实的业务的时候，这种技术真的能运用到业务上吗？像现在我们用的各种语言，技术和框架，说到底了，都是为了某类业务才发明出来的。所以嘛，程序猿们还是别只知道代码，从各方面多了解业务，多将代码和业务揉和起来，同样是很重要的。和不同的人探讨业务需求，还能改善我们的交流能力，何乐而不为呢。