一只很酷的蘑菇

如何写好前端业务代码

阅读量:

一、背景

想想从15年11月到现在,从zbj以前的交易取经团,到现在的顾问平台,大大小小做了不少业务需求,也是一边踩坑(一边挖坑)一边成长。以前维护10年累计下来的老代码,缝缝补补,主站所有项目全部在一个文件夹里,也是练就了一身从定位代码的本事。到后来新项目用了新框架,node作为controller层,后台不需要兼容ie的项目也引入了vue。刚开始的时候开心得不行,终于不用苦逼地搭php那一套老开发环境,前后端彻底分离,也不用维护那些“陈年佳酿”。后来才慢慢发现,其实并不是那么轻松。java写的服务化接口,基本是原子性的接口,一个接口只做一件事,所以前端除了完成以前的工作外,node端必须去处理之前几乎没有涉及到的业务逻辑,也承担了更重要的责任。经过了一年左右,几个项目的摸索,我也总结出了一些业务经验。

二、排期

这是很重要却最容易被忽略的一个环节。项目做到后面做得很累,感觉自己怎么也完不成,往往是因为排期没有做好。

需求分析,功能模块细分

一个需求我们拿到的时候,肯定是先做需求分析。排期也是在完成需求分析的基础上进行的,需求分析的时候需要注意以下几点。

明确需求

根据产品原型和产品的需求宣讲,梳理一遍需求,如果有自己不懂或者不理解的地方一定要在这个阶段产品明确。

模块、功能划分

单页面排期一般就是从上到下按照功能不同分模块,比如顶部导航、信息展示、评价列表等等。

一般一个多页面的项目,产品们会在产品原型上根据他们的理解,分几个板块。但是我们分析需求的时候不能用他们的思路去分版块,而是要从开发和程序设计的角度去划分。比如在首页、某某搜索结果页、某某页有三个不同的地方,虽然样式不同、逻辑不完全相同,但是他们都在某步骤上涉及同一个业务逻辑。比如点击某个地方,判断用户在线,不在线调出登录框,在线的话创建订单,然后跳转支付页面。balabala,这个逻辑是不是最好让同一个人去完成,而且最好写成一个统一的接口或者组件呢。

依赖关系整理,时间线整理

划分好模块后,就是进行工期预估了。这也是一项很重要的工作,不仅是让团队的开发、测试、上线计划能够顺利开展,而且也能帮我们进行前期工作优先级安排。

需要依赖的东西包括设计稿、后端接口、其他前端组件、人员到位时间等等,排期时间需要根据这些依赖项产出的时间进行时间线的整理。

风险点预测

容易产生风险的点需要提出来,排期中留出适当的缓和时间。当然在开发中遇到阻碍也要及时抛出,让PMO或者项目负责人及时跟进解决。

每天跟进或者总结

根据排期最好做一个任务清单,每天总结完成的项目,想好明天的开发计划。

如何面对快速的业务需求迭代

最近做的一个项目是一个从0开始的新项目,产品发展方向其实也不是非常明确,需要上线试错,经过用户反馈和数据收集后不断改进。一期产品为了快速上线往往很多需求做了简化,这时候如果在一期的开发上不注重项目的扩展性,后面的每一次迭代都是伤筋动骨。

功能细分、代码模块化

尽量让功能变成积木一样的,每个部分写成一个模块,方便后期维护和拓展。代码模块化,一个几千行的文件,几百行的方法真的难以维护,其实就是一句话,当你觉得这部分代码好长,那就是需要拆分模块了。

通用接口多样化

这也算是我挖的一个坑。在一期的时候,有一个搜索接口,当时的需求只需要通过一个id进行查询,我设计的接口参数就是传一个id。当1.2.4的迭代版本的时候,产品说需要支持多个id查询,java把参数改成了数组类型。我准备改的时候,发现已经有几个其他业务方调用我这个接口,传的是单个id,我为了不去改更多地方,只能在接口层面做了单个和多个的兼容。

所以在接口设计的时候,就要尽可能考虑多种调用场景,可拓展地设计接口入参和出参。

公用逻辑提取

之前也提到了,在一期的时候可能我们并没有发现这个逻辑其他地方也可能会用,所以写到了自己的模块文件里。当后面业务发展,这个逻辑其他业务方也要接入,而且仅仅是来复制粘贴你的代码的时候,就应该要马上做出判断,这部分逻辑是否需要提成一个公用接口,如果是包含了前端各种逻辑比如弹窗、调用其他前端组件等,这个逻辑就要提成一个组件。
一是减少了后续的开发成本和维护成本,二是让这部分逻辑更加可控。保证后续修改逻辑的时候,没有遗漏到某个地方。除了保证组件的一致性,可拓展性也很重要,对于组件的设计,又是另外一个话题了。

内容配置化,业务逻辑不要写死

除了产品提出需求要开发配置功能外,我们自己也要主动去拆分可配置的内容。
一些业务上经常改动的部分,需要产品和运营去修改的部分,比如推荐位id列表,推荐位图片等,走cms配置。
一些静态数据,不经常改但是可能改动,比如网址等可以写到配置中心或者配置文件。
如果实在没必要走配置的,也要写成一个常量,这就让我想起了以前接的一个需求,把某某发布最低金额限制的判断从3000改到1000,我在老代码里ctrl+f了很多地方,才把那些3000全部改成一个统一的常量。

静态内容和代码分离是最好的,内容改动,仅仅改一下配置就行,不需要走上线流程,这样才能真正做到以不变应万变。

其他

还有其他需要注意的点,我也就不一一说明了。

  • 发现不对劲,一定要停下来和产品沟通。
  • 任何显示给用户的字符串,都应该抽取成常量,方便国际化,这点也是我做了一个项目转国际化的需求得出的感想。但是在后续开发中其实还是没有实施,如果项目有国际化的需求,需要考虑这一点。

三、业务安全问题

因为做了Node层,很多参数校验都是我们做了,也就积累了一些和业务安全相关的经验(安全测试环节被查水表)。这里提到的就不仅仅是xss和csrf了,更多的是业务层面的安全问题

  • xss
  • csrf
  • 表单提交的内容,如果网站有这个需求,需要做违规违法字过滤
  • 推送红包、站内信、通知、发布订单、发送手机验证码等http接口,需要做防刷处理,限制次数
  • 用户id用token加密解密获取,而不是直接用cookie里的userid
  • 注意判断用户的身份和权限,防止越权

四、定位问题

  1. 尽量在所有可能出错的地方,捕获并抛出问题,报错内容清晰指明什么接口报错,方便定位。比如一大堆的报错都是'系统异常!'创建支付订单失败:xxxx,哪个更容易定位错误呢?
  2. 方法文档清晰。
  3. 使用charles、findler等工具调试非本地环境代码

暂时想到了这些,如果后续还有新的体会会来补充。

陈柯伊

梦想一克拉 热血一卡车 眼泪一酒瓶 熬夜一光年

评论

文章目录