今天与何老大的一些交流，引发一些心中很久的感想表达一下，主要是针对我们开发过程一些幻想，最后给出实现的规化方式。
1、云开发平台
我们开发人员整天忙忙碌碌，重复最多的就是编写代码->编译->简单测试->改代码->编译...
云开发平台正是为解决这个问题而来，它是什么呢？
所谓云，就是对使用者透明，所谓云开发平台，是指对我们开发人员（测试人员）几乎透明的编译调试环境。
你要做什么？
告诉它你的项目地址，告诉它你的编译方式。
它帮你做什么？
1、监控你的项目，有提交时帮你编译，返回编译结果。
2、准备环境，提供一个云端返回的编译完成的主机（我们的测试机），可以登录ssh进行测试。
2、开发过程自动化测试
我们现在正在测试前移，甚至在需求阶段介入，我这里不关注需求的测试方法，只说测试前移怎么去做？ 我们现在在强调前期的代码审查测试，前期的逻辑检查，这些属于白盒但是静态检视，我以为这些可以去做好，但仅仅对前期测试来说能暴露的问题有限，更多的时候需要靠更多的编码经验。
而开发人员在编码时更多的时间花费在调试（大约80%不为过），这部分工作实际上可以减少很多，而且大家也知道，如果更多的时间用来设计与编写高质量代码，测试的工作量也会更少，能够有效提高整个研发效率，而现在的问题是，开发不知道如何利用工具改进开发过程。
开发过程自动化测试是指，提供一种易用性框架，利用自动化测试优势，将过程的重复工作实施自动化测试，将每次都需要验证的测试点实现自动化验证。
效果是：
开发设计完成，开发编码。
测试前移，准备测试点，编写自动化用例。
利用某一个统一的平台进行交付自动运行。
难点一：对测试人员要求较高，但我们可以培养。
难点二：对开发有一定惯例限制，但每一次的限制用的好可以带来更大的自由（好处）。 像如今满大街的智能机不是对键盘的限制使用吗？
最后一点，也是最宏大的。
3、研发管理平台：
越来越多的流程，越来越繁琐的文档，越来越混乱的IT系统，经常这个账号记不清另一个账号无法登录的。
申请序列号这种小事都需要助理来处理，试想我们如果有一套完善的认证系统不可以自动下发序列号吗？ 系统会记录的更清楚。使用的人也会得到最快速的响应。
开发改了需求没有通知我！！！
忘了xx文档的svn地址了！！！ 找其他人问还十分不好意思，有时候还得不到立刻答复，又影响他人。
SQA累死累活的跑路收集各种信息，但却依然可能受到大家的数据置疑。
一项流程更新，通报了全研发体系却大部分的人在真正执行时仍然遗忘。
。。。
问题已经比较突出了。我们应该怎么做？
研发管理平台，正是我们的需要。
它的核心功能：
1、统一接入认证体系。保证内网安全可靠，并提供完善的日志。
2、集成研发流程，提供从需求到发布的过程跟踪。 可强制限定开发经理与测试经理的活动。 并做到智能提醒。（ 试想，每天我作为开发经理只需要登录一下系统就知道接下来该干什么， 每天只需要一次提交每日进展即可，并可随时查询项目成员的代码提交质量； 而项目责任人无需过多信息，通过研发管理平台即可收集到项目的信息）
例如，需求过程可以简化， 只需要一次录入需求， 以后每次需求变更，所有相关人员自动接受邮件，任何需求过程均被记录，系统发布前提供需求完成情况，自动形成可发布文档。
3、集成自动化测试， 提供统一的静态扫描并与ATM做接口。提供数据仓库可以随机构建有效数据，提供虚拟化硬件平台，任何人在需要的时候一键获取测试主机进行快速接入验证。
4、具备数据分析甚至挖掘能力，提供一定的SQA职责，供决策使用。
我们来初步分析一下，
1、云开发平台
实现难度： 中（监控svn应该不成问题， 提供调试编译环境，这点可通过部门虚拟设备解决，我们自动化已经基本解决虚拟设备实现克隆，开启，关闭，甚至修改ip，执行任何命令的操作，剩下的就是工作量与需求问题， 其他难度在于解决不同环境部署的约束）
实现工作量： 低
实现效果： 能够节省每个开发人员的重复操作并易出错的问题。
限制： 需要开发人员配合实现代码文件存放和命名约束，以及相关需求细化。
2、开发过程自动化测试
实现效果：大规模提高发包与测试回归速度
实现难度：中
实现工作量：中（在于如何设计一个简单易用的框架来快速编写和执行自动化，这里与ATM平台不同的在于它是轻量级，更易于完成非关键字级的验证。并支持更多的语言。）
3、研发管理平台
实现效果最佳。
这个就不分析了，可以通过分步去做。
为什么想到这些？
首先，测试与开发是分不开的。我们测试的目的，保证版本质量，另一个也十分重要的在于提高测试效率。
开发的目的，快速高质量发布新版本，高可维护。细致一想，提高测试效率不简单在于测试过程，而是整个开发过程； 而高开发快速发布一部分依赖于测试的快速测试，除了高可用的架构以外，依赖于快速有效的自动化，依赖于高效率的工具。
不然，开发每次迭代10%开发，测试验证110%的功能局面无法得到任何改变，我们又苦又累却得不到结果。
为什么单元测试在我们项目中实施失败？
1、没有好用的工具， 如果有一个只需要写业务测试代码的单元测试框架被牛人整合出来，何担心没人去用？
2、没有明确的目标，或对目标效果要求太紧。 我们缺乏十分有效的数据度量，缺乏有经验的人，仅仅靠人的自觉基本上很难推行这些项目走向成功。
关于开发语言，
大多数人就像大多数人一样倾向于选择大多数人使用的语言， 而谓之于“最佳实施”...
而如果我说，学一门脚本语言吧，你可能会说， 没听说过图灵等价吗？（ 意指 任何计算机语言的表达能力是等价的，一门语言可以完成的事件，理论说另一门语言肯定可以完成） 脚本语言啊，太弱了吧？ 不能开发大项目吧？
实际上，目前是Lisp类的语言的天下，从perl开始， ， ruby已经不只是开发小型项目了。大家都在使用的时候，知道它是什么写的吗？ 实际上，它的web页到启动脚本均用的。 已经火了N久了，最近的Node。js把它从前端发展到后端。
是什么原因？ 高效的开发效率， 强大的表达能力， 越少的代码往往意味越少的维护成本。有兴趣的同学可以关注下 作者是硅谷的投资之父，揭秘了快速开发的秘密。
我们可以尝试部分内部项目采用它。
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。