互联开发模式的经验之谈

互联开发的核心问题

本质：服务，而不是产品

没有明确的需求合同。这导致了没有办法为软件设计固定的开发方案，也难以确定长期目标。

没有预付款和客户验收。互联服务用户来了就用，爽了就给钱，不爽了就走，连沟通的机会都不会有。

甚至连明显的销售环节都没有。很多互联公司只有市场推广部门，而没有所谓“销售”部门，因为推广就几乎等于销售，在推广的同事，就必须把销售的事情一起做了。

对于一项服务来说，需求是持续变化的，你可以找到一些通用的模式，但是必须保持变化。

开发效率是第一重要的，因为市场竞争中，应对需求变化快的单位将获得更多的客户。

小米的MIUI开发节奏

管理：手段.vs.工具

程序员的能力水平。有一些项目其中的技术，是程序员完全没接触过的类型，这里包含了学习、调试的时间。

开发过程中的各种修改变更。由于对可行性、需求确认等方面的因数，开发往往会走“回头路”。有些项目做到一般会发现技术上不可行，需要修改需求；而另外一些项目是在项目做到一半甚至快完成的时候，需求方发现需要修改产品设计，因为在产品可体验之前，完全无法想象到最后会是现在的样子。

各种和开发无关的过程中的事务。这里包括开会、写告、沟通、等待开发电脑编译、处理开发服务器故障、各种开发环境和测试环境的问题处理等等……这些事情往往都看起来不是非常“有技术含量”，但是实际上会严重影响开发进度。因为开发工作需要一个稳定、专心的工作环境，频频的被各种事务打断，会让程序员反复的花费时间去“进入”工作状态————面对成千上万行程序代码，要找到之前写到哪个部分，其实不是那么简单。

资产：代码.vs.流程

敏捷开发的意义和实践

需求变更的原因

架构设计实体化：单元测试

敏捷开发讲究要快速的修改代码，我们往往会发现，代码修改的越频繁，BUG越多，这似乎是一个无法解决的矛盾。然而，在敏捷开发方法论中，有一个重要的措施，就是用来防止这种修改造成的BUG增加的。这就是——单元测试。单元测试本质上，充当着自动的QA人员的角色，如果我们把所有的设计和需求，都先按单元测试的形式“固化”编写下来，那么我们在修改代码后，就能快速的、自动的、反复的去验证我们的代码有没有问题。如果这些测试足够全面和详细，那么我们是不会担心代码修改导致大量的BUG的，因为单元测试会自动帮我们支出问题所在。一旦我们知道了问题，修正起来反而变成是最简单的事情了。

统一软件设计思路的重要性

代码交流：面向对象

代码架构与重构

持续集成的意义和实践

所有资产纳入版本管理

自动化部署

自动化集成测试

DevOps的意义和实践

运维与开发的一体性：运维、运营、QA

可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集

运维需求：这类需求往往表现为非功能性需求，它要求服务器程序能够适应大规模用户访问和持续稳定运行。

运营需求：这里需求通常是功能性需求，因为产品上线后，产品和运营、客服、测试人员，还需要持续不断的使用这个系统，和互联的海量用户进行互动。

运营：客服、活动

因此一般我们在设计互联服务系统的时候，就应该一开始就把运营需求，也作为版本目标纳入开发计划中。一些比较好的团队，会抽象和总结同类互联项目（比如游戏、电商类型）在客服、运营活动上的共性，形成一套标准的服务规范以及实现这个规范的接口。由互联服务开发团队去实现这些规范的接口，提供功能上的支持，而另外一个运营开发小组，则负责根据这个接口，开发供运营团队人员使用的界面、内部管理系统等。比如游戏的运营规范会要求游戏提供查询角色区服、帐的名字、等级等数据，提供接口在游戏中发布任务；电商系统的运营规范会要求店提供本店销售排行查询、优惠券折扣接口等等。

运维：部署(虚拟机)、监控、统计

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

互联 开发模式的经验之谈

互联 开发的核心问题