我理解的互联网应用和企业应用开发

前段时间，我写过一篇[url=http://zwchen.iteye.com/blog/1071866]该主题的博客[/url]，但写完了，我觉得还是没有谈到本质，这篇文章算是续篇。

互联网应用(网站或app)，和企业应用的本质区别，应该从用户谈起。
互联网是陌生用户，网站对于他们来说是自助系统(类似于ATM取款机)，不需要、也不可能对他们强制培训，比如用户注册。所以它们要做得绝对的弱智化，尽量降低学习成本。
企业应用是公司员工，带有强制性，而且上岗前、或系统上线前，一般都有培训，比如工行柜台员工那个Windows客户端的功能，比如存款，都是通过输入“2397”调出的。相对于互联网应用，用户体验并不是优先考虑的。但有一点会很重视，那就是便捷性，如快捷键，因为这些应用一般都是运营系统，员工每天都是重复做那些事情，效率很关键。

特别提示，像淘宝网，前台网站是互联网应用，供买家使用产品、订单模块属于企业应用。
对于一家B2C电子商务公司，往往既有前台的互联网应用，也有后台的业务系统。因为前后台的高度耦合性，如前台订单提交和状态，必须和后台的订单处理流程对应，导致项目很难外包给第三方软件公司，互联网公司一般都有自己的IT开发团队。将软件分包，需要很高的项目管理水平：开发过程解耦+模块解耦。目前，互联网开发外包刚刚起步。

[b]用户行为驱动 vs 业务流程驱动[/b]
互联网是用户行为(意图)驱动，带有随机性，而且不同的用户有不同的浏览习惯。比如我google东西时，一般会先打开上10个页面，然后才一个个看。再比如豆瓣网的书籍详细页：书籍评分、查看类似的书、查看书评、添加书评等，并没有严格的逻辑或流程。同一个书籍界面，书商(作者)、读者、点评者，对该页面的关注点都不一样，就如同企业应用里面的不同用户角色，登录到系统看到的界面不一样。
而且，用户查到该书后，他的浏览顺序、下一步操作都有随机性。很可能因为网站速度慢，他点击了关闭。

这样的系统如何设计？核心原则：研究用户进入该页面的场景，在该场景下用户的需求，以及在此需求下产生的行为。比如购书网站，用户从比价网进来，第一关注点是折扣和促销；如果用户是购买过程中不经意看到一本陌生书，那么他会关注该书的目录和评价；如果用户已经在购物车添加了一本书，那么他会看一下“其他用户还购买了…”。

其实，企业应用也是这样，Use Case里就特别强调了Business Scenarios(业务场景)。
因为企业应用一般是协作式系统，协作式系统涉及到协作流程，也就是工作流，比如订单处理流程、病人应诊流程。当然了，也有很多模块是没有流程的，如交电费(电力CRM)。但它们基本上都可以抽象为表格+表单+流程。

互联网用户的行为习惯是自己练就的，而企业应用的用户习惯，更多是培训出来的。互联网用户行为极不稳定，比如20岁的年轻人浏览网页非常浮躁，到30多岁就沉稳多了；在网页臭长臭长的年代，鼠标滚轮就被派上了用场。而企业应用，界面操作一般是流程驱动，而流程可能上10年都是那样，用户操作相对比较稳定、线性。

[b]界面原型 vs 领域模型[/b]
无论是互联网应用还是企业应用，稍微复杂点，一般都会出架构图，如部署图（可能4+1架构视图有点教条），如根据负载，一台服务器只做批处理(数据同步和发送邮件)，一台服务器只做搜索查询。

比较复杂的业务系统，我们倾向于在需求分析阶段，开发用例图、领域模型图、序列图。当然，我也见过，很简单的业务系统也画一堆图，然后被开发人员扔到垃圾堆里，其实，一个excel功能需求表就可以解决。

对于互联网应用，界面即需求，往往不需要给业务需求建模：领域模型图和序列图等基本上没法用。性能和可伸缩性等非功能需求，可以以功能列表归纳。

[b]软件过程[/b]
因为需求过程的成果物不同，传统的那套软件开发方法：从需求规格说明书到详细设计，即使是RUP等迭代过程，也很难照搬。
互联网进化快，用户需求非常不稳定，它们往往都是在运营过程中改进；系统上线后，偏向于维护而不是迭代开发。估计若干年都不会出现针对互联网领域的业务组件库，但在企业应用领域却很普遍，比如SAP的NetWeaver里针对行业的组件库。

互联网应用，一般均采用敏捷过程。但这种敏捷过程，我们往往搬过来都很教条，如燃尽图和每日站立会议。其实它们解决的就是进度和沟通的，本质上也就是风险控制。这些方法学层面的东西，在《职业经理人》课程里面，都是常识：时间管理、沟通管理、团队管理等等。
敏捷是一种理念，不是一种方法学，虽然最终要落实到方法学。什么叫川菜，什么叫东北菜？一看就知道，但我们需要用辣椒和酱油来衡量吗？

[b]IT人员构成[/b]
做企业应用项目，一般有三种角色：技术、需求、管理。
技术：架构师、高级工程师、工程师、设计师
需求：需求分析师
管理：项目经理PM、技术经理TL
上面我忽视掉了配置管理和测试等角色。

对于互联网项目，角色和上面差不多。
技术：也是架构师、高级工程师、工程师，但设计师普遍比做企业应用的强一个层次。因为他需要处理界面风格、易用性、浏览器兼容性、SEO等。
需求：产品经理+公司业务人员，可能还会配上用户体验专员(交互设计师)。
对于企业应用，偏向于分析性归纳思维(向内)，它只要求你抽象出的软件，能够match当前的业务；而互联网应用，更多是偏向创造性思维(向外)，比如SNS网站的like、poke按钮，极大活跃了用户互动。
管理：项目经理PM，可能由产品经理PD担当，看项目规模了。可能还有技术经理TL，负责技术人员的绩效管理。

两种不同的人员构成，主要体现在需求人员上。互联网需求，是挖掘出来的；企业应用需求，是梳理出来的。企业应用你可以做业务调研，但互联网应用，你调研谁？像中国移动财大气粗，可以花十分钟做一次电话调查，但这往往是选择题，选择就意味着封闭。像苹果iOS中的窗口，并没有关闭、最大化、滚动条，这些创造性功能，是不可能通过用户访谈得到的。

[b]技术架构[/b]
做企业应用的那一套，如Hibernate，我是不建议用在互联网上的。Hibernate解决领域模型的持久化很有效，而互联网应用，偏向于页面而不是领域模型。
另外，互联网应用偏向于读，而不是写操作，这和企业应用是反过来的，Hibernate主要是解决持久化(写)。
Hibernate的性能、级联查询，基本上在互联网上很难有作为。
如果用Java，我倾向于Spring MVC+Spring JDBC，前台做URLRewrite。企业应用那种三层架构、五层架构，在互联网开发上，一定要谨慎。

谈到开发语言，可以选择Java，这和.Net基本上没啥差别，看你的团队精通哪种了。因为它们在团队协作性方面都很强(静态编译型)，有强大的开发工具来规范团队行为，对项目可维护性也很有益。
当然了，如果团队不大，php应该是首选，因为它操作数据库非常简单、高效、灵活。php优势特别是在部署上面，因为互联网应用部署非常频繁，Java一部署就重启app，原来session全部丢失，这绝不是一个小问题。
对于Ruby这类小众语言，太过灵活，团队一大，很容易失控。我没有在项目中实战过，只是曾经研究、学习，不敢妄自发言。

好了，就写到这里。
这篇文章，我还没有谈到产品经理在内容建设方面的职责。像电子商务网站，在内容这块投入的人力成本，如产品图片和文字等，仅次于开发。产品经理在内容建设上，是一个纲领性角色。

这篇文章，只属于启发性，还谈不上总结。估计几年后，会出现比较成熟的互联网开发方法学。

最后

以上就是踏实百合为你收集整理的我理解的互联网应用和企业应用开发的全部内容，希望文章能够帮你解决我理解的互联网应用和企业应用开发所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。