v.youku.com
心有猛虎2
获得徽章 0
- Linus 在 2007 年 Google Talk 上介绍 Git。 他讲解了开发 Git 的初衷，CVS/SVN 的缺陷，Git 的优势，并顺带着骂了一堆人。看完这个视频，我对 Git 的理解更深入了，而且在大神的谈笑风生背后，有很多关于软件开发的深邃思想。视频时长 1 个小时 10 分钟：
v.youku.com 654 - 什么是研发思维，我总结如下：
1. 首先要懂业务，明白需求是为业务哪点服务的，自己是否认可这个需求。 就好比大楼的建筑工人，也应该明白大楼为什么这么设计。要不然只能永远是工人。 而且产品的需求文档不可能事无巨细，理解需求对于清晰的实现很重要。
2. 其次要有分析，优化研发方案的能力。 我要解决什么问题，我要实现的性能，可拓展性是什么样的，我有哪些方案可以做，我做了什么限制条件，我是否可以做的更好。真的无法做的更好了吗，再次优化。
3. 再次要具备方法论。 明确方案，去实施的时候，如何通过遵守流程保证质量。如何保持代码的可读性。如何减少代码的bug几率。
4. 而且要有责任心。 研发出来的产品就像生出来的孩子，不能不负责了 。持续的优化，问题的跟踪解决要积极主动响应。
5. 要有以终为始的素质。 从项目中总结自己可以做的更好的地方，优化自己的方法论，自己的研发思维。展开评论18 - code review 究竟如何是好？
1、容量。
贺师俊在这个回答里www.zhihu.com 提到一点：每个 PR 强制要求改动行数小于100行，新人要求小于60行，以保证 code review 的实际可操作性。因为 PR 太大，review 和 reject 的成本都比较高，就容易倾向于放水。
2、时机。
不能赶在上线前提 PR，否则提出的问题改还是不改呢？改了要不要重新测呢？reviewer 一看要上线，也更容易倾向于“通情达理”直接 approve。所以至少应该在提测前提一次 PR。
3、匿名？
并非所有人都能完全做到公私分明、就事论事。你要不要指出比你职级更高的人的问题？某个问题改良的成本很高，不改的话尽管不好但也能用，那还要不要提？
4、范围。
为控制时间成本，并非所有代码都需要 review，就前端而言，通常只需要 review js，那么具体 review js 的什么呢？你并不知道背后的业务逻辑，那到底 review 啥？一般来说需要关注：函数的设计、有没有重复的轮子、某处逻辑完全不知所云是否增强语义或补充注释等。
5、开放？
如果公司有一定规模的话，除了组内的人 review，要不要开放给组外的人？code review 并不只是找问题，也是技术交流、学习提高的一种方式。我个人感觉这个很大程度上取决于团队整体的技术氛围，国内应该没有几家能做到吧
。 展开评论19
