aikin / refactoring-kata Goto Github PK

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

代码坏味道，怎么样的才算坏味道？可读性，可扩展性，可维护性.... 然而这个如何量化？

代码坏味道的修改成本，随着时间的增加， 修改成本会越来越高。特别是那种基础设施的代码，牵一发而动全身。

怎么样才算基础设施类型的代码？ 按照生命周期阶段考虑，产品的生命周期，功能的生命周期，数据生命周期，请求的生命周期等。比如说：架构，功能抽象设计，数据库设计等。
对于一个 web 的请求来说，
request -> security -> controller ...-> service ->service ...-> repository->repository ...-> DB

比如：如果修改的是数据库层，修改的辐射面， 就是从下往上。如果修改的是，security，辐射面，就是整个横向面，加上如果是微服务架构，整个 auth 层 都需要修改。

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

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

怎么定义一件事？我觉得就像是问，微服务拆分，多小才算小。我觉得没有标准。但是有一些原则参考：
简单的原则，提取到不能提取为止。当然提取的过程不只是为了 extract method，然后命个函数名字而已，而更应该关注的是抽象。保证函数中的代码处于一个抽象层级，将其它的细节实现就提取出去。

举个栗子：用户注册，同一层次的抽象就是：验证 -> 加密 -> 存储 ，具体怎么验证 、怎么加密、怎么存储的实现细节用其它的函数完成，或者说其它的类完成。不应该在都在注册的函数内。

我理解核心**是为了提高可读性和可维护性。