我相信，有很多程序员和我一样，并不是软件相关专业科班出身的。 对于我们这些非科班出身的程序员来讲，很多时候，都是在摸着石头过河。因为没有系统性和体系化的知识结构基础，在做程序设计和程序开发的时候，都只能凭经验或直觉来做。 经验丰富之后，可能写出的代码也比较漂亮；但是在带新人的时候，却不能够讲解清楚什么是好代码，怎么避免掉入烂代码的坑里，结果导致自己的“弟子”们，要么无法理解自己所讲授的内容，要么，就学的似是而非，画虎类犬。耽误了别人的前程，同时，也阻碍了自己的进步 回头来学习这些，是为了“补课”，把自己的经验理论化，将这些理论知识和自己的实践相互印证，建立坚实的知识结构体系。在这样的体系基础之上，也更易于向别人传播自己的知识和经验，只有基础牢固，才能建成真正屹立不倒的摩天大楼

Notification和MsgSender的场景很形象，不过还是不过瘾。如能基于这个场景， 先IfElse地爆炸实现、实际工作中评估不全、造成线上事故等问题， 再引申出设计大神的桥接模式救场，再复盘地研究下， 桥接模式究竟是哪些天赋异禀造就了神奇的解耦效果， 就更好了。 不过， 这些内容， 可以留在升级课程中提供一对一的工作坊式教学。 感谢老师

"设计原则和思想比设计模式更加普适和重要"，被这句话一下子点醒了。

咨询一个问题，是在dev分支还是feature分支做，如过在开发分支做，是不是因为每天提交的过于频繁，并且缺乏逻辑整体性，导致cr效果不理想。

1.对个人。一方面提升代码美感，另一方面提升对源码等的理解。 2.对团队。代码可读性，bug率等会降低。

作为一个只会js的小前端看这个有些吃力了

dynamicArray的例子实际上说的是一个“向上转型”的问题

我觉得5点各有侧重，设计模式多种多样，能谈到这四个字的程序员，一定是很有经验的，它本身也是前人经过长时间的实践，总结出来的代码编写经验，最后形成了一套可借鉴的固定模式，对想提升代码编写技术的人很有帮助。

如果是单枪匹马写一个程序，那可读性也就不那么重要，反正都是自己在看，如果是团队做项目，共享代码，共同提交，那么，可读性很重要，至少要让你的团队成员看地懂，理解。

多态是一种语法，lsp 是一种设计原则。lsp依赖多态的语法机制，但lsp从功能，输入，输出，异常等方面的约定，对子类提出了跟进一步的要求。