编码知识首页
引言
对想表达的东西做个索引，方便检索。
代码原理
如上图所示包含了个人在思考代码的一些思考点：
- 利益驱动
思考一个方案或者代码的写法，不能靠经验或者习惯，或者权威，而是应该从利益驱动的角度出发，分析每种方案的收益，选择最有利的方案；很多不同的写法只是适用场景不同，并无优劣之分。 所谓收益是实际的收益，不能只是感觉。
- 表驱动法
在代码Review中，我们经常会发现代码中大量if-esle结构应该使用Map数据结构取代，数据和逻辑有时是相通的；《代码大全》对此起名是表驱动法，表驱动法可以解决很多问题，比如《使用面向行为编程解除项目耦合》也可以认为是一种表驱动的应用。
传统的分层一般是：用户界面层 -》 应用服务-》 领域服务 -》基础设施层（存储）；严格意义的上层依赖下层对复杂业务并不是很有效，如果采用依赖倒转，会变为基础实施层依赖于领域层提供的基础实施定义；采用更重视业务【六角形架构】，可能更符合复杂业务的发展，你会发现分层被拍平了。
Command Query Responsibility Segregation，CQRS
说白了就是读写分离，分别为读写设计，可以通过数据分发冗余数据抗读流量，不用受写业务影响读设计,可参考《常用互联网架构》的抗量部分。
为80%设计简易途径，特殊需求采用麻烦途径。比如互联网架构中我们缓存中有100个字段，其中一个客户访问占80%流量，但只访问其中的10几个字段，那么我们就可以为这个客户专门异构一个缓存集群；再比如我们在某个业务中对写没有性能要求，但读的流量非常大，我们可以对数据结构按抗读流量来设计，写的时候可以麻烦点或者冗余部分数据。
尽量通过简单的办法来达到目的，技术本身并无优劣之分，关键是要识别面对的问题，分析出当中的痛点，选用合适的技术解决。
- 代码表现力
提升代码的表现力。
- 业务驱动
写代码不应该直接想代码怎么写，应该先假设自己是业务人员，从业务的角度怎么描述业务，能说的清楚，再用代码描述。写代码的过程是业务到代码的映射过程；所以写代码要建立业务和代码间的思维映射。
文章：【先考虑逻辑再写代码】
文章：【搞懂DDD在说什么】
- 业务中台建设
在中台业务组价积累的基础上，快速响应前台业务。
文章：【 中台化建设】
- 学习的过程
总结知识的获取过程。