哪里网站备案方便快,实惠福步外贸论坛,html视频教学,南沙区网站建设作者#xff1a;零一来源#xff1a;前端印象前言大家好#xff0c;我是零一#xff0c;今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过#xff0c;也可能只是简单得走过过场#xff0c;别划走#xff0c;这非常重要#xff01;在字节#xff0… 作者零一来源前端印象前言大家好我是零一今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过也可能只是简单得走过过场别划走这非常重要在字节我接触到了更完善、更规范、更高效的开发流程产品需求设计 需求粗评 做设计方案 粗估时 需求细评 排期 开发 提测、修bug code review 上线其实在我未工作之前大部分的流程我都听说过或者在实习时经历过比较少接触的可能就是设计方案和code review了这两者分别是干什么的设计方案在拿到需求后写一个文档来描述自己对于该需求的实现思路、模块划分等相关考虑的点可供今后自己或他人查阅Code review代码提交合并前给mentor或leader检查一下你的代码让别人作为旁观者来看你的代码集思广益完善代码发现未考虑到的边界问题说实话哈啥设计方案啊我第一次在一家小公司实习的时候突然就被产品叫过去花5分钟给我阐述了一下下个版本他想要上的功能紧接着立马就问我你看看大概需要多久我的预估是5天后就上线ok吗我 内心os我刚知道这个需求我哪能那么快知道我得花多久做出来啊你说5天就5天吧反正我说6天也没用太离谱了可能很多小公司的现状都是像我说的这样吧这样真的很不好版本快速迭代中掺杂着许多需求而开发时间又比较紧张只会让开发想尽办法怎么赶紧把功能实现而不会去考虑任何性能问题更别说让你考虑边界问题了。长期这样下去你会深深地体会到你处于一个无止境的项目快速迭代中加班、通宵可能都是常事哪还会有时间去学习新的知识或做自己爱做的事也不会有多余的时间去关注自己接手的需求从开发到上线的整个生命周期线不会定期去复盘因此个人的项目经验、技术积累是很少的之前也有小伙伴私聊过我类似的情况我也是建议他最好能在一个有「自我学习」、「定期复盘反省」的环境中工作大圣老师就是如此记得他在有次直播中讲到他当年去360时把「能留给自己充足的学习时间」作为他最在乎的因素这样真的非常好。大家也可以看看自己当前的现状是否真的利于自己发展然后做更长远的打算。好了言归正传我们为什么要写设计方案呢目的是为了在真正开始敲代码之前理清自己的思路对需求有一个更清楚的认识这样就不至于在开始开发后边写代码边思考了想必你们都有遇到在写代码时突然发现哪一模块之前没考虑到然后对之前写好的代码的架构进行调整代码进行抽离这无疑是在降低开发效率。另一点就是时间一久突然这个功能出现了一个bug让你去修复你可能会对自己写的代码有些忘却此时找到之前自己写的设计方案一看便知这同样也能作为新入职的小伙伴在熟悉现有代码的重要资源对于第二点我深有感触到一个新部门总会接手1~2个祖传项目代码紧接着你就要阅读他们的代码逻辑这是非常痛苦的因为你根本不了解这些需求的背景也不了解他人代码完整的设计思路这不跟抱着一本厚书在那硬啃一样嘛image-20210725102004643要是之前的人都写过设计方案你完全可以在看每个模块的时候找到相应的文档这不事半功倍嘛~那么如何写设计方案呢整个方案大致分为4个部分需求相关信息、方案调研、具体方案、其它一、需求相关信息作为一个开发工程师一定要有工程师的精神需要对自己所接手的需求有清晰的认识这包括负责这个需求的其它相关人员分别是谁产品、测试、UI、后端等、我这个需求的出现背景是什么、需求何时提测何时上线...格式如下一、需求相关信息需求背景因为我们要做线下推广提高xxxxxxxxxPRD文档链接产品小华UI小明测试小红前端零一服务端小张联调时间2021.07.30提测时间2021.07.31上线时间2021.08.10
把这些内容写在设计方案的开头让跟这个需求相关、不相关的人都能一目了然如果遇到问题也可以立马精准地找到相应的人二、方案调研这一部分主要是需要我们在考虑功能实现的技术选型时对比很多不同的方案综合考虑每一种方案的优缺点可以适当地取舍和改进形成一套适合当前场景的技术方案。举个比较简单的例子吧假设你此次接的需求中有一个复杂的动画要实现那么你以下这几种考虑的方向以前我有没有做过类似的动画可以借鉴的公司内部有没有什么现成的库或者代码能用业界有没有现成的库或者比较不错的实现思路如果不用别的库用原生实现我会怎么做有没有什么兼容性等其它问题在了解了这四种场景以后我们此时需要思考别人的方案和我自己的方案哪一个更好优缺点分别是什么别人的方案是否适用于我们当前的场景在综合考虑了众多因素后我们选择一套相对比较靠谱的方案用于实行。通过以上几个步骤来支撑我们接下来敲出来的代码的可靠性与质量三、具体方案这部分是最重要的了它几乎涵盖了你所有需要思考的东西业务的完整流程、数据结构的设计、关键功能的逻辑描述、异常的处理、安全性、性能、与现有业务的耦合情况、组件复用起码要保证其他人以及你自己在看到具体的方案介绍时可以很清楚地明白你的设计思路、写代码的思路、模块的划分。你可以用任何形式去表达你的思路例如伪代码、流程图或者纯文字等等简单演示一下「流程图」流程图的设计能让你对自己的需求有更清楚的了解也能让他人对这个需求有一个直观的认识「伪代码」function getSomeData() {let data; if(无缓存) {// 请求数据if(请求异常) // 展示错误页面;data 请求到的数据;}// 展示页面
}
伪代码可以在你不写具体代码实现前展示大致的编码思路那么在大家一起过你的设计方案时就可以很清楚得知道你的代码想怎么实现因为是伪代码所以非技术的同学说不定也能看懂然后给你提点意见呢「模块划分」模块的划分也是考验你架构设计的一个点你需要考虑清楚你的代码中哪些需要单独抽离出来作为一个单独的模块哪些可以作为公共组件哪些是跟业务高耦合的「用例图」用例图的话能帮助你整理需求中每一个大大小小的场景这个光靠脑子想可能没有太大的作用当你列出来时你可能会发现这个流程好像少了点什么东西也就是有助于你考虑更全关注到一些犄角旮旯的边界。插播个小彩蛋我有个前端同事写用例写的特别好有一次leader调侃说他这个写的也太太太详细了每一处考虑得都特别周全甚至都可以直接原封不动得给测试当测试用例了hhhh我所列举的例子都比较简单大家根据自己实际情况进行操作就好。还有一些别的就是你还需要考虑一下你的某些接口需不需要考虑安全问题比如点击submit会增加抽奖次数那不会被别人恶意伪造一些信息进行刷抽奖次数呢还有你的页面会不会存在一些性能问题如果以后要在这个需求上扩展别的功能你觉得你的代码可扩展性如何当然你要考虑的肯定远不止这些希望每个工程师都能对自己的方案考虑周全做到精益求精这样才是一个合格的工程师四、其它最后一部分完全可以留给你自己自由发挥可以记录下与这个需求相关的一切我个人觉得可以写的有这些你在写设计方案时遇到的问题以及解决办法你的代码上线以后用户的反馈如何如果好好在哪里如果不好到底是哪里出了问题该如何解决你在方案调研时有没有发现别人的方案哪里做的不好或者有哪些值得学习的地方在此次整个开发流程中有觉得哪个流程不太好的低效、无用的沟通等等可以记录在此然后找相关人员讨论改进more...总之这里随心所欲发挥实践感受一开始让我写设计方案时我略微有些抗拒就心里想着为啥写个代码还要先写文档这不是在增加我的工作量嘛后来leader告诉我写设计方案的时间不会算在我的开发时间内的而是在开发时间之前给我3~4天专门用来写设计方案内心oswoc这么爽我写我写这不香的要死嘛于是我也就开始尝试写设计方案了在写的过程中发现流程上我可能会发现一些同事们都没有考虑到的问题这是站在开发的视角去看的所以产品同学难免会遗漏一些点而在case的梳理上我又偶尔会发现大家都没有考虑到的边界问题可能是真的大家都没考虑到也有可能是我的想法比较独特但这都ok在后面所有相关人员统一过我的设计方案的时候可以一起讨论出个对错。嗯这些都是光凭脑袋想不一定能想到的或者哪个瞬间想到了却来不及记录到了开发的时候又给忘了等我设计方案写完以后相关人员会约一个时间一起听我讲一遍我的设计方案不同岗位的同学有不同的视角去看问题每个人也有不同的想法所以这里能暴露出很多问题也能把很多不ok的点处理掉例如我的leader经验比较丰富每次过设计方案时他都会提醒我哪一块儿地方可能会存在安全问题记得考虑一下。再后来测试同学会整理一些测试用例拉大家case评审你之前做过了设计方案对自己的需求非常熟悉了那么在测试过你的需求的case时你会更加的明白也许测试考虑到了你没考虑到的点也许是他遗漏了某些点而你考虑到了这些都是可以互补的。完成了以上内容基本上我写代码的思路就通了确实也节省了不少的时间等我开发完以后还会再自测一遍怎么测直接拿我设计方案和测试给出来的测试用例对照着自测就好啦总不能说你自己这里都还没跑通就拿过去给测试测吧总之收获还是很大但设计方案的实施还是需要有一个不那么短的开发周期的那种需求刚提5天上线的情况哪有时间给你写设计方案啊就更别说考虑这么多东西了你自己个人也很难沉淀下东西不过哦~我突然又发现了写设计方案的另外一个隐藏好处我们的简历上不是会写上自己过往项目经验和工作经历嘛这些都跟我们做过的项目需求紧密相关你如果之前每个需求都写设计方案那么写简历还用愁嘛妥妥的筛选一下 复制粘贴啊往期推荐对象存储为什么那么火高性能开发别点发际线要紧什么是自动驾驶被 AI 算法“监控”的打工人点分享点收藏点点赞点在看
