弯曲,或折断     

任何一个单独的模块尽量不要依赖其他模块的特性,除了有些特殊情况下会违背这个原则换取一定的效率。     

元数据:用于将代码功能灵活化。将容易改变的、不确定的数据用“元数据”进行配置而不要固定地编织到代码中;可以将某些并非模块固定功能的逻辑(比如客户的个性化需求)通过配置而非代码的方式表示,这样就不用反复为了适应需求而修改代码、重新编译。可以时不时检查加载新的配置以免修改配置便需要重启的麻烦状况。     

时间的解耦:进行流程分析,分析各任务时间上的相互依赖,进行并发编程,可以提高程序的效率。要对全局变量、静态数据的访问与调用进行保护。接口要设计得更整洁,避免接口对调用时间的依赖。     

 黑板:将各个信息放在一个信息流里,各模块与信息流进行交互,从而可以达到统一简便的交互,而不需要在各个模块之间两两规定严密的发布/订阅协议,发布者与订阅者不需要了解对方。  这个设计用于较为复杂,每个模块的行为都会带来新的改变,随时有可能有事件发生并引起其他模块的行为的系统,此时在各个模块之间一一设计接口几乎不可能。  这个设计很优美,但我产生了两个疑惑:这样大的数据量是否会对数据的维护和模块的查找带来负担?是否会出现信息泄漏的风险?对于第一个问题,维护问题我没有想好,但查找可以通过良好地组织数据结构简化;对于第二个问题,可以通过限制权限得到改善,但似乎还是会有风险。

当你编码时:

代码需要演化,它不是静态的事务。 重构  不要试图在重构的同时增加功能。 在开始重构之前,确保你拥有良好的测试。 采用短小,深思熟虑的步骤。 从一开始就可以把可测试性构建进软件中,并且在把各个部分连接在一起之前对每个部分进行彻底的测试。

版权声明:本文为lijiawei1-2-3原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/lijiawei1-2-3/p/11876261.html