Kin Lu

公司 HR 小姐姐对话 **HR小姐姐**：代码优雅是什么意思？ **小 DEV**：在现实生活中，你怎么理解优雅？（内心戏：优雅？？？ 当时脑袋一蒙，这又是哪位大神造出来的概念。先反问一下。） **HR 小姐姐**：呃呃呃。看起来很舒服，很有气质。 **小 DEV**：我觉得说的没错，看起来舒服，赏心悦目，看起来很简单，但是又很有博学。那么迁移到编程的上下文来说，代码优雅，也就是让读代码的看起来舒服，简单但是又很有料。 **HR 小姐姐**：舒服？那不是很主观吗？ **小 DEV**：好问题。那我们先定义舒服这个词。在编程上下文来说，看起来的舒服的代码，就是保证可读性，可维护性，可扩展性。 **HR 小姐姐**：怎么理解`可读性`、`可维护性`、`可扩展性`? **小 DEV**：举个例子来说，衣柜。小姐姐的你的衣柜应该很多服饰吧，那么你怎么整理呢？有人，就是乱放，没有分类。然后找的时候很难找。如果可以整洁进行分类，优雅的分类。是不是可以很好”维护“呢？ **HR 小姐姐**：乱，那也可以找到啊？那叫乱中有序。 哈哈哈 **小 DEV**：没错。那这个前提条件是，你一个知道，你一个问题维护。软件工程往往不是一个人，讲究的是一个团队协作，那么怎么保证团队中人都能知道你这个 “乱中有序”呢？ 写在最后：优雅是一种对代码的感性表述，它后面有很多理性认知的支撑。代码优雅，是一种艺术的表现。

一开始的抽象层次就不对，比如说，不该在基类的放在了基类里面。

继承滥用，封装滥用。

数据库表的设计，表的抽象

* 模式：用于解决反复发生的设计问题的简单，雅致的解决方案。 * 灵活性，模块性，已经创建可理解的，清晰的设计。 保持代码的价值观：让代码更加体现出，沟通，简单，灵活。 `沟通`：代码可读性高，用代码体现出我们的业务逻辑。 `简单`：简单设计，不要做无畏的抽象，降低逻辑的复杂性。 `灵活`：可扩展性要高。 `软件的成本`: > cost(total) = cost(develop) + cost(maintain) `维护的成本`： > cost(maintain) = cost(understand) + cost(change) + cost(test) + cost(deploy) > `金钱的时间价值和未来的不确定性，由于不确定性的存在，实现策略应该更倾向于带来即时收益而非长远收益。`

`命令式`：阅读代码时，需要跟随着代码的执行流程。阅读者需要在大脑中建立起一个程序状态、控制流、数据流的模型。 `声明式`：更多的是简单的描述。 ***命令式：*** ```java public static junit.framework.Test suite() { Test result = new TestSuite(); ...complicated stuff... return result; } ``` 如果要知道，哪些测试会被执行？就需要知道，suite 的具体实现，需要读懂，理解后，才能知道它的功能。 ***声明式：*** ```java @RunWith(Suite.class) @TestClasses({ SimpleTest.class, ComplicatedTest.class }) class...

《》

类名要简单，易懂。子类名有两重职责，不仅要描述这些类像什么，还要说明它们之间的区别是什么。类名，为了让代码可以更好的和人沟通，而不是计算机沟通。 继承虽然可以减少代码量，会比原封不动地把超类的内容复制粘贴到所有子类精简得多。和所有减少代码量的技巧一样，它会让代码变得更难读懂；`*因为必须理解超类的上下文，然后才能有可能理解子类。*` 每一次的增加间接层，都会增加理解的成本。因为需要了解这层抽象，才能知道如何完成下一个具象。 减少类的数量是对系统的改进，只要剩下的类不因此而变得臃肿就好。

method(obj) -> method1(obj) -> method2(obj) -> method3(obj) ->.... 这样的代码看起来真的很累，因为不知道 obj， 在哪个阶段会被改变。

> 那些被恶心过的命名不规范 * API URL * API Request 和 Response 字段 * 方法名，成员变量，参数，局部变量 * 数据库的表，列 * 消息