做事
- 指责不能修复bug---Blame dosn't fix bugs.
- 把精力放在解决问题上,而不是抱怨和指责.
- 过程符合标准并不意味着结果是正确的.
- 在团队中,勇于承认自己不知道答案,这会让人放心.
- "这不是我的错",这句话不对."这都是你的错",这句话更不对!
- 如果你没犯过任何错误,说明你可能没有努力去工作.
- 如果团队中的一个成员的行为一再伤害了团队,则他表现的很不职业.
欲速则不达
- 防微杜渐---Be ware of land mines.
- 不要坠入快速的简单修复之中.要投入时间和经精力保持代码的整洁,敞亮.
- 一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽池,最终会吞噬整个项目的生命.
- 你需要了解团队的开发方法或开发过程.
- 如果团队成员花些时间阅读其他成员的代码,他们就能保证代码是可阅读和可理解的.
- 代码复审是发现bug的最有效的方法之一.
- 单元测试是防止代码难懂的重要技术.
- 你必须要理解一块代码的是如何工作的,但不是一定需要成为专家.
- 不要急于修复一段没能真正理解的代码.
- 所有的大型系统都非常复杂,没有一个人可以完全明白所有的代码.
对事不对人
- 消极扼杀创新---Negativity kills innovation.
- 整个团队应该关注真正有价值的问题,而不是勾心斗角,误入歧途.
- 你必须把重点放在解决问题上,而不是极力证明谁的注意更好.
- 你不需要出色才能起步,但是你必须起步才能出色.
- 如果你是一个有远见的人,就一定要特别尊重别人的意见.
- 你是一个掌舵者,一定要把握方向,深思熟虑,吸取各方意见.
- 关于决策:设定最终期限,逆向思维,设立仲裁人,支持已经做出的决定
- 尽力贡献自己的好想法,如果你的想法没有采纳也无需生气.
- 脱离实际的反方观点会使争论变味.不带个人情绪并不是盲目接受所有的观点.
排除万难,奋勇向前
- 动手证明是最有效的方式,把糟糕的代码放到一边,立刻重写.
- 当发现问题时,不要视图掩盖这些问题.
- 如果设计或代码中出现了奇怪的问题,花时间去理解为什么代码会是这样.
- 如果你找到解决的办法,但代码仍旧令人费解,唯一的解决办法是重构代码,让他可读性更强.
- 如果你没有马上理解那段代码,不要轻易地否定和重写他们.
- 如果你说天快要塌下来了,但是团队成员都不赞同.反思一下,也许是你是正确的但你没有说清楚自己的理由.
- 如果你说天快要塌下来了,但是团队成员都不赞同.认真考虑下,他们也许是对的.
