2) 可消费性设计、开发
可消费性设计、开发指的是，设计需求的结构、设计和实现方法是否具有可消费性。包括下面几个方面的内容：
架构和设计可消费性
这里指架构和设计方法的逻辑性和合理性，并且是否符合主流的架构模式和设计模式。良好的架构，应该是采用标准、结构清晰、一目了然，并层次分明的。
架构逻辑性、层次性依赖于架构师的功力。但业内有一些非常好的实践和标准，是值得大家去遵循。笔者在此分享一些这方面的经验教训。
经验是：在架构设计上，应尽量采用标准，以及主流的架构设计模式。标准和主流的架构模式一般意味着非常好的实践，而且都有免费或者开源实现，可以复用标准，加快开发速度。比如，企业Web前端的展现层框架可以利用标准的JSF，后端的服务接口使用Web Service等。
教训是：笔者参与的项目重新实现了一些业内已经很成熟的架构和技术，比如界面组件，而没有采用标准定义模型等，造成一些不必要的工作量，而且效果不如采用标准的好。
界面设计可消费性
界面设计和开发是可消费性的重要内容，因为它是和用户进行交互的主要通道。笔者总结了一些常用的非常好的实践，界面设计至少需要符合下面这些点：
·信息清晰原则。尽量少用缩写，除非你的缩写已经众人皆知。比如IBM、PPT这样的词语。但像VC=Verification Code，这样的缩写尽量避免。
·可视性的设计原则。用户界面的操作尽量让人一看就知道如何操作，而不用记忆或查阅文档。比如，界面中隐含操作顺序而不用用户牢记；用星号标记出必选项等。产品界面是否好用，用户第一次使用，或者用户很长时间不使用后重新使用时是否能够很方便的使用，这些都很关键。好的设计无需用户记忆，在设计中隐含着可视性的提示，便于用户完成操作。
·限制性原则。尽量限制在界面上的用户错误操作。一座高楼，如果危险，就应该加上栏杆，界面上也是如此。应该屏蔽用户当时不能输入的输入框等，尽量不让用户操作会引起错误的界面元素。限制错误的操作，指示正确的操作，只给用户一条正确的路，用户就能无需去判断错误，容易的完成操作。
·反馈原则。反馈是控制科学和信息理论中的一个常用概念，其含义为：向用户提供信息，使用户知道其某一操作是否已经完成以及操作产生的结果。举一个例子，我们在打电话时，按键都会产生提示音，并且在液晶显示屏上会提示用户输入的数字，这就是一个典型的应用反馈原则设计的产品。如果用户的每一个电话按键的输入，完全没有反馈，只有到电话拨通后才能知道是否拨错电话，那可想如此的电话系统必不受用户欢迎。在界面设计中，用户输入信息，界面上应该能验证输入信息的正确性，并提供反馈信息给客户。
·分类原则。当界面上的信息多时，这一点尤为重要。把所有信息分类，并把同类的信息显示在一个区域，能方便用户浏览信息。
·差异性原则。用颜色和和字体体现不同的界面元素，如必选项用红色标记，字体用粗体。颜色与心理学、公司或国家常规是相关的，否则会适得其反。
·逻辑性原则。逻辑上两种元素的结构关系，可以通过界面上的视觉结构体现出来。如层次包含结构，在界面上应该用缩进、层级菜单等结构体现出来。
配置可消费性
现在产品越来越多的配置，有基于XML的、基于Property文件的、基于编辑器的。配置带来产品灵活性的同时，也带来了可消费性问题。下面是几点可消费性建议：
一：配置集中化。现在产品配置步骤繁多，大都需要配置多个地方，多个文件，如果其中一个没有配置就会导致所有的配置不起作用。
建议能用一个配置，尽量不用两个配置；能在一个文件，尽量不要分散在多个文件中。
二：配置向导化。配置也好，调整也罢，你需要告诉客户都要做那几步配置，在哪里配置，怎么配置。现在大多数的配置需要在成千上万页的文档中查阅，然后一一对应，有时候配置的顺序还有关系。
建议如果有多步的配置，采用向导的方式，一步一步的指导用户完成正确配置。
三：配置验证性。用户完成了许多的配置，大多产品不给用户足够的反馈结果，提示配置是否出错，出什么错，哪里出错；而需要用户在运行环境按经验去找错，看Log、Trace。结果好不容易找到了，兴许也就是一个很小的大小写错误。用户兴许会想，都是自己不小心，怪自己疏忽。但笔者认为这是设计开发人员的可消费性错误，不注重可消费性的今天，用户帮着承担了。
建议：用户的配置应及时甚至当场就提供给客户反馈信息，提示用户配置的结果，如果配置错误，应提供足够的错误信息，哪里错误，出什么错，有什么解决方法。
开发规范可消费性
开发规范可消费性是在开发的过程中，开发人员编码规范和编码习惯的可消费性。好的编码机构清晰，读起来毫不费力，是一种享受。开发规范可消费性包括：程序代码结构可消费性，代码格式可消费性，注释可消费性，包结构和命名可消费性，类名和方法名可消费性，变量名可消费性等。
·代码结构可消费性在于开发人员不断重构，把代码按照逻辑结构分成不同的包。
·代码格式可消费性一般可以通过编辑器的代码模板和格式器来控制。
·注释可消费性即符合JavaDoc或.Net的注释格式书写注释。
·这里强调一点是命名的可消费性，不管是包命名、类命名还是变量命名，命名时应该采用能够让人看懂的名字。名字长一些往往更好，尽量少用不清晰的缩写，如：People对象，应该用people等能够一目了然的命名，而不是p、pe等简短不清晰的命名。
