https://github.com/gdut-yy/A-Philosophy-of-Software-Design-zh
软件设计哲学：
1、这本书指出什么是软件复杂性，如何是识别复杂性， 以及如何解决软件的复杂性；通过模块化设计，信息隐藏，抽象，增加注释等方式降低了软件的复杂性；
最后提到软件设计性能相关，应该先找到可能影响性能的关键点，针对性能是可度量，最后围绕关键路径来做性能优化；
2、本书最终结论是：软件复杂性是存在的， 通过一系列方法只能降低复杂性，并不能完全消除复杂性；
本书学习到的一些设计理念：
1、隔离的复杂性不叫复杂性；如果存在非常复杂的逻辑， 但是这部分逻辑非常合的隐藏在模块中， 外部不感知，这种复杂性是合理的设计；
2、尽量提供较深的模块， 接口层应尽量简单；逻辑内聚；深度模块并不能得到业界统一认可， 个人理解深类有一定好处；可结合业务场景来做设计，不避追求最优；
3、信息的隐藏和泄漏： 信息隐藏是优雅的设计；（case： 订单系统记录出清标记，这个就出现了信息泄漏的风险）
4、类在设计的时候， 应该尽可能内聚；存在一种叫做直通方法（case：比如我们api， 将底层service转为http 典型的直通方法）
5、装饰器模式：考虑使用装饰器模式的场景（延展：装饰器不是万能的， 要充分了解设计模式的使用场景《避免因为知识匮乏 出现”银弹“》 ）
6、如何衡量何时内聚，何时分散：如果遇到一个接口非常复杂， 那这个复杂性是暴露给外部调用者来调用多个接口还是自己封装一个接口外部调用者只调用一个；建议自己封装一个接口，将复杂性在自己内部处理好（case：OCS 关于促销优惠选择逻辑， 这部分应该放在促销，而不是放在ocs）
7、代码应该写注释：应该先写注释，后写代码；注释应该写在模块中心为主， 注释不要重复代码内容， 主要不要有歧义，随着业务发展更新注释（case：促销算价逻辑，如果没有注释可能通过代码无法了解其设计思路）
8、名字的重要性：名字要准确，前后一致（bascase：会员系统， 有的地方是member，有的地方是vip ）
9、代码：团队内部要有代码风格和规范
10、技术选型：相同的事情就用相同的方式， 不同的事情用不同的方式；（延展：识别业务场景，不要拿一套理论或者架构套在不同的业务上， 充分识别是否是相同事情之后， 选择合适的方式）
11、设计性能：性能优化应该先找到可能影响的关键点， 其次是性能优化是可测量的， 然后在关键路径上设计修改。
以下是对本书阅读过程的知识图谱；
网友评论