【日志归档】 11月, 2008
另一个层次的耦合度
耦合度有很多的理解，《模块的耦合度》就讲到非常好。文中分别讲了七种耦合情况：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。本文从“产品”的层面来谈谈耦合度（以上经验也是在实施SOA之后，系统变得更加庞大，业务变得更加复杂之后的一些思考）。
第一，技术与业务的耦合，在使用开源产品的发展型公司中，这是普遍存在的一个现象，技术中包含业务，业务中包含技术。出现的结果是：技术只为使用它的业务服务，难以持续发展；技术的重视变为一种口头禅，想单独发展也困难；技术管理变得虚弱，甚至不存在；不断refactor，技术架构与业务架构联动；开发人员的能力要求等同化，不利于培养和发展；遗留问题边缘化、遗弃化。【看参考《闲话通用技术之二 ：苦中作乐》与系列文章】
第二，产品与产品的横向耦合，产品之间的耦合表现为模块接口耦合、数据耦合、业务模型耦合（解决它是具有巨大挑战的。出现的结果是：被耦合度产品，关联度越高，越难以维护，越难以发展；数据上的一丝变化，就导致业务故障；任何被耦合度模型，即使一个小的变化，就需要重新设计其它模型；为了应对多样性的存在，产品提供的相似接口有一打。
解决以上两种耦合度方法是：技术产品化、架构平台化、耦合协议化与规约化、产品体系化。
一页知实力：看Amazon、EBay、Taobao、Youa商品页面
不经常去看看优秀竞争对手的产品绝对是错误的，因为一页而知实力（有点一页知秋的味道）。下面来看看几个页面（注：随机挑选了几个商品）：
看完这些页面，会发现EBay、淘宝、有啊、拍拍长得挺像，这也难怪，大家都是一个商业模式。在此处我重点不是要说这些，重点是通过看每个详细页面来看看各个公司后面的技术实力。
EBay详细页面包括：商品描述、卖家描述、商家推荐、物流介绍、退货政策、支付方式。淘宝详细页面包括：EBay的基本内容、商品评价、销售记录、关联商品推荐。有啊详细页面包括：EBay的基本内容、商品评价、销售记录。拍拍详细页面包括：EBay的基本内容、销售记录。
Amazon详细页面包括：商品描述、关联商品推荐（按客户）、相关商品类目中销售最好的商品推荐、相似商品的分类标签、广告推荐（Customers Viewing This Page May Be Interested in These Sponsored Links）、商品评价、Customer Discussions、Feedback、Where’s My Stuff、Your Recent History 和 Continue shopping: Customers Who Bought Items in Your Recent History Also Bought；对于图书，又有打包促销（Best Value）、客户对该书打的Tags（Tags Customers Associate with This Product）、促销活动等。
从页面反应的内容看：EBay不是很出色；Taobao在学习的同时又增加了评价（引入信用概念），关联商品推荐；有啊完全学习了老的淘宝，反而把他的强项关联搜索没有加入；拍拍也学习了老的淘宝。单独从功能来看（抛开数据量的原因，其实这几家公司都有大数据处理的丰富经验），这几家公司的技术实力差距不是很大。但这几家公司与Amazon相比较，就会发现缺少了很多东西（功能），而缺少的这些东西恰恰是一般技术所不能解决的（对分析、智能的要求更高，Amazon在加强Web2.0的同时，已经悄悄迈向Web3.0），由此可见Amazon实力的深厚。这几家公司，需要加强再加强软实力的建设，在同一业务领域内竞争的同时，看看旁的领域内的领先者。
其实Amazon的这些能力也不是一天之内加入的，而是逐步的增加进来的，直到今天所看到的这些内容。如同武侠中练习内功一般，一年一个脚印。如果把技术比喻为内功，商业比喻为外功，那么最终的胜利者一定是内功高且外功也不差的公司，妄图以外功获取全胜，可能性还是比较小。比较有趣的是Amazon引入的WEB2.0的2个概念：discussion，加强用户交流和体验的功能，把社区与商品结合；引入Tag，加强商品信息是信息的本质特征，同时加强用户参与度。这2门外家功夫还是值得我们学习，也提示我们Web2.0在商务领域同样有市场，一旦这个市场拓展开了，一定也会百花齐放，期待ing …..
由“携程状告‘去哪儿’网侵犯著作权 ”看用户信息所有权
今日在CSDN看到如下新闻《携程状告“去哪儿”网侵犯著作权 索赔1000元》，主题内容是：认为“去哪儿”网站链接自己的用户点评信息侵权。这则看起来很不起眼的一个事件，其实非常有意义，从法律的角度来说，它就是第一个标准案例，具有非常大的参考意义。
这里面透露出来的一个关键问题是“用户点评信息”的所有权问题，只有确定了所有权，才能确定最终谁有权利来确定信息是否允许共享的问题。如果信息归网站所有，那么用户相当于免费替网站生产信息了；如果信息归用户所有，那么网站将不能随意决定信息的外部使用策略，那么会有一大批的网站需要调整自己的产品了；如果信息不隶属于任何一方？就更惊奇了，希望不是这个结局。
我们再来看看业界其它几个事件与该事件的关系：淘宝屏蔽搜索，这儿的关键就是商家信息是属于谁的问题，当业界在争论对错的时候，其实忽略了这一实质问题；因而对于淘宝来说，本案例的判决将会影响到它的信息开放策略。再看FaceBook开放其平台上的客户身份、客户信息，但控制权在用户自己，用户有权决定信息的外部使用策略，它默认信息属于用户。
胡思乱想一下：这个案例的判决，是否会影响到未来互联网技术和信息的走势？这个案例的判决，也会影响虚拟资产的判决（信息也是一种虚拟资产）？
闲扯经验之道
今天与友人（非IT行业）闲谈，讲到自己通过几年的实践，积累了一些经验，其中又讲到了自己的几个体会。我很有感触，因而给他讲了经验获取之道。人获取经验大多如下几个道路：交流、实践、阅读、领悟。
友人平时不喜读书，然善于实践，今日与我聊天，大有一发不可收拾之态，他心中有很多东西希望说出来，与人分享，同时获得一些建议。由此可见他平时缺少沟通，因而他也就缺少了一个获取经验的途径。我身边有时候，也多有此类情况，人们往往因各种原因，而少交流，甚至不交流，从而缺失了一道快速获取经验的渠道。此处的交流不是闲扯、说些无用的官话、废话，而是有意义、有思想的一些东西的碰撞和互通。
当我们频繁使用交流、实践、阅读之道的时候，会快速积累大量的经验。然如何把经验变为一种学识（识：一种判断、辨别的能力）、把经验与意识融为一体？唯有领悟。佛家常讲的“悟性”大体如斯。领悟是种非常自我的东西，很少能够通过其它3种途径获得，只有依靠自己坚强的毅力不断自我冥思和自省，发挥潜意识，逐步构建。曾子曰“吾日三省吾身”，这个过程也是”悟“的过程，今日我们是否也能够做到与曾子一样哪？。
目前已知的除了人类会通过记录传递知识外，生物界普遍是通过实践、交流、领悟来获取经验，再仔细观察，那些能够杰出的动物，除了身体原因外，还非常聪明（聪明指：除了大脑反应快之外，应该还非常有经验，非常有学识）。再考察其成长过程，基础条件都差不多，为啥结果差别那么大哪？”悟“是关键，正是这个主观的作用，形成了个体的巨大差异。
一篇热论日志引起的思考：亮剑精神与创新
“Savio（关明生）给我印象最深的几句话“,这篇帖子引起了大家都热议，也非常有趣。细看下来，其实大家都没有说错，只是自己的屁股所在的位置不同而已。职员、专家、初级管理者、中级管理者、高级管理者、带头者，每个人的利益点都是不同的，考虑问题、说话自然也会非常不同。例如：你让一个客服人员说“今天的最好表现是明天的最低要求”，他一定说不出来，也不会这么想，这不是要把我累死吗（热论中也有人这样的观点）？
看完贴子，我想起了“亮剑”中的一个人事调动，李云龙从被服长到独立团，最后成功“带”出了独立团；关明生在阿里的作用，与老李有点像，他“带”出了一个公司。关帮阿里建立的这种文化，与李云龙毕业论文“亮剑精神”的作用有点像。一个团队没有这种文化作为支撑，怎能可持续的获取胜利。在IT界，看看微软和Yahoo，就是一个明证。
在议论中，最具有争议的话题是“今天的最好表现是明天的最低要求”，关于这句话的理解，我认为“思践”说的很对，摘录如下：
1、高执行力的保障
阿里的各部门中，按说最不具备创造力最枯燥乏味单调的工作就是商机编辑，也就是用户提交的公司和产品资料的审核人员。但是这个部门创造了不少奇迹，从一个人一天能够审核200条信息（不光是审核，大量不规范的提交内容都需要逐一确认并且修改，而非打回让用户自己修改）。最早这个部门一个人一天能够审核200条，但是最后，这个部门创造了一个人一天能够审核编辑2000条的结果。怎么做到的，其中经历了两个过程。第一个过程——把人变成机器人；第二个过程，把人变成智能机器人。第一个过程是有天花板的，但是厉害的是第二个过程，一个编辑要完成机器人到智能机器人的转变，最终他变成了客服+PD+UED+BD+社区运营。在这个部门出现了最大量的产品创新和改进。
2、逼得你创新
除了保证执行力，更重要的是这样的文化下，逼得每个人必须重新，因为按照老路，根本不可能做到“昨天的最好表现是今天的最低要求”，因为KPI的指标也是按照这个原则制定的，只能升，不能降。即使是在销售上，也有大量的创新。所以真正能够长期稳定在阿里工作的人，往往具备了创新的意识和能力（当然也有很多创新也会因为急功近利而留下隐患）。
闲话通用技术之三 ：首次
首次总是会给人流下深刻的记忆。
听一朋友曰：来了一高手，1周才把环境搭建起来，2周才把系统跑起来，3周才摸到了点门路。初次听来，似乎很夸张，不可能吧？我就体验过这种“首次”【至于其中的基本状况，可参考《闲话通用技术之二 ：苦中作乐》一文中的第三阶段】。对于一些新进入编程领域的人来说，这种情况给他带来的挫折是非常巨大的，即使有2-3年经验的人，也很受打击呀，从而出现了某些人很长时间才能融入环境，才能安心开始“正式”的编程事业。
对于一个新进入环境的程序员来说，他要面对技术、业务、管理过程等多方面的再学习，所有的都面临“首次”考验。我一直以来有个梦想：“通用技术能否帮助这些程序员降低首次的恶梦，而不再是梦魇的制造者“ — 这也是一位“高手”义不容辞的责任。
闲话通用技术之二 ：苦中作乐
开源带给许多软件、互联网公司以快乐，可以免费获取到许多资源，可以获取到社区的帮助，可以在某一个开源东西的基础上定制自己的东西（我不把它称为产品，是因为许多定制出来的东西的确不是产品）；开源给程序员带来了快乐，他们可以学到学到新技术，可以学到许多新思想，他们可以通过开源贡献价值。快乐呀！！
韩非子“塞翁失马”的道理总是很快就体验到我们的身边，快乐到一个点，痛苦随着而来；艰苦的熬过痛苦，终于又看到了快乐；然后周而复始；直到那个终点出现（这个终点也是EJB与Spring等的汇合之点。）？看看下面的故事线索：
- 在网站系统创建的1-2年，是快乐的时候，Spring、WebWork等开源框架，很快就搭建了自己的系统，而且运转的那么好。
- 第三年，日用户量达到了百万，服务器也增加到了几十台，业务系统也达到10几个，终于进入了分布式领域，引入了SOA、远程服务、分布式事务、消息等技术。痛苦的开始。
- 第四年，服务器增加到了几百台，开发人员100-200人，解决发布冲突的问题、并行开发的问题等，引入了SCA、OSGI之类的思想和技术；数据量太大了，需要分布存储，引入了分库、统一数据访问、搜索等技术。痛苦在继续。
- 第五年，所有的指标都增加了翻了一倍，似乎一起都混乱了，需要治理，引入了服务治理、服务器监控、更强大的过程管理工具、更多的技术出现了。有人开始乐乐，有人更加痛苦了。
- 第六年………………..
日复一日，重复着这些过程，程序员就是这么可悲。开源并不能解决这个过程中遇到的困境，开源也不是上帝之手;一些开源技术把我们带入了快乐，也给我们埋下了痛苦的隐患。
在这个过程中，我们定义了一系列的规范、标准，就像制定EJB的规范一样来制定企业自己的技术规范；开发了一系列的技术，依然不能解决我们的难题。对玩技术的也许有些讽刺，我们在不断的给业务搞技术架构，却很少给自己的技术搞个架构，把我们的技术平台化，产品化，看看那些成功的互联网、软件公司，无一不会通过这种方式来化解上面的困境。看到技术，永远是点，点多了必然会乱；只有把点组织为有机体（产品），才会健康。“众里寻他千百度。蓦然回首，那人却在，灯火阑珊处”，这诗句写的就是好。
【备注：】朋友写的一篇文章：大型网站架构演变和知识体系，进一步证实了这种情况，即使在第九个阶段，也不是最终阶段呀。
闲话通用技术之一：EJB与Spring会否汇合
晚饭后，与几位同事在办公桌边消食，不知哪位兄弟说起了EJB，结果立刻引起了一片讨论。总体论调无非是EJB已经死亡，以及EJB死亡的原因，以及Spring为啥流行。
在此处我不想对此进行太多探讨，毕竟EJB还在不断进化，使用者也还是有很多；Spring等轻量级框架也在进化，使用者也很多；非Java领域也有很多 东西在不断创新的东西被大量使用。世界本来就是多样性的，关键是个体的选择。在软件领域，架构师对技术平台的选择，可以参考《构建架构的思考》一文的观点 （由三大类要素决定选择架构）。
来看看EJB，Spring的进化：
EJB1.0 –》EJB2.0 –》EJB3.0
Srping –》Spring Application 1.0 –》？？
从大趋势看：EJB标准由复杂走向简单，Spring从框架走向产品。抛开复杂度、个人兴趣等等，只看问题域它们都是一致的：
- 产品化
- 可管理
- 可监控
- 组件化
- 模块化
- 容器
- 事务
- 分布
- 开发者支持（工具等）
- 组装（Ioc特性）
那么它们的终点是否会汇合？
