多种接收方案促成的正确描述有(多种接受方案促成法的正确描述)
前言
一个优秀的技术方案需要有足够的特性。每个功能都是为了解决一个或几个实际问题而设计的。我们不会为了无用的东西而临时抱佛脚。 在需求开发的过程中,有一个重要的环节,那就是技术评审。 【技术回顾】开发者细化梳理需求,分析实施过程,预判可能出现的问题和困难,总结解决方案。经过组长/负责人/多位同事的肯定,可以确定开发周期,实施开发流程。 【设计方案】是指在技术评审过程中,开发者需要提前总结好文案。它必须具有以下特征和属性,介绍
应该有可追溯的需求上下文。 记录tapd链接。Tapd是腾讯的项目管理工具,免费版和商业版都很好用。禅宗等标杆工具。记录它的原因是基于: 手头有工作的同事/团队负责人/技术评审负责人,可能没有完全理解这个需求的来源和描述。只有在复习前看一看,才能提前做好预测。不用说,团队负责人可以在tapd链接中从需求文档中快速提取出这个需求的技术可行性和难点。团队可能不会使用与后端相同的文档集。可能后端用的是【嘲鸟】,需求团队只用的是【tapd】。方便后续开发者,能够接管,并且能够追溯后台。方便开发者自己每天下班后同步tapd链接进度。示例: tapd : https://www.tapd.cn/my_worktable?来源_用户=? 00-1010应该可以根据大数据搜索引擎快速定位文档。 对于每个需求,应该提取一个标签进行搜索。该标签必须具有需求特征,并且可以键入多个。记录它的原因是基于: 随着需求的迭代,会积累越来越多的文档。凭记忆很难找到相应的文件。但是文档管理平台内置了ES搜索引擎,大数据匹配非常精准。您可以通过标签快速索引到所需位置。随着开发人员的流动,历史代码需要可追溯的文档来帮助新来者跟踪上下文。示例: 标签:新人指南新人流程主线指南 00-1010应该有完整的开发属性。 每个需求都应该有相对完善的开发属性。可以做到,即使是第一次用户也可以根据文档完成技术的第二次打开。出于以下原因: Jenkins不知道是哪个开发分支,是哪个开发仓库,是哪个前置、后置、测试和产品,是哪个参考示例: 詹金斯: http://xxx.jenkins.xxx.com/job/xxxsrv-release/ 分支:新用户指南 https://xxx.xxx.com/git :xxxxxxx/xxxsrv.git
人员:前端-张1客户端-李2产品-王0后端-赵9数据-图10
挂链
用图表代替多余复杂的文字。需要流程图。当逻辑比较复杂的时候,光看产品需求文档和代码是无法理清楚的。不要看流程图中的螺柱,只是一个图片灯。把树枝拆开来画。合格的流程图是提前切断的策略。你可以参考法典中的【否则禁止原则】。//有了正确的流程图策略,就会画出三个图,即A、B、C出口。
如果a {
返回
}
如果b {
返回
}
c
返回//错误的流程图策略,将绘制单个图表。都达,有三个出口。
如果a {
}否则如果b {
} else {
}
整理正确的er图,建立1-n相关性。统一映射工具。一组一队的图片在狂舞,不利于维护。我用的是[processon],不是很贵,70r/年。
标签
不要写文章。每个人都有不同的顾虑。前1-5个功能可以放到技术方案首页。后几个模块,往往基于处理不同的职能人员,需要分层:
必须有一个[客户端界面]单一文件。客户端只关注接口访问参数,更关注你的方案分析。必须有[后台接口]单个文件。管理后台前端,只关注后台界面的访问参数,更关注方案分析。有[sql]。要拥有新的独立sql文件,请在执行发布计划时进行复制和粘贴。
申请权限,出错率低。要有【发布计划】。记录需求周期,发布流程中的注意事项等。要有客户端代码压缩包。记录调用代码参考,方便业务中台参考引用。要有美术资源压缩包。记录美术图样例,方便二开,以及业务中台引用。接口文档从简,忌讳一个接口一个文件。样例
语雀层级由于语雀空间可见性,该层级只能对团队内文档访问。
主线引导 @落后的奇异果 | - 设计方案 | - 客户端接口 | - 后台接口 | - 子游戏接口 | - sql | - 发布计划 |- 归档 | - 客户端代码资源 | - 美术资源 | - 产品资源主线引导@落后的奇异果新人引导 @落后的奇异果 · myself
设计方案设计方案 · myself
客户端接口给app端,h5端,小程序端等客户端提供的接口
客户端接口 · myself
子游戏接口给服务间提供的接口。和客户端差异在内网鉴权,和私有域名。
子游戏接口 · myself
后台接口给管理后台使用。和上者的差异在后台鉴权。
后台接口 · myself
sql记录需求产生的新模型。
sql · myself
发布计划记录发布前的一些细节统筹。发布细节本章不作样例分析。
归档归档这边省略了,因为只是添加附件上去,一般在上线前,找客户端和美术要资源。