一个被微软咨询顾问"认证"的"技术开发平台"设计规范

1. 技术开发平台的编码，最低标准是能够通过VS2008的代码分析工具，而不出现任何提示信息，同时应该完全遵循.NET设计规范。
2. 技术开发平台应该是易于理解、内在一致的，一旦开发者理解了其中一部分，那么就应该能立即理解其他部分。
3. API接口，应该具有可用性，不会产生编程困扰。比如，API接口应该易于实验；又如API应该通过异常来传达对API的误用。可通过这些条件反射式的学习过程迅速入门；等等。
4. API接口，应该层次清晰，容易上手，让低层类型暴露丰富的API并提供强大的功能，而高层类型则用便利的API对底层API进行封装。开发者直接接触到的应该是主要场景API，而高级场景可通过（抽象和重载等）触类旁通的学习方式逐步提高认识和开发技巧。
5. 代码编写应该有良好的注释习惯，要求完整而详尽，开发者可通过VS2008的自动提示功能即可基本了解其使用方法、参数的用途和含义等等，做到望文生义，即日常的编码过程尽可能少的去翻阅说明文档。
6. 必不可少的文档：提供详尽的使用说明书、联机帮助、案例（经典场景）样例代码，等等。
7. 可扩展性：选择既能满足需求又使得开销（业务设计和测试）是最低的机制。即能灵活有没有太多的陷阱，不会因开发者无意的滥用而带来麻烦。
8. API接口，可以多种形式，比如封装成各种层次的API类、可嵌入到类中的Attribute等，以最低的开发开销为准，方便开发者使用。
9. 尽可能封装同类功能的接口，提供一致的编程接口，以便开发者触类旁通，减少学习周期和强度。比如：组件之间的调用方式是透明的：开发者不关心是本地调用还是异地调用（仅关心逻辑分层）、调用时是实际采用什么协议，比如WebService还是remoting、TCP还是HTTP、文本流还是二进制流，等等，甚至未来的通讯协议，仅需扩充本功能即可，提供一致的编程接口。而部署时，仅通过配置即可随意更换通讯方式，而不影响代码编写。
10. 作为引擎类型的功能，主要以事件的形式提供给开发者的编程接口。比如，动态刷新功能，除了提供API接口进行注册外，剩下的就是等着引擎提供各种事件以驱动业务系统产生相应的动作，比如更新界面对象等等。
11. 作为服务类型的功能，应该提供配置工具，方便开发和部署。配置信息如果与业务编码相关的，还应该将配置工具嵌入到VS2008开发工具中，比如：当重构类时，是不是配置中也有相关的信息需要保持一致，这些工作如果交由开发者处理的话，即是简单的重复劳动也很容易出错，都应该交由技术开发平台来自动（或者半自动：一键式处理）完成。
技术平台应该捕获自身缺陷、开发者设计缺陷、开发者编码缺陷、用户业务逻辑缺陷等等造成的运行期异常和故障，为维护者提供统一的界面报警和记录，并为MOM提供接口。