基于云的应用程序往往使用户的创意灵感集中在供应商所说的“声明式编程”（declarative programming）上：明确行为的点击式规范，另外还有配置、设置、规则和公式。由于易于使用、含有多租户的工作负载和容易测试，这些都是很好的选择。但如果你的云应用程序用户数量众多，或者用户的使用情况复杂，声明式开发方法给你带来的帮助将很有限：用不了多久，你会满足于用表示层（视图）和业务逻辑（控制器）来编写代码。在一些云环境下，你甚至会直接处理元数据和事务层（模型）。

　　当然，如果你在使用基于云的开放环境或部署环境，那么一开始就要面对模型、视图和控制器模式（MVC）的所有三个层。对于IT专业人士来说，这不是什么新鲜事。

　　但是云开发领域的确带来了一些新的挑战，因为云开发这方面仍然处于早期阶段。比如说：

　　• 没有中心机制：不但用户们是分散的，开发人员也可能位于任何地方，服务分布在好几个位置。对于应用模型、代码、测试数据库或应用程序工件（artifact）来说根本没有中心存储库，除非你用偏爱的版本控制系统和维基创建一个中心存储库。就创建一个吧。

　　• 你要通常同时面对好几种语言：即使面对的只是一个应用程序，你还是要用到大量的跨语言引用。比如说，你的代码可能调用Java库、内部应用函数或脚本。你的用户界面可能调用jquery、JavaScript、JavaScript框架、原生文件系统实用工具、AJAX、Flex及其他语言。这种方法编写出来的代码功能很强、效率很高，但是可能会导致对代码进行排除和调试会非常困难。尽量把所使用的语言总数控制在不超过5种。不妨试一试。

　　• 不同的开发工具会影响代码结构：从代码分析和设计直到代码测试和部署，无不如此：一些工具允许（甚至鼓励）使用极其精巧、扩展性极好的代码结构。其中一些比较花哨的工具只出现在Windows平台上，所以使用Mac和Linux的开发人员对于你编写的系统会有不同的体验，包括开发时间和部署时间。对代码调试来说更是如此；对用户界面来说同样更是如此。

　　云代码评估标准

　　假设云代码可以正常运行，又能满足用户需求，还应该评估代码的哪些方面呢？不妨看一下基本的方面：

　　• 性能：在云应用程序中，性能通常由“屏幕刷新时间”来衡量，因为用户会认为屏幕刷新时间就是“完成时间”。要在典型的用户机器（比如说使用了三年的笔记本电脑）上开展这项评估工作，而不是在配备16GB内存的3 GHz四核高性能机器上进行。两个要素通常决定了明显的性能：云环境的服务器响应请求之前的那段时间，以及屏幕呈现时间。评估云代码时要留意这三个致命要素：不合理的查询、过多的网络繁琐性（尤其是要调用几项Web服务时）以及过头的页面长度或视图状态。

　　• 可部署性：虽然有可能在几秒钟内发布针对某个模块的错误修正版，但是要做的正确事情是在任何部署之前有一个相当全面的测试周期（用于生产系统，Salesforce.com甚至要求全面测试）。不过如果是大型应用程序，部署环节可能包括对元数据、配置表、应用程序工件和测试数据连同代码进行修改。当然，可以使用并发版本系统（CVS）和可编写脚本的编程引擎实现部署自动化。测试的顺序也可以实现自动化。真正的问题在于：这种自动化是不是果真已到位，测试周期是不是在合理的时间内完成？我们最近开发的一个系统最近花了好几个小时才运行完毕强制性的测试周期。这使得应用程序实际运行起来问题重重，我们强烈建议根据这个基准来筛选供应商。

　　• 说明文档的深度和宽度：你可以说我是不切实际的理想主义者，但是云应用程序要有比传统应用程序更详细的说明文档。还要用不同的方式为云应用程序编写说明文档。大家都仍处在不断学习的过程中，所以要确保根据这个基准来评估采购的应用程序和集成商的代码。

　　另外还有一个老大难问题：可维护性。

　　下面这番话听起来不像是出自顾问之口，但是“这完全取决于你的实际情况、你想要实现什么样的目的。”比如说，如果你仅仅使用商业云应用程序，就没必要试图自己来维护。所以，“可维护性”就相当于“SLA”（服务级别协议）。（如果你使用开源云应用程序，可维护性又相当于“外头知道该代码库的顾问有多少？”）

　　但是如果你在自行开发云应用程序，或者用页面、触发器和类来扩展现有的云应用程序，你就需要评估代码，检查代码在分析、扩展和排错等方面的简易性。一种常见的误解是，使用最普通、扩展性最好的代码总是最好的办法。虽然良好的扩展性和避免硬编码是好事，但是倘若这些做法做得过头了，就与代码混淆没有什么两样。要确保评估代码的“可读性指数”，为此请你的员工自己进行一次代码走查（code walkthrough）。要是编程技术太抽象了，很不透明，那你将永远依赖于最初编写这些代码的那家集成商。