产品之路的随想

《产品之路的随想》由会员分享，可在线阅读，更多相关《产品之路的随想（10页珍藏版）》请在金锄头文库上搜索。

1、产品之路的随想产品之路的随想(社区版社区版)98 年从 14.4k 的 modem 拨号上网，看到的是网易，邮箱，蓝波 BBS，以及痞子蔡的第一次亲密接触，这些让我印象非常深刻。当时没能想到 web 对我的生活和工作产生了这么大的影响。99 年开始接触搜索引擎，有位老鸟的话让我记忆犹新：“要把 写在手背上，天天能看见”。2000 年开始接触 php，mysql，linux，apache，一个企业网站能卖 5000 元，那个时候是个产生泡沫的时代，对我们来说也是个幸福的时光。在那个年代里，操作系统是 windows98，linux 还只是勇敢者的工具，广大程序员还热衷于钻研 pb、dephi、

2、vb；Web 上的开发感觉上还是玩具；仍旧津津乐道于 ms 的发家史，回味着 ms 和 broland 的激烈竞争，至于 google，面孔总是一成不变，但它总能返回你检索需要的东西，仿佛是从遥远的地方传来的天籁之音，一切很神秘。 如果把基于 web 开发看作一段历史，我和 web 也逶迤拍拖了 10 年。如果把 Java 出生名门的语言叫做大家闺秀，那开源社区推出来的语言就可以称呼为小家碧玉了。大家闺秀和小家碧玉各有风姿，在早期的开发中是各有千秋，一般来说企业应用采取的是 java/jsp/ejb 等；互联网应用是 php/mysql/apache/linux；大家井水不犯河水，各自在自己的

3、领域中用着不同的开发语言。不过随着小家碧玉这几年越发出落得玲珑绰约，大家也争相使用，象 spring，hibernate，tomcat 都是其中的佼佼者；开发模式也有了极大的改进，从早期 model1 演变成了随后的 model2，再到目前基于框架的快速开发，乃至现在推崇平台开发；工具也从当年的 editplus/ ultraedit 到后来的 jbuilder，直到现在的 eclipse 一统天下。 图 1 model 1 模式图 2 model 2 模式仿佛是一夜春风来，千树万树梨花开，在 java 诞生 15 年后，我们处在一个前所未有的面临选择的境地：各种各样的软件工具，框架，平台纷至

4、沓来；银弹/非银弹争论不休，开发方法论孰是孰非皆无定论，此时此刻只有 windows net 气定神闲，整体解决方案，全套开发工具，所见即所得界面，开发就这么容易，可惜我选择的是 Java 路线，结果在选型，搭配上花不少的时间，也走了不少的弯路。 一路走来，项目之中的苦与乐在内心中酝酿发酵，如何抽象组件，如何提炼成平台，如何包装产品，也渐渐有了一点感悟和体会。作项目苦，作项目累，留给自己的只有满身的疲惫；在上线的倒计时中，程序员们在疲惫不堪的编写代码调试 bug，项目经理们殚精竭虑计算如何上线，不同的部门之间相互扯皮推诿。几年下来，项目还是手工作坊方式，自己没有什么长进。疲惫啊疲惫，不在项目中

5、锤炼，就要在项目中颓废。如何跳出项目的怪圈呢？ 国内的软件公司大体可以分为 3 类：1 作项目；2 做作平台/产品，有的公司是兼而有之，以项目养产品；3、做运营。项目导向的公司要做好做强做长久，以下几个步骤是不可缺少的，只是不同的阶段深入的程度有所差异： 1、业务逻辑组件化2、基础代码框架化3、开箱即用平台化1、组件化：、组件化： 公司在项目中已经沉淀了这么多年，已经积累了很多可用的业务组件，包括报表展现、ExtJs 图形开发，flex 页面设计工具，规则引擎，流程引擎等。应用这些组件，在项目实施中减少了开发时间，提高了工作效率。但这些组件分布在不同的部门，大家各用各，甚至还有些敝帚自珍的想法

6、；有的基础组件是你有我有大家有，重复开发。对于这些组件如何甄别和挑选，不浪费本来就很珍贵的人力资源，则在部门之间应该有个通盘考虑。 就算各个组件都汇聚了，如何互联互通，以及在同一个项目内发挥预期作用，这就考验组件的设计方式了。我们的组件基本上都是围绕数据/表来的，涉及一些增删改查以及前端展现，着重要考虑是事务以及组件之间的关联，因为我们的组件是需要被上层更大的组件，或者模块所调用，如果组件对外暴露的是 api 接口，就不能假设上层应用对组件之间的调用逻辑顺序。 如何设计一个比较通用的组件？有些地方可能需要注意： 1、事务的调用，组件内部不能发起事务的开始，这个权利交给了用户，用户或在 clie

7、nt 显示申明，或是在 spring 内部声明。2、组件可能要使用充血模式而不是贫血模式，即在组件内部中维护自身的数据和状态，并同上层的业务系统的数据同时提交或者同步回滚。3、组件内部的各个类需要自身来维系，比如工厂模式，多例单例，而不能依靠 AOP 的能力，否则每集成一个组件，都尾大不掉的带一个 spring，彼此之间有影响，项目内部可以使用 spring，但在组件级别，类与类的关系得在组件内部考虑。4、组件要支持多线程环境，要不给方法加入同步，要不给属性加入 threadlocal 支持5、组件之间如果都有对数据的持久化处理，建议给表加上锁的方式。比如加上乐观锁，虽然有时候用户提交后会弹出

8、一个窗口提示重新刷新数据，但总比数据不一致的后果要好。2、框架化：、框架化： 有了这么多的组件，如何把这些组件组装起来，形成有生命力的总体框架呢？组件之间的相互调用如何处理？组件之间的数据交互如何定义？彼此的事务如何传递？ 在开源社区提供了一种不错的搭建项目框架的方法：struts+spring+hibernate。当然也有不少其他的方式，不过总体为前端采取 mvc 模式展现，中间逻辑采取 spring 的 bean 装配方式，以及事务申明，后台采取 hibernate/ ibatis /jdbc 作为持久层，加上其他一些辅助支撑组件，组成了service+dao+orm 的方式，前后台通过

9、POJO 传递数据（现在也与时俱进了，有用 xml 和 json 方式传递数据的）。Serivce 采取的是贫血模式，把组件提供的功能当作 dao 的功能来使用，所以在组件这层面就得考虑组件自身的数据如何与上层业务数据的集成，当只有组件是充血模型方式，才能保证上层业务数据的提交一致性；否则自身组件不维护信息状态，全部持久化到表中，在事务回滚的时刻，就不能保证组件的信息数据也能同步回滚。 图 3 传统项目构架方式对于多人协同软件，比如大型的 OA 系统，BOSS 系统，有很多业务逻辑是需要多人协同的，前后关联的，并还有些条件分支和判断。当然可以在逻辑中使用硬编码的方式，但做成组件，整个框架会更加

10、灵活，多人协同的逻辑抽象出来，演变成了流程引擎；把条件判断抽象出来，演变成了规则引擎。 这样在业务逻辑这块再细分为业务逻辑块和流程逻辑层，整个体系架构演化成：表示逻辑、流程逻辑、业务逻辑、数据管理逻辑四种基本逻辑。表示逻辑还是先前的 MVC 方式；业务逻辑仍然是 service+dao，数据管理逻辑依然由 ORM 负责，或者直接使用 JDBC，流程逻辑则有workkfow engine 来处理。通过这样的分解，使其中任何一层逻辑的修改都不会影响其它三层，与传统的三层结构相比，将流程逻辑从业务逻辑中显示的抽取出来，形成了相互分离的流程逻辑层和业务逻辑层。从而最大限度的降低系统内部的耦合性，提高系

11、统适应变化的能力。这就是所谓的基于工作流的系统架构。 图 4 基于工作流的软件架构再加上一些基础设施，比如日志，异常体系，定时调度，远程调用的通用方法，这个框架的羽翼也逐渐丰满，假以时日就能展翅高飞了。有了组件和框架，其实施的层次还是很低，要编写的代码还是很多，在需求变化的时候，开发人员照样叫苦不迭。而且我们的框架还不灵活，无法应付不同的项目需求。那我们先看看要面对的是哪些项目需求，在摸清对方的要求和套路后，也许就能找到化解的招数。 WEB 应用从目前的角度来区分大体分为互联网应用，企业应用，2 者的涉众和要求有很大的差别。 企业应用企业应用：包括电子商务系统、企业资源规划、客户关系管理、供应

12、链管理，办公自动化，数据库系统，数据仓库等；需要实现用户交互界面，业务逻辑，外部系统的集成，数据库；涵盖到 J2EE 的各个方面，包括 JSP/Servlet/Java/JMS/Transaction/WebService/XML/ESB/EJB 等技术。 可以细分为小企业应用和大中企业应用 1.小企业应用：主要表征是表不多（0100 张表），业务逻辑不复杂，用到的技术也就是页面展现和数据库的方面2.大中型企业应用：主要表征是表多（200 张表以上），业务逻辑复杂，而且涉及到和遗留系统的集成，开发时间长，投入人日多，因为开发费用高，当然也是各软件开发公司的必争项目。 互联网应用互联网应用：包括

13、应用系统：Blog，wiki；网络服务：在线存储，网络磁盘，比较购物； 传统服务：Email,IM，个人主页，新闻信息，门户，论坛，支付网关，商城 ；传统行业：彩票，保险，电子客票，商旅定餐，订票，定杂志，定花；技术上多半采用脚本语言，早期多半用 php，现在也有部分应用是在 rails 上实现。数据库基本采用 mysql，架构在 linux 上，用 apache 服务器。 1.普通互联网应用：比如有 javaeye，itpub，我经常上去逛逛的。它们属于论坛逐渐发展起来的。分别以 java 为主和以数据库为主的社区，分别是用 Rails，php 来设计的。目前都从早期简单的论坛发展成了社区，

14、集成了圈子，博客，招聘等应用，并都有了各自的盈利模式。2.大型互联网应用：典型的有 sina，豆瓣网，采取了很多技术来提高页面访问并发量，比如页面静态化，读写分离，分布式缓存系统。但这种技术在企业应用中用的很少，主要是企业用户更加关心的是数据的正确性和一致性。3.在线运营类型：在线运营只是技术实现方式，还要看上面承载的业务。Google 是老大，什么都有，从搜索引擎到 gmail、google docs，都是在线应用的典型应用。淘宝专注与电子商务和第 3 方支付；A，专营网上书店； 则是最早提出云计算和软件即服务 (SaaS) 的理念（1999 年），国内八百客（800APP-PaaS 平台）

15、，山寨了一把 salesforce，目前在国内也算占据了一个山头。SAAS 盈利的一种模式就是：用户每个月需要支付类似租金的费用来使用网站上的各种服务，按次或者按时间均可。在后续的章节会继续讨论在线应用。现在互联网应用和企业应用有相互渗透的趋势，一些企业把业务系统的一部分搬到互联网上（比如现在淘宝就把电子商务搬到互联网并获得了成功）。 3、平台化、平台化 平台不是框架的简单丰富，给骨架穿上衣服，它也终究是骨骼，没有生命力，只有赋予框架以思想，赋予方法论，框架才有了自己的思想，才有血有肉，有了灵与肉的结合，框架才能跃升为平台，真正指导程序员去开发项目。 根据平时的接触，能称为平台的包括有：上海普

16、元，上海动量，广州天翎，南京联创（无线部的 boss 平台，其他事业部的不清楚）。根据这些平台的定位，大致可以分为 2 类：上海动量和广州天翎面向互联网的；上海普元和南京联创作企业应用的。根据前面对 2 者的应用分析，下面的表格能大致反映其差异性。 企业应用（表企业应用（表 1）：）：1行业领 域区分行业，各自领域业务背景不一样，并形成了一定的门槛。2业务逻 辑业务逻辑复杂，涉及大量的数据和多人协同处理。3数据一 致性强调数据一致性，需要通过事务，交易中间件，数据库锁，java 同 步机制来保证数据的一致性。4数据复 杂度数据复杂，有大量的表，表之间有复杂的牵涉关系，在某些行业维 护这些表之间的关系和数据就需要一个团队。5并发量不是特别大，比如通用应用为 100200 并发，重度并发 500 的系统 就能满足国内大部分的系统要求。6系统集 成关键系统需要和很多外部系统集成，集成的方式可能采取 esb，jms，web service，socket。7用户交 互强调界面交互和数据表达