2019-03-29想起有人说过一句话，大意是如果语言支持，就不需要设计模式。换个角度理解，其实讲的就是设计模式背后的设计原则更重要更本质，是道，而设计模式只是设计原则在具体场景下的派生，是术。
张三丰问张无忌：这套拳法你可记得住了？
张无忌答：刚开始记得七七八八，现在已经忘得差不多了。
张三丰听后满意地抚须而笑作者回复: 对，是这个意思。
14
2019-03-29这么些课跟下来，发现课程从多个角度来阐述。但是拆解这件事一直贯穿在其中。仔细一想都是相通的。小了才会更可控，小了才会更能发现问题。因为有了在动手写之前拆解发现了问题才能保证后面写起来更顺畅。作者回复: 嗯，你理解得很到位。
5
2019-03-31我们常说任务到手不要着急去做，要从设计入手，把时间多花在前面。工作中发现大家都是思考了才动手的，那为什么越往后偏差越大呢？共性原因有二：一是全局观不够，用咱们课里的话说就是上下文局限和反馈延迟（看到问题不提，直到代码写到那绕不过去了再沟通）；二是没有领域的概念和有意识地去实践（纸上谈兵），尤其是做流程型任务，都喜欢先把表结构定义出来，再去生成实体，所以从领域层面来看这些实体就很不合适了。结果必然是用面向对象的工具写出了面向过程的代码，既然是面向过程那OO设计原则就鲜有用武之地了。
这两点也是我个人理解要做好软件设计的两个必要条件。作者回复: 很好的补充！
3
2019-03-30我呆过的中小公司的开发，基本上不用什么设计模式，SOLID五个选择挺简单的，但看设计模式感觉比较难，复杂化了……20多个设计模式一定要学吗？感觉上用到的少，是不是需要再学？
另外想问下开发一定要学算法吗？都说算法是程序的灵魂，我看很多开发不不怎么懂算法😓…
也是用到再学？作者回复: 算法、数据结构是基本功，至少要懂得常用的数据结构怎么用，知道算法怎么分析。设计是进阶一点的东西，你不学的话，组织代码的能力就差一些。这些东西都要学，没人会强制你用，但不学，你就缺少了一个思考的维度，就很难上台阶。学习是自己的事，越基础的东西越要学好。
3- 2019-03-29老师，案例中将三个方法放在三个类中职责是单一了，但是如果计算正常的工作时间的方法一样的时候，这样不是又出现重复代码的问题了吗？
作者回复: 这三个类应该自己写自己的，就不应该有共用的代码，甚至不在一个工程里，它们属于不同的限界上下文，后面讲 DDD 会再次提到。
3 
2019-06-18老师，shell脚本的编写是否也可以遵守这个原则呢？我这两天有个案例，就是我在写一个shell 脚本，原本是传两个参数，但是发现有另一种特殊情况是两个参数中的一个是固定的，也就是可以不用传，其他功能都一样。像这样的情况您觉得是写两个单独的脚本比较好，还是在同一个脚本里再写一个switch判断呢？作者回复: 这还是简单的场景，怎么做都好。但有一点，shell脚本也是源代码，需要按照同样的方式进行维护。
1- 2019-04-02有道无术，术尚可求也；有术无道，至于术
关于设计模式，《重构》《设计模式》《重构与模式》这三本书结合看，我自己理解的更深刻了，并且能够很自然的应用。
关于函数长短，我觉得，像人的体温，函数太长，肯定就是发烧了，特别长，会把人烧坏的。作者回复: 这个比喻，赞！
1 - 2019-03-29我以前一直以为软件设计就是用UML画出类图，理清类之间的关系就是设计，现在感觉类图只是对业务的正确理解，设计要体现在代码中，体现在软件架构的整体风格中，不知道我的理解对不对？希望老师指正
作者回复: 设计可以简单理解成组织代码的方式。类图往往只有实体，还有一部分内容是动作，往往通过服务体现出来。在Robert Martin看来，没有什么架构，都是设计。
1 
2019-11-181 人需要负债而行。一开始过度设计，尤其在能力不足，需求全貌不足时，问题严重。
2 solid 尊重原则。道于术，虚与实。基于原则去思考问题，理解问题。
3 作为常年评审同事代码的人， 代码长度，看了下自己的，一般也在15行一下，复杂的30左右。
我觉得大量的只用一次，且分解足够，很便于测试的，30行是可以的。过度拆解10行以下，照样有弊端。属滥用行为。- 2019-09-06用SOLID原则，给你的代码减熵。
2019-05-06还有著名的KISS原则，自己写代码时，一直默念这个原则作者回复: 嗯，Keep It Simple, Stupid.
2019-03-31怪不得之前我一直用不好设计模式呢，心中没有设计原则，会 术 不会 道。作者回复: 现在可以去补上欠缺的部分了。
2019-03-29小而美 最近一直跟随老师的课程反思工作中的问题作者回复: 你理解了！