产品之路的随想[完整图文版].docVIP

产品之路的随想 98年从14.4k的modem拨号上网，看到的是网易，邮箱，蓝波BBS，以及痞子蔡的《第一次亲密接触》，这些让我印象非常深刻。当时没能想到web对我的生活和工作产生了这么大的影响。99年开始接触有哪些信誉好的足球投注网站引擎，有位老鸟的话让我记忆犹新：“要把写在手背上，天天能看见”。2000年开始接触php，mysql，linux，apache，一个企业网站能卖5000元，那个时候是个产生泡沫的时代，对我们来说也是个幸福的时光。 在那个年代里，操作系统是windows98，linux还只是勇敢者的工具，广大程序员还热衷于钻研pb、dephi、vb；Web上的开发感觉上还是玩具；仍旧津津乐道于ms的发家史，回味着ms和broland的激烈竞争，至于google，面孔总是一成不变，但它总能返回你检索需要的东西，仿佛是从遥远的地方传来的天籁之音，一切很神秘。 如果把基于web开发看作一段历史，我和web也逶迤拍拖了10年。如果把Java出生名门的语言叫做大家闺秀，那开源社区推出来的语言就可以称呼为小家碧玉了。大家闺秀和小家碧玉各有风姿，在早期的开发中是各有千秋，一般来说企业应用采取的是java/jsp/ejb等；互联网应用是php/mysql/apache/linux；大家井水不犯河水，各自在自己的领域中用着不同的开发语言。不过随着小家碧玉这几年越发出落得玲珑绰约，大家也争相使用，象spring，hibernate，tomcat都是其中的佼佼者；开发模式也有了极大的改进，从早期model1演变成了随后的model2，再到目前基于框架的快速开发，乃至现在推崇平台开发；工具也从当年的editplus/ ultraedit到后来的jbuilder，直到现在的eclipse一统天下。 图1 model 1模式 图2 model 2模式 仿佛是一夜春风来，千树万树梨花开，在java诞生15年后，我们处在一个前所未有的面临选择的境地：各种各样的软件工具，框架，平台纷至沓来；银弹/非银弹争论不休，开发方法论孰是孰非皆无定论，此时此刻只有windows net气定神闲，整体解决方案，全套开发工具，所见即所得界面，开发就这么容易，可惜我选择的是Java路线，结果在选型，搭配上花不少的时间，也走了不少的弯路。 一路走来，项目之中的苦与乐在内心中酝酿发酵，如何抽象组件，如何提炼成平台，如何包装产品，也渐渐有了一点感悟和体会。作项目苦，作项目累，留给自己的只有满身的疲惫；在上线的倒计时中，程序员们在疲惫不堪的编写代码调试bug，项目经理们殚精竭虑计算如何上线，不同的部门之间相互扯皮推诿。几年下来，项目还是手工作坊方式，自己没有什么长进。疲惫啊疲惫，不在项目中锤炼，就要在项目中颓废。如何跳出项目的怪圈呢？ 国内的软件公司大体可以分为3类：1作项目；2做作平台/产品，有的公司是兼而有之，以项目养产品；3、做运营。项目导向的公司要做好做强做长久，以下几个步骤是不可缺少的，只是不同的阶段深入的程度有所差异：1、业务逻辑组件化；2、基础代码框架化；3、开箱即用平台化 1、组件化： 公司在项目中已经沉淀了这么多年，已经积累了很多可用的业务组件，包括报表展现、ExtJs图形开发，flex页面设计工具，规则引擎，流程引擎等。应用这些组件，在项目实施中减少了开发时间，提高了工作效率。但这些组件分布在不同的部门，大家各用各，甚至还有些敝帚自珍的想法；有的基础组件是你有我有大家有，重复开发。对于这些组件如何甄别和挑选，不浪费本来就很珍贵的人力资源，则在部门之间应该有个通盘考虑。 就算各个组件都汇聚了，如何互联互通，以及在同一个项目内发挥预期作用，这就考验组件的设计方式了。我们的组件基本上都是围绕数据/表来的，涉及一些增删改查以及前端展现，着重要考虑是事务以及组件之间的关联，因为我们的组件是需要被上层更大的组件，或者模块所调用，如果组件对外暴露的是api接口，就不能假设上层应用对组件之间的调用逻辑顺序。 如何设计一个比较通用的组件？有些地方可能需要注意： 事务的调用，组件内部不能发起事务的开始，这个权利交给了用户，用户或在client显示申明，或是在spring内部声明。 组件可能要使用充血模式而不是贫血模式，即在组件内部中维护自身的数据和状态，并同上层的业务系统的数据同时提交或者同步回滚。 组件内部的各个类需要自身来维系，比如工厂模式，多例单例，而不能依靠AOP的能力，否则每集成一个组件，都尾大不掉的带一个spring，彼此之间有影响，项目内部可以使用spring，但在组件级别，类与类的关系得在组件内部考虑。 组件要支持多线程环境，要不给方法加入同步，要不给属性加入threadlocal支持 组件之间如果都有对数据的持久化处理，建议给表加上锁