意大利输球了，睡不着阿！现在就剩下德国和阿根廷是比较喜欢的球队了。
最近一直都在看世界杯，很少关注园子里面的事情了，但是好像每次打开首页都会看到一群人在批斗（不知道这个词用的对不对）firelong，这个让我不禁想起了以前一群人批斗格日的“水贴”。但是在批斗的人当中又有多少人想过你批斗的对吗？但反过来支持的人，你们支持的也对吗？
以前在一个技术群里面有一个香港的也是做技术的，姑且叫作某某吧。某某这样评价过他们公司的市场：读书少，脑袋转的慢，死脑子。为什么了？因为他们提了一个做im的项目，但是这个市场直接就问了一句：怎么跟msn和qq竞争？最后，这个项目做了1年，2个人做，做的很好看，买个了国内一个市的公安局，20W。但是其实这个项目已经是一个很失败的项目。开发费用起码30whk$(这位老兄2w一个月）。但是他在群里面说上面的话的时候我惊讶的发现竟然有那么多的人同意他并且附和他。难道程序员真的没有一个知己的思想的？
回到现在园子里面的口水仗。其实各位看官不知道有没有注意到一点，firelong用的是C++和C#比较。其实这个不必要比较。C#必败。就好象让C++达到.net安全性一样。但是我不知道各位看官有没有看到其实微软已经解决了这个问题就是托管C++和非托管C++。其实.net的定位就是java版的C++builder。我想微软已经做到了这一点了。再者，firelong使用所有的文章的论据都是以偏概全的。第一、反射是慢，但是反射是为了解决什么的？反射本身就是以性能作为牺牲的。第二、客户端现在不用.net是因为微软这两年才开始在操作系统中绑定.netframework，我想如果微软不倒，过几年应该就会很多了。第三、服务器方面的，这点我承认微软做的不好，mvc的落后，市场营销的失败还有就是java刚开始大好河山这三点让微软在大网站上没什么作为，但是如果看一下小网站，其实你们会发现微软已经占了半壁江山。第四、企业应用方面，这一点说真的微软真的不怎么样，一是因为firelong举出的所有的好的企业应用都是行业的领头羊，而是因为你总不能够要求微软十全十美吧。三是因为如果你要我给一个好的企业应用我会给你说winnt。第五、据说微软现在的重心除了windows，office之外就是家用设备（xbox，家庭娱乐）这个是在浪潮之巅看到的，各位可以看一下，所以如果这点成立，那么微软的ce还是很成功的。
我说了这么多，不知道各位看官有没有想过这些问题了？还是被人牵着鼻子走了？其实firelong说的都对，但是都是偏门。用辩论的术语来说就是诡辩。在回到某某身上。其实我当时很想给他说，一个产品不像一个项目，一个产品一定要有自己的市场定位。只有有这个定位你才可以去推广。现在国内做im做的好（能赚钱有钱途）的除了qq剩下的应该是飞信了，但是各位有没有想过为什么飞信可以做好了？其实如果各位细心的想一下，你就会发现，飞信依托的是移动巨大的市场，2e多的活跃用户，这是一个什么概念？所以不是所有im都可以成功的。
我觉得这两年可能园子里面的人多了，所以好像气氛更加浮躁了。没有了以前我刚进博客园的那种平和。程序员需要淡定，需要倾听，更加需要分辨。明辨慎思笃行。不要老是不经思索就附和，这样你永远都只会是一名程序员，而且是一名不合格的程序员。
无意批判各位，如有冒犯万分抱歉！
还是聊聊代码上的事情吧。什么地方该省代码？在我参与、开发和接触到的很多项目中，曾经都很喜欢在开始阶段做一个设计。这本身没有错，问题在于，经常在还没有用户或者网站总用户才几十万的场景下，去考虑高并发，去考虑高负载，去设计能够跑在N台服务器上的架构。现在想来这都没有错，不去尝试，不去思考就不会进步。当然，所考虑绝不是仅仅这一个问题，而是言必谈扩展性。积极地去考虑扩展性的问题，我一直认为是个好事情，假如我是老板，我一定会适当放松项目周期，以期让开发人员有更多的思考。事实上在我以期考虑这些问题的时候，我经常会把下班时间也用上，对公司其实并不一定吃亏。
但现在想来是一个极端的表现。现在想来应该是当时对使用到的技术的各个方面：比如I/O吞吐能力、线程并发能力、网络并发能力、事物处理等等，对他们都一知半解或者干脆就不了解。另外两个最重要的方面在于对需求定位不清，以及总想一步到位。不要试图说你对需求的定位很清晰，实际上需求方都不一定完全把握。就比如项目的生命周期，整个项目组真的清楚了么？对使用的技术缺乏整体上的理论理解，才会让人不之所措，以至于过分关注性能等问题。出现性能问题也不能立刻把握瓶颈。
跑题了，继续说说我对省代码和多写代码的理解。我认为，开发任何一个项目，只要不是一锤子买卖，都需要从整体进行把握。不但能有效地进行业务的后期扩展，也可以在协同中少走很多弯路。我认为只要不是自己能够把握的代码，都可以能省则省。那什么是自己不能把握的代码？举个离子，我开发一个项目需要用到B部门开发的一个系统，那么调用B部门系统的方式就是我不能把握的代码。更极端地说，如果B部门的系统还要依赖C部门开发的组件，那B不能都不能把握给我调用的方式，那自然我就更加不好把握。这种情况，就需要和需求方多沟通，让需求方于B、C部门保持沟通才能让我在开发时更加省力。这种情况一般把B给你的接口和你实际的调用方式分开更好。可以根据需求方的业务要求，制定自己需要的接口，然后再拿自己定义的接口和B部门提供的接口做适配。这样做有两个好处，没有他们的系统你也可以很方便地模拟数据进行单元测试，或者说是即便没有他们的系统，你的系统依然可以运行，只是不能用而已。另外一个好处是如果B部门的接口不影响你的接口调用的方式，就可以隔离掉对你的系统的影响。这样就将对B部门系统的依赖降到最低。一定要把整个过程当成两件事情，当整个团队确定要做一件事情，那先要保证你的事情做好了，然后再去看别人的事情做好没有。当然如果需求方在保持沟通过程中发现事情根本不能做，大家都放弃，那是最坏的打算。但不能因为这个理由而拖延项目的开发，以致项目延期。在这种场合就要多做设计，多写点代码，哪怕最后没用上都没关系。我做过的项目，没有中途不变更的，所以还是先考虑设计要紧。
刚才说了不要过分关注对未来的扩展，因为你也不能保证你的设计就能符合未来的场景。但是有一些设计还是可以做的，比如，可以将你认为会影响性能的地方抽象化，先做简单的实现。如果在项目上线后发现确实是这里拖了后腿，改动的化也只要改实现而不用重新架构项目。
那什么时候可以省代码呢？对那样根本不要重用或者很难重用的东西，可以考虑省代码，省设计。比如一个页面要以5种样子显示，老老实实地做5个页面就行了，不用过分地去设计。A页面显示10条数据3个字段，B页面显示.....如果做抽象设计会绕进去，我尝试过很多次，没有做到一个可以让我满意的方案出来。当然你也可以去尝试，我做不出不代表你做不出，呵呵。
一般来说不需要做多种解决方案的也不要过渡地去设计。比如做个日志，你不是要把日志存储到N种设备上就不用考虑设备相关。诚然，做得象log4j那样确实很牛，但common-logging中也提供的简单的实现。一般来说，一个团队形成的积累不用过渡考虑你们根本用不上的场景，那只是增加负担。