- 开发人员热衷于技术并通过技术手段解决问题，而不是深入思考与设计，这会导致他们孜孜不倦地追逐技术上的新潮流；
- 过于重视数据库、数据流。大多数解决方案的讨论都是围绕数据流、数据库、数据模型来开展的，而不是聚焦业务流程和运作方式；
- 开发人员没有足够重视根据业务目标命名的对象和操作，这导致他们交付的软件和业务模型之间有较大的分歧；
- 业务干系人常常浪费大量时间闭门造车，以实现各种无人问津的需求，或者只有一小部分能开版本吸收；
- 开发人员使用“任务看板”，而非考虑周祥的设计导致他们造出了一个个“大泥球”；
- 在用户界面的持久层组件中构建业务逻辑或在业务逻辑中执行持久化操作；
- 数据库查询会时常出现中断、延迟、死锁等问题，阻碍用户执行时间敏感型的业务操作；
- 项目中存在错误的抽象级别，开发人员试图借助过度概括的方案瞒足所有当下以及臆想出来的未来需求，而不是解决实际而又具体的业务诉求；
- 存在紧耦合服务群，当一个服务执行操作时，该服务直接调用另一个服务并引发一个对待操作；
- 业务逻辑、权限、事务等等一系列的事情等着 Service 层去做，如此产生了大量的依赖和循环依赖，当业务复杂度上升时，直接导致了服务层所含的代码过于庞大和复杂、测试成本直线上升，并且各个 Service 的逻辑散落在各处，维护的成本也非常大；
- 开发与产品之间的「沟通」不能保持一致，双方对于同一事物的「表达和理解」有很大的区别。产品看到的是实际的「业务场景」，而开发则更关注背后的「实现逻辑」。
SipingXu/clean-code
Folders and files
| Name | Name | Last commit date | |
|---|---|---|---|