软件开发团队管理经验收集

  1. Google极客谈软件开发团队不良行为的解决方法
    写一份明明白白的任务宗旨。这样可以随时保持专注,知道哪些是目标,哪些不是。
    E-mail讨论要有礼仪。保留归档,要求新人研读,防范那些“嘈杂的少数人”。
    所有历史都要有记录。这不单指代码历史,还有设计决策、重要的bug修复,以及过去犯下的错误。
    有效地进行协作。利用版本控制,代码改动要尽可能的小,方便进行审查,扩大“公车因子”,避免出现领地感。
    修复bug,测试,发布软件要有清晰的政策和流程。
    降低新人加入时的壁垒。
    依赖基于共识决策,在无法达成共识的时候也要准备好化解矛盾的方法。
    参考资料:http://www.infoq.com/cn/news/2013/03/google-geek
  2. Facebook元老王淮眼中的软件开发原则
    提交代码增量需要注意的事项:
    a、Bug修改,无所谓,该多大就多大。一般bug fix不会超过100行。超过的要特别重视,想想究竟是什么原因造成。会不会是当初设计的问题。一个diff,原则上不应该超过200-300行修改。但多了怎么办,把一个diff变成多个。
    每个diff应该只做一件事情。每个diff尽可少的做一个改动。这样可以尽可能的方便自己的管理(学会用git b、branch),和方便审阅者的代码审查。如果diff越集中做一件事,审查代码的人需要越短的时间来审查做出高质量的,整体效率越高。
    c、一个功能超过一屏,则将其分割。

    代码审查注意事项:
    a、作为审查者,一定要读懂diff;所有被接受的diff必须是在读懂的前提下。做审查者的人要有“将来如果这些代码线上出问题,我要帮助支持”的心理准备。
    b、代码审查应该被每个工程师当做工作的重要一部分。
    c、应当在24小时内给回复,这应当变成共识。
    d、感觉有问题的代码,一定要在相应的行上做出评论 (inline comments),以让作者明白问题所在。
    e、尽可能把对修改的所有意见一次性给出,减少来来回回的次数。比较复杂的建议审查者主动找代码作者来进行线下沟通,达成一致。
    f、一般的diff,来回次数不宜超过3次;如果超过3次,想想看,是不是diff 太大,太复杂了。

    thoughtbot公司最近在github上发布了自己的代码审查原则,其中几个值得关注的要点包括:
    接受这样的现实:很多编程上的主张都是一种个人观点。应该讨论它们的利与弊,提出你的倾向观点,迅速地达成一种解决方案。
    提问,而不是命令。(“把这个变量改成:user_id,你觉得如何?”)
    请求给予说明。(“我不明白。你能解释一下吗?”)
    避免代码的归属之争。(“我的”,“不是我的”,“你的”)
    避免使用一些会被认为是有关人身特征的词语。(“笨蛋”,“愚蠢”)要把所有人都看作是有魅力的、聪明的、善意的。
    要明确。要记着并不是每个人都能理解你的意图。
    要谦虚。(“我不能确定——我们来分析一下。”)
    不要用夸张修辞语。(“总是”,“从不”,“永远”,“毫无…”)
    不要讽刺。
    展现真实的你。如果你不是幽默型的人,不喜欢使用一些表情符号或动画gif图,不要勉强。如果你是这种人,请自信的发挥。
    如果有太多的“我不理解”或“另一种方案:”的评论,请专门针对这个人进行交流。可以把你们线下的交流总结成一个帖子附在后面。
    对审查者的建议表示感激。(“谢谢提醒。我会把它改正。”)
    理解审查是对事不对人。审查的是你的代码,而不是你。
    解释为什么代码写成这样。(“因为xxx原因我才写成这样。如果我把这个类/文件/方法/变量改个名会更清晰些吗?”)
    整理所作的改动,在以后的迭代中重构它们。
    在做修改的版本上注明代码审查的链接。
    push提交要基于最早的一轮反馈,并形成一个独立的分支。等这个分支上的任务完全完成了再合并。这让审查者能够根据早先的反馈找到你的单独的更新。
    努力站在审查者的立场上理解。
    争取回复每个评论。
    直到最后一个人退出登录后再合并分支。
    直到持续集成测试(TDDium, TravisCI,等)告诉你这个分支的测试套件通过后再合并分支。
    参考资料:http://www.infoq.com/cn/news/2013/03/wh-principle

发表评论?

0 条评论。

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据