阐明: 生鲜电商属于一个软件的产品，那么如何做好代码设计呢？代码设计，是程序员做我的项目时，在 coding 之前十分重要的一个步骤，能够说关系到整个零碎、整个团队的研发品质和效率。个别说代码设计，可能涵盖以下几种：
1. 整体设计
2. 架构设计
3. 畛域模型设计
4. 数据库设计
5.API 设计
6. 代码实现设计
代码设计的前提是，我的项目组成员曾经实现正式的需要评审，并通过充沛思考：
1. 这个需要是为什么业务指标服务的？
2. 这个需要形容的内容，是否为服务该指标最合适的形式（包含研发性价比、我的项目周期等）?
3.prd 自身是否逻辑自洽?
4. 是否每个内容点都可实现?
5. 实现的技术计划是什么?
6. 是否做过相似的性能，合并吗？复用吗？拆解吗？
整体设计与架构设计
“我的项目的整体设计，有时会涵盖零碎架构设计，这里要辨别一下，零碎架构设计并不齐全等同于代码架构设计。”
整体设计首先要思考的，是以后我的项目是要做一个全新的我的项目，还是要做原有我的项目根底上革新、迭代；项目组的积攒中，是否有能够复用的中央（模块或成熟计划），是否有能够通过革新以合乎新我的项目需要的可能。
其次再思考，如果是新起我的项目，要如何搭建整体实施方案，内容个别包含：
1、硬件部署与资源申请：硬件和资源，是要和业务需要联合来制订的，比方业务最大拜访、TPS/QPS 等，要切实探讨得出一个数据范畴，以确定零碎是否做高并发计划。另外还要思考容灾等问题，以此制订零碎高可用的设计。
2、剖析我的项目特地突出的业务、技术难点：如千人千面的 UI 和查问，或灵便配置的业务模式，相似这种需要的我的项目，会在模块模型设计上做额定解决，可能是将各种规定独自做一层规定引擎，也可能是在数据建模时减少更多维度；再比方超大的 QPS，可能要在整体架构上，增加额定的中间层，异步收集数据等性能；还有就是依赖于审核的迭代上线周期（IOS、微信小程序）等，都要在整体设计中思考进去。
3、内外部信息替换通信：整体设计零碎，要明确划定我的项目范畴，哪些是本零碎的性能，哪些性能、数据依赖其它零碎或模块。要明确此次我的项目对外交互零碎的拜访关系和拜访条件。
4、数据的长久化存储计划，如何抉择硬件，如何抉择软件，个别有惯例解决方案。特地要思考和需要联合的一点是业务数据的生命周期，这也是数据归档计划等重要依据。
“整体设计中十分重要的一部分是零碎架构设计，要在业务边界确定的前提下进行。”
首先，从业务视角进行拆解性能，定义零碎由哪些模块形成。
其次，依据业务复杂度、模块功能性划分，抉择正当的软件架构模式及计划。
比方，业务需要上，有非常复杂的流程解决，但各个业务子模块之间绝对独立，则能够抉择事件驱动型架构，基本上用状态机、工作流就能够满足性能了；再比方做微服务架构设计上，也不肯定都做集中式负载平衡，如果整体性能需要对音讯流转要求比拟高，则能够思考核心音讯型服务（比方 Rocketmq）。
以上两步更多是从需要上剖析，偏近于从业务角度设计零碎。前面两步要从技术上做架构设计。
下一步要依据模块划分和架构计划抉择适合的开发语言和技术框架。生产上个别思考优选 Java 语言 +Spring 框架，但也有许多混搭的成熟计划，有些基于 JVM 的开源框架中对多语言的反对还是比拟好的。
再下一步要将零碎拆解，个别思考划分出展示层、（通信层）服务层、数据层，再依据需要为每一层设计正当的服务及组件。如展示层上 web 还是 mobile，服务层是用 Spring Boot 还是 Spring Cloud 做微服务，数据层应用 Mysql 还是 Oracle 等。另外还有我的项目服务等通用组件及各种业务、技术中间件、及整体我的项目通用的技术计划选型，如日志（ELK 等）、监控告警，拜访受权，token 认证等。
整体设计要在需要明确（不肯定所有细节齐全敲定）的前提下尽心，个别造成定案要在正式需要评审会之后。
整体设计由团队 leader 或我的项目 owner 实现。
整体设计文档，优先思考应用物理部署图、逻辑架构图、业务流程图等形容零碎架构。
另：特地倡议在需要评审会后，首先由研发 lead 组织召开设计探讨会议。目标是让我的项目成员尽早的参加到我的项目之中，并应用探讨到形式，更好的了解我的项目及整体设计方案。
个别设计探讨可用头脑风暴形式进行会议。有重大一致时，能够投票表决。
此探讨会议召开前，须要 leader 提前设定议题，会议上设有 1 名主持人（可 leader 专任或者 team member 轮流负责），依照议题集中，轮流发言再个体探讨形式得出结论。
次要议题包含：整体设计方向、我的项目人员大抵分工、待解决疑难和解决人。
畛域模型设计与数据库设计
在整体架构设计实现后，要针对曾经拆分的零碎模块做模型设计，尤其是在我的项目需要中有重要性能的局部要重点设计。领域建模要深度联合需要，从业务角度登程，用一种自顶而下的形式来建设模型。
领域建模办法很多，最重要的准则是在我的项目模型建设之前，要先做概念的对立整顿，要对特定概念的名词做业余命名及能力束缚。在此基础上，再进行重叠性能的归并和形象。须要留神的是，此处制订的模型，和业务需要、数据库设计、代码类设计，都是一脉相承的，但并不齐全等同。比方需要中有订单 Order 的概念，在设计订单 Order 都有哪些元素形成，能够实现什么操作时会发现，要在数据库和代码中，拆分为 OrderHeader 和 OrderDetail。
在畛域模型中，还有一个重点，是要标注分明各抽象概念之间的数据关系和束缚。个别会比拟关注数据之间是一对一、一对多、多对多等关系，并在此基础上，联合业务流程泳道做零碎模块依赖关系图、数据流图等。
数据库个别联合畛域模型设计，是畛域模型长久化存储的映射转化（ORMapping）。在我的项目数据库设计中，除了惯例关注的范式、mysql 束缚等（独自写过 mysql 利用的 usage，此文略），额定关注：
1、表字段在整体零碎中的标准定义和对立应用。比方雷同的概念，在各个表字段中的定义要统一，（在代码利用中也应保持一致）。
2、数据库事务的利用计划。
3、冗余字段与代码简洁实用的均衡。
4、特地阐明，数据库个别仅作数据的长久化存储，不要将业务逻辑的解决放到数据库中进行。
5、生产业务数据 delete，应该仅作逻辑删除，不做物理删除。
6、表设计要和性能联合起来，特地当 DB 成为性能瓶颈时，要特地斟酌索引设计的合理性。
模型设计个别为团队 leader 或我的项目 owner 实现，数据库设计个别为 leader 率领 team member 一起实现。
数据库设计个别要先于具体性能代码实现，在做此设计后，要针对存储计划和底层数据结构设计，做 double check 和集中评审，评审内容包含存储介质选型、表结构设计是否满足技术计划、存取性能和存储空间是否满足业务倒退、表或字段之间的辩证关系、字段名称、字段类型、索引等。在评审统一通过后，积淀为文档。
API 设计与代码实现设计
在实现整体设计后，要将所有性能拆分成独立可调用的 API。这里的设计要思考零碎实现和业务需要的联合。零碎 API 拆分，肯定是从需要实现角度思考，基于畛域能力做的，且要充分考虑后续需要的变动演进，尽量使更多后续性能变动在既有规定服务 API 的框架内持续演变。此外还要关注非功能性需要，比方安全性、可用性、可扩展性等。最初，在这个步骤要关注的点，除了零碎骨干正向流程外，还有逆向流程、异样流程、业务边界等方面的接口定义。API 是零碎模块对外提供的服务，现行零碎根本满足前后端拆散的框架应用条件，所以个别能够简略了解为前端和零碎交互的入口。但理论零碎设计中，API 不仅仅提供给前端应用，所以每个 API 的实现设计是零碎模块设计中十分重要的环节。
API 的调用方个别会思考给展现层多端调用（web、mobile 等），还要思考雷同的 API 是否能够给其它零碎模块应用，最初一层设计是，是否用雷同的 API 对外提供 openAPI 服务。设计中该当特地思考此类 API 的性能聚合、拆散，多场景适用性等。以订单列表查问为例，设计一个订单列表 query 接口：
1、给前端页面查问，前端分页每次传参。这个场景最大的特点是，查问页面会设计较多分类查问的筛选条件，且此类设计实现常常可能是查问条件间接投射到 DB 上。
2、在整体零碎中，给其它模块应用，如用户模块或报表模块。这个场景的特点是，如果其它模块性能为同步调用，则 QPS 不可预测，比方用户模块应用了这个订单 query 接口，那么这个接口的性能就会成为用户模块的瓶颈。还有一种可能是其它模块用此接口异步拜访同步数据，就很有可能采纳定时工作形式，固定分页，并发调用查问，如每 5 分钟调用一次，每次调用并发 20，每个拜访查问 500 分页数据。
3、给 openAPI 应用。如果凋谢给前端的 query 服务提供给开放平台间接应用或包装后间接拜访，则容易呈现的场景是，每次调用查问不确定分页，很有可能一个大分页（如十万）就打到 DB 上，这样即便索引匹配也容易造成数据库缓存区拥挤。遇到这类需要，
3.1 要思考一个 API 接口是否能够满足所有需要，是否对数据拜访做权限隔离。即，思考所有的服务都集中到一个 API 上，还是定向拆分，将一个外部实现 core，别离投射到多个 API 上。
3.2 不同拜访端如果有不同的 QPS 需要，还都思考到，单个特大 QPS 接口，能够横向合并，即，不依据业务束缚，而是把所有大拜访的接口拆出来，给到独自技术架构和硬件部署的服务里。
3.3 是否外部实现上统一，是否应用缓存、中间层计划等。
4、数据库设计尤其是索引设计要和接口设计（尤其是筛选条件）保持一致。
API 的设计还有一个维度的思考，是基于数据交互思考。当两个零碎模块要应用 API 交互数据时，定义的 API 要充分考虑应用场景，并做技术选型：
4.1. 数据是推还是拉？
4.2. 同步推送还是异步告诉回调？
4.3. 通过接口还是 MQ？是否须要削峰？
4.4. 是否须要保障强一致性？
4.5. crontab 定时发动还是工作队列发动？须要延时队列、死信队列吗？
API 拆分实现后，要做代码实现设计。此设计次要关注每个 API 的外部实现，将一系列畛域模型转换为零碎对象的类设计。这外面有 3 个图能够辅助设计：
1、如果一个 API 复杂度较高，调用链路上的波及对象较多，能够应用时序图来表白并且明确各调用环节的输出与输入，以反映对象间的交互与协作关系。时序图对实现设计评审、辅助我的项目开发有很大作用。
2、如果某个业务对象的状态较多，能够应用状态图来表白并且明确状态变动的各个触发条件。首先明确对象有多少种状态，而后明确两两状态之间是否存在间接转换关系，再明确触发状态转换的条件是什么。状态图对测试用例有很大帮忙。
3、如果零碎中模型类超过较多，且存在简单的依赖关系，能够应用类图来表白并且明确类之间的关系。类图对简单零碎设计，尤其是灵便配置、路由映射、设计模式利用等，有肯定帮忙。
类的设计要充分考虑繁多准则。该当优先应用聚合 / 组合的形式来实现。不得已应用继承的话，要使父类可能呈现的中央子类肯定可能呈现。依据依赖倒置准则，尽量依赖抽象类与接口，有利于零碎的扩大与保护。
在设计形象时，要思考以下问题：代码直观吗（好的代码自正文性很强），它的编写奇妙吗？实现细节可能隐去了吗？程序编写是立足于问题域而不是计算机科学或语言结构域吗？
程序开发有一个场景比拟典型，写第一版需要时，仅仅是一个简略性能，实现也比较简单，但后续性能减少很多，变化很大，每次在原有类定义根底上减少性能，倒置代码冗余，尤其容易造成 if-else 太多。此时要思考提前预估性能，做扩展性设计，或者在每次性能迭代中，做小版本重构。比方订单明细查问，在定义查问接口（interface）后，需要要减少一个千人千面性能，不同用户拜访返回的内容条目不一样。如果用 if-else 或 switch 写，会比拟不好治理，代码也容易凌乱，这里能够新设计一个接口，做不同内容配置，而后组合应用，或者采纳其它设计模式。
设计模式的目标，是辅助程序员更好的实现代码形象，将事实业务逻辑，映射到形象维度的代码语言上。个别生产上常常用到工厂形象工厂、模板办法、策略、状态等。抉择适合的设计模式和数据结构，有助于晋升代码的清晰简洁度。
这个档次的代码设计个别交给 team member 实现，并输入接口定义、接口具体设计、包含一些数据库的 DDL 等。
设计评审与文档核心
在我的项目施行之前，设计评审是十分重要的环节。研发 lead 应该组织外部设计探讨，每人的接口设计要通过 peer 或 backup 的 review，更好的形式是通过集中评审。
因为再好的设计，也要确保项目组所有成员，了解正确且统一。这个不仅仅是 lead 对团队的灌输，要确保组员之间对同一个业务概念的了解也是正确且统一的。要确保每人的接口设计，都合乎整体设计须要。要确保我的项目级别畛域定义合乎更下层定义（如公司级别命名），要确保我的项目级别畛域定义对立、代码实现中英文命名对立。大型项目，在 dev 外部设计通过后，也能够由项目经理组织产品、研发、测试各方开展设计评审，此处尤其要和 prd 联合，为整顿测试用例服务。
接口细节的实现也该当是入手 coding 之前先做设计，并倡议造成文档，研发 lead 要提前组织好开发文档核心，整组对立设计文档格局。
个别惯例内容包含：
•新我的项目背景、或惯例迭代我的项目里程碑
•项目管理的工夫节点（需要评审工夫、设计工夫、提测工夫、上线工夫点）
•本期我的项目概要设计说明
•分工（API、实现人、预估工时、理论工时等）
•具体设计：接口实现设计、DB 设计、缓存设计等
•上线打算等等
起源：r6d.cn/C5Ja
欢送关注我的微信公众号「码农解围」，分享 Python、Java、大数据、机器学习、人工智能等技术，关注码农技术晋升•职场解围•思维跃迁，20 万 + 码农成长充电第一站，陪有幻想的你一起成长