码农开发规范
【luckydraw-ddd】①大厂码农开发规范
学习总结
了解大厂开发技术栈、规范、流程等相关内容，从系统需求分析、系统架构设计、系统开发、上线维护等掌握系统开发流程规范，后续结合相关的系统应用开发掌握相关技术栈的应用和开发流程规范
1.开发技术栈
互联网分布式技术图
2.角色介绍
业务
需求的背后是依赖于某些战略落地的背景，完成目标结果，这个目标可能是拉新、促活、留存等等，最终在预期投入下完成价值产出
产品
业务定需求、产品做方案，产品经理需要梳理方案执行落地的过程，协调各方部门配合完成项目开发。当产品经理把各方可配合的信息协调好后，就开始整理输出PRD文档，在整理完成后开始拉对应的项目需要的人员，组会一起评审PRD。通过反复多次评审完成后交棒给研发。
研发
当产品经理的PRD评审通过后，按照项目的大小会有架构师、跨部门协同人员、项目开发人员、测试人员等进入到项目开发落地中。在这个阶段首先会有架构师确定整体的实现方案，再通过会议评审后，把需求拆分模块拆解分配到各个研发人员身上。再由研发人员进行细节设计、把握开发过程。
在研发整体设计完成后，统一组会进行设计评审，这时候需要产品、运营、架构师、开发人员、UI以及leader，都会参会评审，评审内容包括：架构设计、细节设计、人员分工、开发时间、联调时间、测试时间、预发时间和上线节点，以及运营介入的时间和外部人员配合的时间。这些内容都在会议上确认完毕后，会由产品经理发出一个整体的项目计划甘特图，由各方人员知晓投入的时间节点以及确认工时投入和目标产出。确认完毕，研发正式进入开发阶段，并每天有一次敏捷日会，来反馈风险和进度以及待推进完成的事项。
测试
当研发项目逐步接近尾声，并已经完成提测标准时候，有代码评审、有测试用例、有自行验证下，对应项目所分配的测试人员就会开始编写测试用例并进入用例评审。有些时候测试用例也会早于研发提测前就开始进行，当测试用例评审完成并已经拿到研发人员提测报告，测试过程包括：冒烟测试、功能、流程和预发以及白名单测试。在测试的过程中测试人员会关注到每一个细节的节点，白盒测试人员还会关注代码实现流程。当测试工作完成以后，会提交测试报告，再由研发人员通知系统上线时间点，约定各方配合验证，最终发布到线上，交付产品和业务方进行验收
运营
在测试和上线的过程中，运营人员会配合配置一些活动、玩法、券信息、息费、地图链路、视频等各项内容，来配合测试人员进行系统验证。在最终系统交付后也是需要运营人员进行处理各项运营动作，使用业务费用，完成业务目标，收集GMV、PV、PV、获客、留存、转换等各项数据，用于分析效果和制定优化完善策略
3.系统架构设计
根据需求大小构建系统设计：
- 拆解项目的各项人员职责、确定系统架构（模块功能细化设计、库表设计、分支计划、工程导图构建）
- 执行进度汇总表（统计上线阶段的各项进度把控风险，开发并推进交付）
职责总表
一般使用专门的系统或者一个excel表，记录前端、后端、UI、需要配合的外部、运维和测试，这些人员的在此项目的工作职责、预估工期、启动时间和预计完成时间。方便在项目开发阶段可以明确的找到各个模块对应的负责人员，减少一定的沟通成本
系统架构
负载(LVS、F5、Nginx)、网关(Zuul、Gateway、自研)、结构(DDD、MVC、SOA)、治理(RateLimiter、HyStrix、netflix)、框架(Spring、SpringBoot、MyBatis)、服务(RPC、MQ、分布式任务、配置中心)、数据(ES、HBase、Mysql&分库分表)，七个模块是整个搭建系统架构过程中必须考虑到的点。一般在公司内部这些基本是固定成型的，除非是系统有升级或者之前没到的新技术才会重新设计架构
功能模块
在系统架构制定完成后，就需要把具体的需求拆分到各个人员手里进行细节设计，包括：服务领域的拆分、功能细节实现、网关接口包装等，这些细节的设计可以更好的评估出指定人员完成此需求的工期，算是包产到户的感觉
库表设计
库表设计奠定开发阶段数据存储、扩展的基础，依托于详细结构设计和底层结构的建设
针对较大型的系统开发，可设计分库分表，并结合应用场景将数据通过类似otter的工具，通过binlog把数据同步到ES以用于使用
分支计划
设定统一分支名称、分支范围约束代码提交（一个需求开发可能涉及不同系统、或者是按照功能模块开发限定）
命名规范可采用时间、开发者、开发内容，组合一个分支名称
工程导图
将功能模块借助xmind思维导图、visio图示进行展示
进度汇总
在项目开发和上线阶段，如果要保证项目的进度，就需要做一些进度汇总和风险暴露的策略制定。比如一个敏捷项目需要每天开发日会，汇总研发的开发进度、测试的用例进度、产品的补全进度、运营的配合进度等，这些交叉信息的汇聚，会尽可能避免出现，“你认为、你觉得”这样的事情的发生，提早暴露和规避临近测试和上线时暴露的风险。
上线计划
测试接近尾声，需梳理相应的上线计划和准备工作：例如上线资源申请（服务器、数据库、组件授权、服务配置、权限开通、埋点数据）、接口服务验证、运营服务配置等
4.开发阶段
系统搭建
依据系统需要服务建设的复杂度来选择搭建的框架，比如：单体架构、分布式架构、分库分表架构、分层架构等，按照不同的体量进行选择。如果是较大型的系统开发则会把不同的职责拆分为独立的系统进行开发，包括：基础层、业务层、网关层、任务层、异步层，基础层处理数据库、Redis、ES的使用以及提供原子接口。业务层用于包装业务、网关提供Http接口、任务层处理分布式任务、异步层用于接收MQ消息。
数据服务
一般互联网中的系统大部分都是使用 MySql 作为数据库服务使用，免费+分库分表策略。如果分库分表那么散落在各个库表里的数据，就需要基于binlog 把数据使用 otter 工具同步到 ES 中，便于汇总查询。
测试环境
在一些大厂开发中，通常本地的开发机器是不能直接启动运行测试完整流程的，需要把服务部署到测试环境，才可以正常调用访问一些相关资源。
功能开发
从一个系统的开发过程可以包括：数据库表创建、原子服务开发、业务逻辑串联、领域功能实现、网关接口包装，一层层搭建和开发各个模块的功能。重在思考领域的建设，把隔层的实现分离到各个层里，避免互相污染。常用技术使用上包括：RPC、MQ、分布式任务、配置中心、网关、Redis
单元测试
其实这个是一个研发标准或者内部自发的约定，因为很大一部分研发是不写单测的，也不考虑单测覆盖率，这样的代码通常在交付测试以后会有很大的风险，其实编写单元测试是提升研发交付质量非常重要的一环，只有你自己已经完整地测试过的代码，才会保证如期交付上线。
接口联调
在接口联调阶段主要包括自身功能开发对接外部，和自己提供出去的接口。通常在服务端开发完成接口的30%时，可以把部分接口提供给前端，前端开始对接接口，服务端陆续提供新的接口。直至所有接口对接完成并联调通过。
提交测试
在研发开发完成并代码评审以后，接下来就是对整个系统开始提交测试阶段。这个时候需要按照约定提交测试报告，包括：涉及的系统、开发的接口、单测覆盖度等。
5.系统上线维护
当系统开发完成并已经全部测试以后，就到了正式发布上线的阶段。通常在测试阶段还会包括预发测试，预发环境一般都是单台的数据库和单台的服务，所以正式上线时需要申请新的资源，并配置相应信息以及初始化服务和数据。
环境
通常在测试人员发出系统测试通过后，研发人员会在测试的邮件上，发送一个系统上线通知。这样所有和系统相关的人员：研发、产品、运营、业务，都会做属于自己的工作。配合的研发人员会进行提前的接口发布提供服务、前端会等待后端的接口上线、运营会配置好活动以及等待新系统上线后的配置、业务人员会做一些计划。而自己内部的研发则需要把所有上线时需要准备好的环境处理完毕，等待系统开发上线。
部署
在系统部署阶段，一般公司内部可能会因为系统的使用范围有不同的上线标准，可能有些是手动发布，有些是服务上云弹性发布。那么这些手动发布的系统一般是基于 Jenkins 实现的部署工具，上线发布的过程基本也类似，可以半自动化发布，一台或者多台服务部署。部署的过程需要特别注意：日志打印的信息，RPC接口挂载情况，外部调用链接情况，指定IP调用的返回情况等，当所有你需要验证的功能都完毕后，再逐步选中其他服务进行20%、30%这样的量进行发布上线。
监控
系统发布完成以后还需要进行监控的配置，比如：TP99、TP999、QPS、TPS、可用率、响应时长、负载、IO、网络、慢查询、事务、连接数等等，都需要从你的监控中有所体现，并能及时把报警信息推送出来。可能你听过一些类似于 Dapper 的非入侵全链路监控，它们是基于字节码插桩技术实现的，可以在性能损耗 1% 的范围进行间隔采集系统运行情况，并实时展示系统运行监控状况。另外除了系统监控以外，还有数据库监控、网络监控、应用实例监控等等，这些监控系统的配合使用，来保证监控的运行。