软件设计：色彩化的设计

　　在软件的设计过程特别是架构设计和概要设计过程中，我们不难发现不太可能在整个项目中“一刀切”而采用完全一致的设计细节：
　　
　　1：一些设计细节常常需要考虑系统可能的性能、系统潜在的变化包括和外部系统的潜在接口（随着一个客户有多个系统建立起来，在基础数据等方面重复劳动大量出现的情况下更加突出）等，这些变化在设计初期不太可能全面而明确的被识别，这个时候，设计上就存在一些不那么确定的实现，常常体现为更多的接口和代理；
　　
　　2：有时候需要“考虑” 到项目组成员的个性风格，甚至有时候不得不对项目组成员采取的“迁就”方式（如项目巨大压力下又无法有足够人手同时也无法说服成员的时候），这个时候，设计上“可控的灵活性”就体现为提供必要的可选实现，那就意味着在一个设计中存在多条道路来完成同样的工作；
　　
　　3：有时候也会存在本来某条设计实现路径是更好的，但是，碍于项目的实际，你无法期望整个团队都按照这个更好的思路去做，但是，也可能某些团队的成员可以有足够的时间和精力这样子做的，这个时候，完整的和不完整的选择实现都共同存在，而且同在一个设计路线上，只是扮演了不同的角色有不同的优先顺序。
　　
　　在这些时候，在软件设计中采用色彩化的设计就是很好的做法。
　　
　　其实，色彩化的设计，说的简单就是在设计中标示“必需实现”、“关键设计”、“性能设计”、“可选实现”等，使得设计能够有优先级或者更好的关注点。比如，设计人员常常就需要实现或者指导实现“关键设计”、“性能设计”，来保证系统的稳健和性能等，这些实践往往决定了系统的质量根基；“必需实现”表明了无论如何项目成员都必须完成的工作，这是强制性的或者说没有选择的；“可选实现”是满足优秀的团队成员的需要的，她体现了设计人员的最佳期望，但依赖于团队的优秀成员来完成（指在编码速度和软件追求上更高的成员）。
　　
　　采用这种色彩化的设计，效果是明显的特别是对“关键设计”、“性能设计”的识别容易让团队更明晰需要面对的技术点从而更好的实现；“必需实现”则对团队加以必要的约束保证团队尽量的协调，而“可选实现”则指明了系统优化的道路。
　　
　　在实践的过程中，我对“关键设计”、“性能设计”常常采用绿色来标示，对“必须实现”采用红色标示，对“可选实现”采用特定设计方式下的默认色彩，也可能还有更细化的色彩标示，但上述的色彩常常已经确定而不会代表不同的意思。设计方式可能是UML、Word，但这些色彩的应用都不会受到影响。
　　
　　色彩化的设计，简单但是实用，欢迎您也使用她。