We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
代码坏味道,怎么样的才算坏味道?可读性,可扩展性,可维护性.... 然而这个如何量化?
代码坏味道的修改成本,随着时间的增加, 修改成本会越来越高。特别是那种基础设施的代码,牵一发而动全身。
怎么样才算基础设施类型的代码? 按照生命周期阶段考虑,产品的生命周期,功能的生命周期,数据生命周期,请求的生命周期等。比如说:架构,功能抽象设计,数据库设计等。 对于一个 web 的请求来说, request -> security -> controller ...-> service ->service ...-> repository->repository ...-> DB
request
security
controller
service
repository
DB
比如:如果修改的是数据库层,修改的辐射面, 就是从下往上。如果修改的是,security,辐射面,就是整个横向面,加上如果是微服务架构,整个 auth 层 都需要修改。
The text was updated successfully, but these errors were encountered:
一开始的抽象层次就不对,比如说,不该在基类的放在了基类里面。
Sorry, something went wrong.
继承滥用,封装滥用。
数据库表的设计,表的抽象
No branches or pull requests
代码坏味道,怎么样的才算坏味道?可读性,可扩展性,可维护性.... 然而这个如何量化?
代码坏味道的修改成本,随着时间的增加, 修改成本会越来越高。特别是那种基础设施的代码,牵一发而动全身。
怎么样才算基础设施类型的代码? 按照生命周期阶段考虑,产品的生命周期,功能的生命周期,数据生命周期,请求的生命周期等。比如说:架构,功能抽象设计,数据库设计等。
对于一个 web 的请求来说,
request
->security
->controller
...->service
->service
...->repository
->repository
...->DB
比如:如果修改的是数据库层,修改的辐射面, 就是从下往上。如果修改的是,
security
,辐射面,就是整个横向面,加上如果是微服务架构,整个 auth 层 都需要修改。The text was updated successfully, but these errors were encountered: