原文: 如果存在大量说不清业务意图的函数，或者存在大量职责不清的模块和类，就知道他基本上还处在搬砖阶段。
   针对细化到每一行代码的设计和作用，很久之前我就意识到了自己这方面没做好，，很多自己写的代码自己无法知道是否优良，于是各处搜索资料，买课程等，，

 可能是因为水平不够，看到了答案还不知道答案或者是目前所搜索到的知识面不够，还没找到，，，
不过本课程，让我眼前一亮， 到底哪些会变，哪些不太会变，哪些需要如何抽象，用什么样的设计模式更好，这些东西已经看到说明的苗头了，不知老师后面会有这一块更详细说明嘛，

如果没有，还望老师能在这个方面，提点一下理解学习路径呢

关于抽象的理解：
抽象的东西一定是稳定的，比如我说:"一个女孩很漂亮"，漂亮这个词很抽象，每个人都会有对漂亮这个词的定义，所以这句话很稳定，大家很难差生歧义。那这句话如果我换成"这个大眼睛的女孩很漂亮"，这个描述是我对于一个具体的描述（大眼睛），这样的描述会产生歧义（有的人觉得小眼睛的女孩才漂亮）因为这样的描述太具体了。
回到架构思维,必须考虑两点:1. 需求分析(不错需求分析，就不要开始做软件) 2.系统分解(也可以称为各层级的抽象)

关于系统分解:
我们仅仅需要根据需求 ，抽象的划分出不同的子系统,比如电商系统可以划分为: 会员系统、商品系统、订单系统、库存系统等。。这些系统划分期初不一定肯定准确，但是根据需求粗略的划分就好.
再将我们需求中的用例(场景)拆解成不同的小功能点，比如下单流程: 1.验证库存 2.验证会员资质 3.计算价格 4.生成订单。。 根据场景拆分后的静态动作划分到不同的子系统就可以了。
划分后的静态动作在子系统中进一步拆解，拆解为包、类 等。 拆分的过程一定遵循:从抽象慢慢过渡到具体的一个过程