OMOOC.py week7 QA

记要

~大妈的团队协作介绍

  1. 本周最关键的问题: 持续编程,累觉不爱?
    • 某些组反复戳, 但最后代码仓库没变化
    • 究其原因并不是大家技术不够, 而是胆子不够.
      • 每个人对于团队的信任还不够. (并不是对自己代码的信心不足)
      • 先协作起来, 才能谈得上协作的优化
      • 类比小时候的群体野炊中, 无间的协作
    • 软件工程可以类比的两类工程行为:
      • 电影摄制组, 厨房
        • 高度协同+资源要求苛刻+出品质量高
      • 厨房: 吃饭是强需求; 同时不能等时间太长;
        • 有限时间, 有限资源, 自己有限的能力 — 与每周提交迭代版本十分相似
        • 利用现有的资源乱炖, 通常也不会太差
    • 两个月的学习后, 我们现有的经验和知识已经足够大家完成原创作品了.
  2. 怎么让代码一步一步变得越来越有用,越来越强大
    • 自己踩着自己的脚上天 — 每个小伙伴的任何一个想法, 任何一行代码都立刻让所有人知道
    • 这种所谓的开发模式大家本身很熟悉,
    • 但为什么换了一个环境, 到了团队协作的编程中, 大家就不会使用了呢?
    • 原因是代码没有运行起来, 因而没法进行迭代优化
      • 本地开发环境不同
  3. 为什么代码没有运行起来, 如何改变?
    • 少了一个核心可运行的原型
    • 第一个版本非常重要
      • 实例: 大部分开源项目, 第一个版本已经完成了80%以上的功能的实现
    • 那么问题来了, 这么牛叉的第一个原型谁写?
      • 很显然, 项目发起人应该来写
      • 在大家进行协作时, 发起人应给出一个能让大家理解项目内容的非常坚实的原型出来.
      • 即 MVP: minimal valuable product
    • 目前的现象: 组长们在呼唤/推进大家"协作"时, 自己没有写代码
      • 以极高热情协同大家, 但是大家依然无法(用事实 — 代码运行)感知: 我们到底要做什么
      • 基于代码的有效性讨论(show me the code) — 变成一种务虚的纸面上讨论(talk is cheap)
    • 如何阻止这种只讨论, 不写代码的循环发生?
      • 方案1: 一个人写出80%的原型, 然后共同优化
      • 方案2: 每个人都写 MVP, 然后进行代码 PK
        • 在最短的时间内产生最多的代码
        • 进行 pk, 形成主线代码
        • 随后大家对此进行维护
  4. 一切协作姿势, 都要在代码仓库活跃起来之后才有意义
    • 一个基于事实的基本判断方法: 每天到底进行了多少代码更新? 多少个推送版本? 加减了多少行代码?
    • 一切协作姿势, 是为了完成作品
    • 如何远程协同
      • 一种有人使用的方法: facetime/skype 远程实时同步大家的状态, 有问题随时询问讨论
      • 创造一种大家一起写代码的气氛
  5. [乱入]代码仓库 README 与 wiki
    • README: 这是什么作品, 需要依赖的运行环境 — 与代码的运行直接相关(用户视角)
    • wiki: 团队计划, 讨论, 资源等 — 与生产代码没有直接关系(团队视角)
Author: Zoom.Quiet /mail / gittip / github