今天看了陈皓的《从Code Review 谈如何做技术》一文，笔记一些有启发的重点如下：

首先要清晰思考

很多时候，人思考问题不清楚，很大一部分原因是因为把很多问题混为一谈。

Code Review 的好处：

主要是让代码可以更好地组织起来，更易读，有更高的维护性，同时可以达到知识共享，找到bug只是其中的副产品。

代码的质量级别：

  1. 可编译
  2. 可运行
  3. 可测试
  4. 可读
  5. 可维护
  6. 可重用

通过自动化测试可达到第3级；

通过 Code Review 至少会在第4级甚至更高

Code Review 做不起来，没效果的问题和原因如下：

  • 人员能力不足；即不知道什么是好代码，什么是不好的代码。
  • 结果更重要；不关注质量、成长，急功近利。
  • 人员的态度问题；完事交差心态，自扫门前雪心态。
  • 需求变化问题；代码生命同期短就算了（如一次性Demo等，而现实中这样的项目其实不多），正常的项目如果需求变化快，代码质量要求反而更高，要能不断适应快速变化的需求。
  • 时间不够；这是需求管理和项目管理不善的问题，需另外解决，思路如下：
    • 梳理需求，分析清楚哪些该做，哪些不该做；
      • 拿到需求后问几个问题：为什么要做？业务影响度有多大？有多少用户受益？回答不清这些问题，没有数据支持就不做。
      • 产品经理的成长：
        • 不但对用户把握得很好，也对软件工艺把握得很好。
        • 不但会开出外在的功能性需求，也同样会开出内在的让软件系统更完善的非功能性需求。
        • 不是在迁就用户，而是引导用户。
        • 不会无限制地加功能，而是把握产品灵魂，控制并简化功能。
        • 会为要做的和不做的需求感到同样的自豪。
      • 做事情是要讲效率的。
      • 需求总是会变化的，不要抱怨需求变化太快。应该抱怨的是为什么我们没有把握好方向？老变？没有应对好这些变化？
      • 当你忙得象牲口一样时，想一下是不是因为自己做事的时候就象牲口一样思考？
    • 寻求资源，不重复造轮子，进一步减少必须要做的需求；
    • 分解需求，设定合理的进度目标；

对技术人员的培养：

  • 写每一个模块，都 Code Review 和 Refactor 至 Elegant （优雅）的级别；
  • 经常学习并分享好的技术文章；
  • 降低手头的重复工作和维护性工作，通过使用工具、编写工具等消除它们；
  • 拒绝或简化不合理的需求并征得所有（Stakeholder）利益相关者的同意；
  • 对自己负责，内心中坚持尽可能高的标准，尽量不对骨感的现实妥协，如果妥协得受不了了就选择离开吧~

【个人感悟】：

Code Review 确实是最有益的编程实践，甚至没有“之一”，然而骨感的现实是80%的开发者做不到（80/20法则应该在此处适用），即使是做到的20%，其中80%还是被逼的，呵呵……包括我在内也是这样，因此需要想办法冲破这些心结和障碍登上那个新的台阶！

  • 从 Review 自己的代码开始做起，每每为自己的优雅代码而欢颜颂唱，或为自己的愚蠢蹩脚而痛斥凌骂：“垃圾！Shite！一坨翔！&#@……”；
  • 多读别人的代码，特别是好的开源项目的代码，建立与好代码的“亲切感”，见到优雅的代码如沐春风一般，这感觉应该就差不多了；
  • 多分享，写一些小工具，开源并写相应的文档，接受各种挑剔、拍砖和建议等，不断改进修正而提高自己的代码质量和编程设计水平……