该省代码的地方要省，反之亦然。

意大利输球了，睡不着阿！现在就剩下德国和阿根廷是比较喜欢的球队了。

 

还是聊聊代码上的事情吧。什么地方该省代码？在我参与、开发和接触到的很多项目中，曾经都很喜欢在开始阶段做一个设计。这本身没有错，问题在于，经常在还没有用户或者网站总用户才几十万的场景下，去考虑高并发，去考虑高负载，去设计能够跑在N台服务器上的架构。现在想来这都没有错，不去尝试，不去思考就不会进步。当然，所考虑绝不是仅仅这一个问题，而是言必谈扩展性。积极地去考虑扩展性的问题，我一直认为是个好事情，假如我是老板，我一定会适当放松项目周期，以期让开发人员有更多的思考。事实上在我以期考虑这些问题的时候，我经常会把下班时间也用上，对公司其实并不一定吃亏。

 

但现在想来是一个极端的表现。现在想来应该是当时对使用到的技术的各个方面：比如I/O吞吐能力、线程并发能力、网络并发能力、事物处理等等，对他们都一知半解或者干脆就不了解。另外两个最重要的方面在于对需求定位不清，以及总想一步到位。不要试图说你对需求的定位很清晰，实际上需求方都不一定完全把握。就比如项目的生命周期，整个项目组真的清楚了么？对使用的技术缺乏整体上的理论理解，才会让人不之所措，以至于过分关注性能等问题。出现性能问题也不能立刻把握瓶颈。

 

跑题了，继续说说我对省代码和多写代码的理解。我认为，开发任何一个项目，只要不是一锤子买卖，都需要从整体进行把握。不但能有效地进行业务的后期扩展，也可以在协同中少走很多弯路。我认为只要不是自己能够把握的代码，都可以能省则省。那什么是自己不能把握的代码？举个离子，我开发一个项目需要用到B部门开发的一个系统，那么调用B部门系统的方式就是我不能把握的代码。更极端地说，如果B部门的系统还要依赖C部门开发的组件，那B不能都不能把握给我调用的方式，那自然我就更加不好把握。这种情况，就需要和需求方多沟通，让需求方于B、C部门保持沟通才能让我在开发时更加省力。这种情况一般把B给你的接口和你实际的调用方式分开更好。可以根据需求方的业务要求，制定自己需要的接口，然后再拿自己定义的接口和B部门提供的接口做适配。这样做有两个好处，没有他们的系统你也可以很方便地模拟数据进行单元测试，或者说是即便没有他们的系统，你的系统依然可以运行，只是不能用而已。另外一个好处是如果B部门的接口不影响你的接口调用的方式，就可以隔离掉对你的系统的影响。这样就将对B部门系统的依赖降到最低。一定要把整个过程当成两件事情，当整个团队确定要做一件事情，那先要保证你的事情做好了，然后再去看别人的事情做好没有。当然如果需求方在保持沟通过程中发现事情根本不能做，大家都放弃，那是最坏的打算。但不能因为这个理由而拖延项目的开发，以致项目延期。在这种场合就要多做设计，多写点代码，哪怕最后没用上都没关系。我做过的项目，没有中途不变更的，所以还是先考虑设计要紧。

 

刚才说了不要过分关注对未来的扩展，因为你也不能保证你的设计就能符合未来的场景。但是有一些设计还是可以做的，比如，可以将你认为会影响性能的地方抽象化，先做简单的实现。如果在项目上线后发现确实是这里拖了后腿，改动的化也只要改实现而不用重新架构项目。

 

那什么时候可以省代码呢？对那样根本不要重用或者很难重用的东西，可以考虑省代码，省设计。比如一个页面要以5种样子显示，老老实实地做5个页面就行了，不用过分地去设计。A页面显示10条数据3个字段，B页面显示.....如果做抽象设计会绕进去，我尝试过很多次，没有做到一个可以让我满意的方案出来。当然你也可以去尝试，我做不出不代表你做不出，呵呵。

 

一般来说不需要做多种解决方案的也不要过渡地去设计。比如做个日志，你不是要把日志存储到N种设备上就不用考虑设备相关。诚然，做得象log4j那样确实很牛，但common-logging中也提供的简单的实现。一般来说，一个团队形成的积累不用过渡考虑你们根本用不上的场景，那只是增加负担。