代码优化与code review

虽然我做前端已经一年多了，但是总感觉自己还未入门。和基础有关，也和自身的意识有关。最近听到一个词是“code review”即代码评审。不管是一些压力测试还是代码评审，都是为了将代码进行优化。

       今天在看技术胖前辈的“vue+koa2电商项目”的时候，他提及到了代码优化。先将代码贴出来看。

目的： 商品价格的格式化

// 第一版
export function toMoney(money){
    let newMoney = money;
    if(newMoney){
        newMoney= newMoney.toFixed(2);
    }else{
        newMoney = 0;
        newMoney= newMoney.toFixed(2);
    }
    return newMoney;
}

这可能是很多刚入门的代码风格，能够实现功能，但是相对冗长。

// 第二版
export function toMoney(money = 0){
    return money.toFixed(2);
}

       相对来说，第二版就简洁很多。若money没有值，就初始化为0。而且去掉了newMoney这个变量，使得代码更加简洁。为函数添加默认值是ES6的新功能。我个人很大的疑惑就是很多东西看了，敲了代码片段，但是没有运用到项目中，一切就被从大脑中抹去。其实，新的功能之所以出现，就是因为之前的东西有欠妥的部分，而我却固执己见，没有想过优化。所以，小伙伴们以后如果遇到和我类似的问题，可以将从前的代码用新出现的功能进行优化。（我知道ES6出来很久了，希望不要有人因此怼我。）

关于 code review 

       由于自己未在大公司工作过，基本都是在创业公司。创业公司是不会有时间进行code review这方面的工作。所以，如果个人想要在代码的优雅性上提高，该如何做呢？其实这个问题我还没有开始寻找答案。

注意点： （摘自网络）

     （1）code review 应该被视作高优先级的事情。你阅读代码并提供反馈意见时，花点时间无所谓，但 review 必须要立刻开始 —— 最好是在几分钟内。

     （2）初级工程师的常常需要更多手把手的指导，比如为他们提供更多的样例代码和参考；资深工程师则需要提醒他们注意他们写的高性能，抽象或者讨巧的代码是很难阅读的，所以需要写更多的注释和文档。

     （3）经常进行Code Review。千万不要等大厦都盖好了再去Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修，的各个时候循序渐进地进行Review，这样反而会更有效率，也更有帮助。

    （4）先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review。当然，最佳的practice是，每次Review的代码应该在1000行以内，时间不能超过一部电影的时间——1.5小时（因为据说那个一个正常人的膀胱可以容纳尿液的最长限度）

（5）尽可能的让不同的人Reivew你的代码

（6）Do I Understand the “Why”?

       Code Review 最常见的一个问题就是 Review 代码的人并不十分清楚这段代码究竟是要干什么，解决怎样的问题，完成什么功能。通常都是在根据代码进行推理，猜测代码的功能，这会造成效率极大的下降，由于一直在猜 Review 的质量就可想而知了，久而久之就变成了形式化的东西 。因此 Linkedin 会要求 commit 代码时给出完整的代码动机，功能和设计方面的描述，这样 Reviewer 在看代码前就可以有清晰的认知，而不是一边看代码一边猜。

 

相关工具：phabricator

相关链接：

关于CodeReview https://www.jianshu.com/p/4b382cc95850

该文中附录Tumblr 工程师 cyle 进行代码 review 的经验。

CODE REVIEW中的几个提示  https://blog.csdn.net/u012516166/article/details/80694605