业务代码 Review

基本规范

编码规范

• 参考eslint中的规范即可。
• 单词命名语义化
• 添加必要的注释
• 单词拼写要正确，可以借助vscode的拼写检查插件

交互规范

• 获取文本内容的时候，比如文本输入框，搜索框，默认需要对文本做 trim()后，在有值的情况下，再做进一步处理。
• 包含异步或较大计算量的任务处理，需要加防重。

代码复用

• 超过2次的代码，建议抽取。
• 超过3次的代码，需要进行封装，方便复用。
• 一个函数只做一件事件，方便阅读和写单测。
• 组件重复逻辑较多的，建议抽取为hooks或者公共组件。

记录

营养项目迭代

A同学

• 未使用的变量，nutritionDoctor
• JSON.parse(desc)，重复调用了四次，isJSON方法判断
• index，本身数组有带下标，是否还需要重新赋值
• className，命名同时有中划线和下划线
• 两个方法里面，有重复代码可以提取为方法
• show，建议改成boolean
• 用空字符串，还是 标签？
• 不良反应问卷跳转逻辑，跟@苏子 确认下。
• 营养师后台，一些未使用的变量，以及console.log 可以删除

B同学

• 逻辑分支判断使用if else使用，会更加清晰些。
• 返回的结果，取值的时候，加上防御性判断。
• fetch 请求方法封装，直接返回 data，可以考虑新加一个方法来做。
• 取请求返回值的 data 的时候，先用变量缓存。
• 第一天体重判断，特殊逻辑，加注释。
• 注释太少了，有些业务逻辑，只有自己知道的，需要加必要的注释。

C同学

• 图片用常量来存
• timeLists = []，清空的逻辑不够清晰、连贯，需要深入后面的代码才能理解这个地方的逻辑，需要加注释说明
• img 标签，多处 alt 属性需要补全
• lock 图片变量，应该常量命名方式
• localStorage.removeItem('query_patientId')，添加注释

计划框架迭代

• 1.单词拼写的错误，除了自己的代码外，跟后端对接口的时候，如果发现单词拼写错误，或者命名不够语义化，不够简洁，不合理，也要指出来。这才是系分对接口的意义所在。单词拼写错误，可能会导致一些问题：阅读、维护比较难受；如果是参数，则可能导致接口调用失败。推荐大家下载 vscode 的单词检查插件（code spell checker），来对代码进行检查。单词拼写正确，符合语义，是正常编码的基本要求，大家一定要重视！
• 2.组件都尽量把props的propTypes加上，这样在使用组件的时候，可以帮我们检测哪些属性是必传的。
• 3.重复的代码块、逻辑，超过2次，请抽取为公共方法。如果在多个文件调用，请抽取为项目的公共方法。
• 4.减少对对象的属性访问，在作用域的代码块顶部解构出要使用的属性，减少性能浪费。
• 5.删除调试代码比如vconsole,console.log
• 6.避免无谓的代码重复执行。务必把代码逻辑梳理清楚（if，else）。减少类似的重复赋值，尤其是setState，会带来性能损耗。
• 7.注释要清晰，带上必要的业务背景，方便维护和阅读。
• 8.随手创建的css文件，没有任何代码，但是会被组件引用到，务必删除。

A同学

• 重复多次代码，需要提取方法
• 
• 表单提交需要添加防重
• 字面量常量，尽量使用大写

C同学

• 拼写错误较多
• 多个变量重复声明，可以放到常量文件中，再引入
• 冗余的注释
• 删除无用的文件
• 缺少 data 为 null 的判断处理

SOP迭代

A同学

• 跟UI稿字体大小不一致
• 单词拼写：getFiledItem 修改为 getFieldItem
• 同一个方法中的重复判断，可以用变量来缓存结果，提升计算效率
• CSS命名问题

B同学

• 避免全局CSS样式
• 避免important的使用
• 不必要的属性
• 较多的属性值，可以先在方法顶部进行结构