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