软件思考记录

• 考虑实例会创建多个，设计和实现时都要考虑进去。
• 尝试引入消息机制，两个模块间通过消息来通信和控制，反馈，回调。这个可以有效避免紧耦合。尤其是在两个模块不得不紧密合作时。
• 考虑对象间的依赖关系，避免相互环依赖。想法打破依赖环。
• 将代码按功能或目的分组分类，并通过文档等加以约束，尤其是基础功能或能用功能，这样可以避免重复代码。通用功能实现时尽量避免对其它通用功能相互依赖，尤其是不要依赖逻辑功能和代码。
• 配置相关的代码不要依赖于任何业务逻辑部分。它们应该被依赖，被访问和设置。
• 考虑哪些提前申请好资源，同时考虑哪些需要用时再通过加锁的方式即时申请。
• 会有多个线程访问的需要考虑加锁。尽可能减小锁的影响范围。
• 将功能单元模块化，并加以封装和隔离。想想，如何以后想要把某个库替换为加一个库，应该如何在实现的最初就加以准备，来避免以后替换的成本。
• 像上一条一样，实现模块或功能时，考虑单元的功能的完整性，单元要小不要全。每个模块要有可替换性，这个很重要。他保证了单元之间的解耦合。
• 慎用单例模式。
  • 单例过多会在程序释放和再重新生成时造成麻烦，也会影响程序的多个实例的创建
• 考虑对象或资源的释放问题。
  • 实例过散或没有相互关系，也会影响释放。因为需要在释放时逐个找到那些没有约束的独立存在的实例是不现实的，而且由于它们可能属于单独的网，也很难通过其它对象访问到它(像遍历网或树结构一样，属于森林的其它树了)。
  • 单例过多会在程序释放和再重新生成时造成麻烦，是否需要和何时再生成，如何判断？。也会影响程序的多个实例的创建，需要考虑哪些需要多个实例共享，哪些是公属于一个实例的伪单例。需要考虑是否可以统一管理
  • 全局实例类似于单例，也要慎用。比如谁在谁之前申请，谁在谁之后释放，谁依赖谁，都不好处理，尤其是实例个数多了以后。
  • opengl的id再申请，及失效后如果判断失效，如何再申请。最好可以统一管理OPENGL资源ID
  • 经常使用的资源或对象，考虑实现缓存池。但需要考虑判断失效和并发
• 大对象的成员变量之间要考虑相互依赖关系。因此需要考虑声明顺序，因为这个顺序决定了他们的构造顺序和析构顺序。所以也影响了他们之间的相互依赖关系，如果不对可能导致问题。比如如果某个成员A对象内本身有锁，其它成员也可能会访问已被释放的A，可能会错误的进不去锁。
• 如果某个问题(崩溃或死锁)只在某个平台上复现，要考虑跟编译器实现相关的东西。如初始化，构造函数，析构函数，构造或析构完成后的值，及他们的顺序,等等。
• 使用类的静态自定义类成员时或者全局类对象时，需要慎重。需要考虑他们的构造及解析顺序(一个类内，以及不同类中)，或依赖关系。
• 日志系统：在设计和开发中要保留充分的日志打印。出问题时开日志可快速定位，或对不易复现的问题很有帮助。日志最好可分类和分级。如错误信息和调试信息。网络信息和调度信息，等等。
• 接口及回调：在设计初期和开发中，均考虑在一些事件点，保留接口回调的钩子。可用于状态变化时做内部处理，也可以对外提供事件变化的回调接口
• 网络访问时，对返回数据要加magic number检验，不能单纯通过200或res为0等正确就直接解析，某些网络下出问题的。
  
• 有静态库要保证版本和数据格式一致
  
• 设计类接口和实现类的标准：迟早有一天，你会把它整个替换掉的。接口设计时尽量使其独立化，最好能像SQL语句一样调用查询来返回结果。需要异步时可以传入回调
  
• 在实现有状态的类时，要封装set和get方法来访问成员变量，不要直接改成员变量。因为以后很有可能会有监听某子状态成员的回调。
  
• 将一个管理一套资源的大锁替换时多个分别管理多个子资源的小锁