产品之路的随想Word文档下载推荐.docx
《产品之路的随想Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《产品之路的随想Word文档下载推荐.docx（14页珍藏版）》请在冰豆网上搜索。
作项目苦，作项目累，留给自己的只有满身的疲惫；
在上线的倒计时中，程序员们在疲惫不堪的编写代码调试bug，项目经理们殚精竭虑计算如何上线，不同的部门之间相互扯皮推诿。
几年下来，项目还是手工作坊方式，自己没有什么长进。
疲惫啊疲惫，不在项目中锤炼，就要在项目中颓废。
如何跳出项目的怪圈呢？
国内的软件公司大体可以分为3类：
1作项目；
2做作平台/产品，有的公司是兼而有之，以项目养产品；
3、做运营。
项目导向的公司要做好做强做长久，以下几个步骤是不可缺少的，只是不同的阶段深入的程度有所差异：
∙1、业务逻辑组件化
∙2、基础代码框架化
∙3、开箱即用平台化
1、组件化：
公司在项目中已经沉淀了这么多年，已经积累了很多可用的业务组件，包括报表展现、ExtJs图形开发，flex页面设计工具，规则引擎，流程引擎等。
应用这些组件，在项目实施中减少了开发时间，提高了工作效率。
但这些组件分布在不同的部门，大家各用各，甚至还有些敝帚自珍的想法；
有的基础组件是你有我有大家有，重复开发。
对于这些组件如何甄别和挑选，不浪费本来就很珍贵的人力资源，则在部门之间应该有个通盘考虑。
就算各个组件都汇聚了，如何互联互通，以及在同一个项目内发挥预期作用，这就考验组件的设计方式了。
我们的组件基本上都是围绕数据/表来的，涉及一些增删改查以及前端展现，着重要考虑是事务以及组件之间的关联，因为我们的组件是需要被上层更大的组件，或者模块所调用，如果组件对外暴露的是api接口，就不能假设上层应用对组件之间的调用逻辑顺序。
如何设计一个比较通用的组件？
有些地方可能需要注意：
∙1、事务的调用，组件内部不能发起事务的开始，这个权利交给了用户，用户或在client显示申明，或是在spring内部声明。
∙2、组件可能要使用充血模式而不是贫血模式，即在组件内部中维护自身的数据和状态，并同上层的业务系统的数据同时提交或者同步回滚。
∙3、组件内部的各个类需要自身来维系，比如工厂模式，多例单例，而不能依靠AOP的能力，否则每集成一个组件，都尾大不掉的带一个spring，彼此之间有影响，项目内部可以使用spring，但在组件级别，类与类的关系得在组件内部考虑。
∙4、组件要支持多线程环境，要不给方法加入同步，要不给属性加入threadlocal支持
∙5、组件之间如果都有对数据的持久化处理，建议给表加上锁的方式。
比如加上乐观锁，虽然有时候用户提交后会弹出一个窗口提示重新刷新数据，但总比数据不一致的后果要好。
2、框架化：
有了这么多的组件，如何把这些组件组装起来，形成有生命力的总体框架呢？
组件之间的相互调用如何处理？
组件之间的数据交互如何定义？
彼此的事务如何传递？
在开源社区提供了一种不错的搭建项目框架的方法：
struts+spring+hibernate。
当然也有不少其他的方式，不过总体为前端采取mvc模式展现，中间逻辑采取spring的bean装配方式，以及事务申明，后台采取hibernate/ibatis/jdbc作为持久层，加上其他一些辅助支撑组件，组成了service+dao+orm的方式，前后台通过POJO传递数据（现在也与时俱进了，有用xml和json方式传递数据的）。
Serivce采取的是贫血模式，把组件提供的功能当作dao的功能来使用，所以在组件这层面就得考虑组件自身的数据如何与上层业务数据的集成，当只有组件是充血模型方式，才能保证上层业务数据的提交一致性；
否则自身组件不维护信息状态，全部持久化到表中，在事务回滚的时刻，就不能保证组件的信息数据也能同步回滚。
图3传统项目构架方式
对于多人协同软件，比如大型的OA系统，BOSS系统，有很多业务逻辑是需要多人协同的，前后关联的，并还有些条件分支和判断。
当然可以在逻辑中使用硬编码的方式，但做成组件，整个框架会更加灵活，多人协同的逻辑抽象出来，演变成了流程引擎；
把条件判断抽象出来，演变成了规则引擎。
这样在业务逻辑这块再细分为业务逻辑块和流程逻辑层，整个体系架构演化成：
表示逻辑、流程逻辑、业务逻辑、数据管理逻辑四种基本逻辑。
表示逻辑还是先前的MVC方式；
业务逻辑仍然是service+dao，数据管理逻辑依然由ORM负责，或者直接使用JDBC，流程逻辑则有workkfowengine来处理。
通过这样的分解，使其中任何一层逻辑的修改都不会影响其它三层，与传统的三层结构相比，将流程逻辑从业务逻辑中显示的抽取出来，形成了相互分离的流程逻辑层和业务逻辑层。
从而最大限度的降低系统内部的耦合性，提高系统适应变化的能力。
这就是所谓的基于工作流的系统架构。
图4基于工作流的软件架构
再加上一些基础设施，比如日志，异常体系，定时调度，远程调用的通用方法，这个框架的羽翼也逐渐丰满，假以时日就能展翅高飞了。
有了组件和框架，其实施的层次还是很低，要编写的代码还是很多，在需求变化的时候，开发人员照样叫苦不迭。
而且我们的框架还不灵活，无法应付不同的项目需求。
那我们先看看要面对的是哪些项目需求，在摸清对方的要求和套路后，也许就能找到化解的招数。
WEB应用从目前的角度来区分大体分为互联网应用，企业应用，2者的涉众和要求有很大的差别。
企业应用：
包括电子商务系统、企业资源规划、客户关系管理、供应链管理，办公自动化，数据库系统，数据仓库等；
需要实现用户交互界面，业务逻辑，外部系统的集成，数据库；
涵盖到J2EE的各个方面，包括JSP/Servlet/Java/JMS/Transaction/WebService/XML/ESB/EJB等技术。
可以细分为小企业应用和大中企业应用
∙1.小企业应用：
主要表征是表不多（0~100张表），业务逻辑不复杂，用到的技术也就是页面展现和数据库的方面
∙2.大中型企业应用：
主要表征是表多（200张表以上），业务逻辑复杂，而且涉及到和遗留系统的集成，开发时间长，投入人日多，因为开发费用高，当然也是各软件开发公司的必争项目。
互联网应用：
包括应用系统：
Blog，wiki；
网络服务：
在线存储，网络磁盘，比较购物；
传统服务：
Email,IM，个人主页，新闻信息，门户，论坛，支付网关，商城
；
传统行业：
彩票，保险，电子客票，商旅定餐，订票，定杂志，定花；
技术上多半采用脚本语言，早期多半用php，现在也有部分应用是在rails上实现。
数据库基本采用mysql，架构在linux上，用apache服务器。
∙1.普通互联网应用：
比如有javaeye，itpub，我经常上去逛逛的。
它们属于论坛逐渐发展起来的。
分别以java为主和以数据库为主的社区，分别是用Rails，php来设计的。
目前都从早期简单的论坛发展成了社区，集成了圈子，博客，招聘等应用，并都有了各自的盈利模式。
∙2.大型互联网应用：
典型的有sina，豆瓣网，采取了很多技术来提高页面访问并发量，比如页面静态化，读写分离，分布式缓存系统。
但这种技术在企业应用中用的很少，主要是企业用户更加关心的是数据的正确性和一致性。
∙3.在线运营类型：
在线运营只是技术实现方式，还要看上面承载的业务。
Google是老大，什么都有，从搜索引擎到gmail、googledocs，都是在线应用的典型应用。
淘宝专注与电子商务和第3方支付；
A，专营网上书店；
则是最早提出云计算和软件即服务（SaaS）的理念（1999年），国内八百客（800APP-PaaS平台），山寨了一把salesforce，目前在国内也算占据了一个山头。
SAAS盈利的一种模式就是：
用户每个月需要支付类似租金的费用来使用网站上的各种服务，按次或者按时间均可。
在后续的章节会继续讨论在线应用。
现在互联网应用和企业应用有相互渗透的趋势，一些企业把业务系统的一部分搬到互联网上（比如现在淘宝就把电子商务搬到互联网并获得了成功）。
3、平台化
平台不是框架的简单丰富，给骨架穿上衣服，它也终究是骨骼，没有生命力，只有赋予框架以思想，赋予方法论，框架才有了自己的思想，才有血有肉，有了灵与肉的结合，框架才能跃升为平台，真正指导程序员去开发项目。
根据平时的接触，能称为平台的包括有：
上海普元，上海动量，广州天翎，南京联创（无线部的boss平台，其他事业部的不清楚）。
根据这些平台的定位，大致可以分为2类：
上海动量和广州天翎面向互联网的；
上海普元和南京联创作企业应用的。
根据前面对2者的应用分析，下面的表格能大致反映其差异性。
企业应用（表1）：
1
行业领域
区分行业，各自领域业务背景不一样，并形成了一定的门槛。
2
业务逻辑
业务逻辑复杂，涉及大量的数据和多人协同处理。
3
数据一致性
强调数据一致性，需要通过事务，交易中间件，数据库锁，java同步机制来保证数据的一致性。
4
数据复杂度
数据复杂，有大量的表，表之间有复杂的牵涉关系，在某些行业维护这些表之间的关系和数据就需要一个团队。
5
并发量
不是特别大，比如通用应用为100~200并发，重度并发500的系统就能满足国内大部分的系统要求。
6
系统集成
关键系统需要和很多外部系统集成，集成的方式可能采取esb，jms，webservice，socket。
7
用户交互
强调界面交互和数据表达，需要支持多种数据展现方式，需要众多数据在页面上的展现，传输
8
开发过程
强调软件过程，讲究行业经验，需要撰写大量的文档和多人的协同，需要版本控制和问题跟踪回溯。
互联网应用（表2）：
跨行业，按应用类型区分，比如blog，wiki，个人门店等。
业务逻辑简单，大部分是通过页面进行数据的增删改查。
要求有事务，但和高并发博弈中，让位给高并发。
数据不复杂，表之间的关联不多
强调高并发，支持用户数量多，强调高速读低速写。
弱。
极少需要和其他系统集成
交互不多，表现方式简单，更多的是数据的增删改查。
强调敏捷，快速开发，基本不需要版本控制。
总体来说软件开发的方法论有2种
敏捷方式：
针对互联网应用，强调快速开发，简略一些中间过程，推崇界面（界面原型）即需求。
提供界面生成工具，通过代码自动生成工具生成部分逻辑，并提供一些管理工具和管理途径。
在项目中使用到了动量（ODE），也接触了天翎（teamlink，myApps），感受了到互联网应用对传统开发模式的冲击，对传统开发模式有了触动。
动量和天翎都强调界面即需求，简化了传统软件工程中的概要设计和详细设计，并通过一部分的代码自动生成简化了编码工作，但2者的实现方式有所不同。
∙动量平台提供了基于web的在线编辑页面的方式，并把界面元素生成表结构，因为在动量内部有专门的表来维护用户设计的表结构和关系，所以我们在PD设计的表结构是不能直接导入动量平台，只能通过ODE的界面来生成，并生成标准的增删改查代码，如果有自己特定的逻辑，则需要在ODE中的规则进行扩展，编写一些java代码片断，并提供了一些后台组件和方法和数据库进行交互，部署后由ODE进行编译生成java类代码。
因为生成的代码是普通的java代码，并和前台页面有直接的调用关系，所以不支持后台逻辑的分布式部署，在大并发量的情况下只能通过借助应用服务器的集群能力。
动量平台架构在很多开源的工具包上，并提供一些企业应用的关键能力，包括事务，包括流程引擎，定时调度，报表展现等，开发人员只要关注界面原型和业务逻辑，提高了生产力。
∙天翎同样提供了界面设计的工具，而且他的扩展是通过所谓宏语言（从技术调度分析可能是设计了一些JS的Lib库），在界面设计方面支持拖拽等更灵活方式，表单设计是天翎平台的强项，并提供了基于手机的任务处理途径。
通过天翎平台创建表单，最终是生成的jsp，所以不存在ODE有个打包编译部署的过程，发布后刷新既可用，通过这种方式生成的页面，大部分的逻辑写在页面中，同样不能做到后台逻辑分布式部署，也只能通过应用服务器的集群能力来实现大并发的访问。
在大项目不容易接，小项目利润薄的情况下，通过敏捷平台能快速开发一批类似的项目，在广种薄收的季节里，也能聚沙成塔，集腋成裘。
另外还有一种方式就是把各种小企业应用抽象出来搭建在云应用（在线支撑运营）上，通过某种租赁方式与众多小企业用户达成使用协议，也就是Saas的理念，在后面的章节会详细讨论。
重型方法：
针对企业应用，以CMM/CMMI为代表，强调过程受控和里程碑，并通过很多文档和流程来支持。
典型的如RUP，4大阶段，9条流程，以及大量的文档模板和在里程碑需要出具的物件，通过这些保证软件过程的可靠有序的执行。
联创移动事业部的开发方式代表了这种模式，提倡了表驱动的设计理念和前后端分离的开发体系，前端是使用tapestry实现的web展现，中间层应用逻辑搭建在tuxedo服务器之上，并能多台部署，后端是Oracle。
Web只能通过调用中间层的服务访问数据，不能直接访问数据库，这样有几个特点：
∙1.中间服务器层可均衡访问，并通过tuxedo把并发访问削峰填谷，提高系统的健壮性。
∙2.前端开发和后端开发分离，开发速度快，行业经验能有效固化。
在特定的行业应用中，后台服务大体是稳定的，变化的只是前端展现，通过后端服务的编排/编制（提供了可视化工具），能快速提供前端展现所需要的服务，前端人员不需要了解后端逻辑，只需要知道是哪个Api，仅此而已。
如果不是这种开发模式，每个省的boss系统不可能在3～6个月内实现（最近2年上的是ngboss，整个后台都发生了变化，云南boss作为试点，前后用了将近1年）
∙3.数据的安全，所有的数据访问，被限定在有限的通道中，非后台人员无法知道后端表结构和数据。
另外一个平台是EOS。
普元eos从5.0我认为才开始成熟，6.0之后已经更上了一层楼，而且在6.0加入了SCA的体系架构，号称是银弹工具。
抛开华丽的包装不说，以程序员的眼光来看，eos提供了一个开发框架和管理平台：
开发平台包括了一个web框架，一个流程引擎，并通过可视化工具（涵盖web开发，流程建模，数据库表设计），包括了表设计，详细设计，编码，测试，上线运营，监控管理等软件过程等一系列关键活动，在国内算得上比较成熟的软件平台工具。
EOS也是表驱动的设计理念，但界面和业务逻辑没有分离（一般来说，基于SCA能支持后台逻辑的分离部署，但在公司的手机支付平台项目中，没有体现这个特性）。
从软件开发的角度来说，使用了EOS，多了一套IDE和流程引擎以及类似struts的web开发工具，还有一些底层的工具包。
当年eos6.0端着通用平台的架子来到联创移动事业部，打算能替换就有系统，但据说没有成功。
Eos的web如果调用后端的tuxedo服务，自身就退化成了一个web开发工具；
eos工作流引擎是本身在管理数据库的流程状态，并和页面的构件有着千丝万缕的调用关系，要符合联创现有的体系，除非重构。
就像2位都有思想的人，结合在一起就是有些别扭，要不就要联创移动事业部迁就eos，要不就是eos重构。
（eos在联创的其他事业部有应用，比如联通）。
另外有个例子，amdocschina（朗新），承接湖北电信boss时候，当时没有现有的平台，采用的框架是struts1＋spring1.＋hibernate2/jdbc，工作流引擎是用存储过程写的，从05年到07年，人最多的时候达到了200多人，开发和上线时间比较长。
根据对企业应用和互联网应用的特点进行分析，以及在理解和把握国内业界先进的平台思想体系，我们开发部也提出了自有的业务基础平台，业务基础平台包括业务开发工具和软件开发框架，其中业务开发平台提供了流程建模器，FlexUI的界面设计器，以及将来提供的规则设计器；
软件开发框架分为5层，自下而上分别是数据访问层，基础业务层，领域业务层，编程接口层，界面交互层。
图5业务基础平台总体框架
开发方法论和联创的大体类似，并借鉴了动量的Web界面快速生成的思想以及管理模块的概念，提出了我们特有的方法论。
开发团队分为前后端，前端web开发人员调用后端服务设计人员编写的开放业务编程接口（OBPI）；
在需要多台后台逻辑服务器的情况下，采取通用远程调用接口（URCI）的方式部署。
前端界面采取FlexUI快速设计界面；
后端逻辑采取表驱动方式设计，并依托工具生成基本的增删改查代码，前端展现和后台通过接口（OBPI）的方式进行绑定，这种方式即有利于行业软件的自身积累，也能在互联网应用中快速开发。
该部分内容在《xx业务基础平台可行性研究报告》中有详细说明，这里不详细阐述。
图6基于软件开发框架的开发步骤
由此可见，要在国内的软件行业站稳脚跟，要有自己所占据的行业领域，以及对行业领域的独有了解。
正如鲁迅所倡导，不但要拿来，还要改造，打造出符合公司需要、公司理念的平台。
自此才深刻了解为什么这几年在不断的引进上海普元，上海动量，广州天翎，以及到上海博科去学习。
师夷长技以制夷，通过走出去，请进来的方式，学习业界先进的思想和理念，并加以山寨、改进、超越，符合公司独有文化，特定领域的需求，才能立于不败之地，否则我们就只能在项目的泥泞中挣扎彷徨。
与其在项目泥潭中怨天尤人、放逐自我还是奋发雄起、积极进取，在学习借鉴把握业界先进平台的同时打造自有的公司级的平台，则是我们程序员对待软件的一种态度和追求。
4、云应用
互联网应用和企业应用虽然都属于web应用，但面向的涉众不一致导致设计思想和开发模式有很大的区别。
就像我们在描述大自然的现象，宏观层面使用广义相对论，但在微观层面使用哥本哈根的量子学说。
本来是井水不犯河水，大家都相安无事，但如果要解释宇宙起源的那一刻，是用相对论还是用量子学说？
当企业应用发布到互联网，为广大的普通涉众提供服务，我们是采用什么方法论呢？
再往前推进一步，如果推广公司的大规模的在线应用，我们打算如何构造呢？
我们的组件，我们的框架，我们的平台能承担这个重担吗？
需要在线运营平台吗
其实在线运营平台的应用和我们息息相关：
google，能在浩如烟海的资料中能快速定位我需要的内容；
QQ，能让我找到老婆；
淘宝，能买到物美价廉的物品；
上amazon买几本原装进口的书；
上code下载开源的软件。
。
我们的工作和生活已经离不开这些平台应用，国内一些类似的在线运营公司，比如XX，腾讯，淘宝，都在各自的领域中称霸一方。
腾讯QQ在前不久已经超过了1亿的在线用户数，这是十分惊人的数量，这么大的用户数保证了腾讯山寨后就能把对手远远的抛在后面。
比如QQ农场，1个月有5千万的进账。
在线运营平台能带来变化
如果观察这些在线应用，愿意支付费用的大概有3种类型的人，商家，玩家，买家。
企业用户愿意购买竞价排序的关键字；
玩家愿意买狗粮买化肥；
买家愿意通过支付宝购买物品。
有了众多网友的鼎力支持，这些企业也赚的盆满钵满。
潮涨潮落，花开花谢，Borland消失了；
sun/weblogic投靠了oracle；
novell不做netware，转而支撑linux了；
IBM不纯卖软件了，推崇服务了；
微软不单单只卖office，windows了，也开始推bing，Azure等在线应用了；
google的界面还是一如既往的这样清纯淡雅。
纷纷扰扰，当年辉煌的产品成了明日黄花，传奇的故事已经烟消云散，但能从中把握一个这样的讯息，辉煌了一时，不会长久一世，只有贴近广大用户的需要，即用户所想，提供用户所需，才能永葆青春。
如何贴近用户？
如何把应用推送到用户手上？
通过互联网，把应用搭建在互联网上。
“衣不如新，人不如故”，人总是有惰性的，用户使用习惯后自然就产生一种黏性效应，比如我从来只上google不上baidu；
只在QQ农场偷菜，从不去开心农场。
当然了，我从不购买狗粮，QQ农场中的5千万的收入收入中没有我的贡献。
如何设计在线运营平台
微软认为，未来的互联网世界将会是“云+端”的组合，在这个以“云”为中心的世界里，用户可以便捷地使用各种终端设备访问云中的数
升级会员 