Kin Lu

Fix npm scripts.

啃过的书📚

1

* 《实现模式》 * 《编写可读代码的艺术》 * 《编写可维护性 Javascript 代码》 * 《重构*改善既有代码的设计》 * 《代码整洁之道》 * 《修改代码的艺术》 * 《XUnit Test Patterns Refactoring Test Code》

别什么都是 继承

1

滥用继承，那都是因为你懒。

《实现模式》

2


命名规范

1

遗留项目中到处可见的，命名方式不一致 `snake_case`、`spinal-case`、`camelCase` 。

怎么定义一件事？我觉得就像是问，微服务拆分，多小才算小。我觉得没有标准。但是有一些原则参考： 简单的原则，提取到不能提取为止。当然提取的过程不只是为了 extract method，然后命个函数名字而已，而更应该关注的是抽象。保证函数中的代码处于一个抽象层级，将其它的细节实现就提取出去。 举个栗子：用户注册，同一层次的抽象就是：验证 -> 加密 -> 存储 ，具体怎么验证 、怎么加密、怎么存储的实现细节用其它的函数完成，或者说其它的类完成。不应该在都在注册的函数内。 我理解核心思想是为了提高可读性和可维护性。

那些基础设施代码的坏味道

3

代码坏味道，怎么样的才算坏味道？可读性，可扩展性，可维护性.... 然而这个如何量化？ 代码坏味道的修改成本，随着时间的增加， 修改成本会越来越高。特别是那种基础设施的代码，牵一发而动全身。 怎么样才算基础设施类型的代码？ 按照生命周期阶段考虑，产品的生命周期，功能的生命周期，数据生命周期，请求的生命周期等。比如说：架构，功能抽象设计，数据库设计等。 对于一个 web 的请求来说， `request` -> `security` -> `controller` ...-> `service` ->`service` ...-> `repository`->`repository` ...-> `DB` 比如：如果修改的是数据库层，修改的辐射面， 就是从下往上。如果修改的是，`security`，辐射面，就是整个横向面，加上如果是微服务架构，整个 auth 层 都需要修改。

Hi, Paulo May I know what is the drawing tool used for sequence diagrams?