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

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

 

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

 

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

 

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

 

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

 

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

 

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

posted @ 2010-06-25 01:46 Birdshover 阅读(...) 评论(...) 编辑 收藏