bug终结者 团队作业第一周
小组组员及人员分工
小组成员
- 组长：
- 20162323 周楠
- 组员：
- 20162302 杨京典
- 20162322 朱娅霖
- 20162327 王旌含
- 20162328 蔡文琛
- 20162329 张旭升
人员初步分工（今后可能会根据具体工作进行调整）
Program Manager
周楠
是团队的行政领导，带领大家在项目中工作，学习
负责开发/测试之外的一些事务和项目进度的管理
利用人脉，对小组成果进行后期宣传，推广
小组博客的撰写者
Project Manager
朱娅霖
负责绝对客观公正地对各组员的工作进行考核
负责开发/测试之外的一些事务和项目进度的管理
小组博客的主要撰写者
张旭升
负责具体代码实现
推动全组同学学习，教会大家写代码
杨京典
负责具体代码实现
推动全组同学学习，教会大家写代码
王旌含
前期负责提供思路及大致方向
中期协助写代码
在后期进行测试，寻找bug，提出不足及改进方案
蔡文琛
前期负责提供思路及大致方向
中期协助写代码
在后期进行测试，寻找bug，提出不足及改进方案
《构建之法》阅读
1. 概论
- 1.1 软件 = 程序 + 软件工程
- 一个复杂的软件不但要有合理的软件架构、软件设计与实现，还要有各种文件和数据来你、描述各个程序文件之间的依赖关系、编译参数、链接参数等等。这些都是软件构建的过程。
- 源代码管理，配置管理，质量保障，软件测试，需求分析，软件维护，用户体验
- 1.2 软件工程是什么
- 软件的特殊性。复杂性，不可见性，易变性，服从性，非连续性
- 软件工程与计算机科学联系紧密，但软件工程更注重实践、应用，计算机科学更注重理论研究。
- 软件工程的目标——用户满意的，可靠的，流程质量高的，可维护的
2. 个人技术和流程
-
2.1 单元测试
- VSTS
- 单元测试应该在最基本的功能、参数上验证程序的正确性
- 单元测试必须由最熟悉代码的人来写
- 单元测试应该覆盖所有代码路径 那么我们该如何确认单元测试是否覆盖所有路径了呢？
- 回归测试
-
2.2 效能分析工具
- 抽样
- 代码注入
-
2.3 个人开发流程
- PSP(Personal Software Process)
- 多花时间在需求分析和测试上面
-
2.4 实践
- 单一职责原则
- WC项目
3. 软件工程师的成长
- 3.1 个人能力的衡量与发展
- 3.2 软件工程师的思维误区
- 分析麻痹
- 不分主次，想解决所有依赖问题
- 过早优化
- 过早扩大化、泛化
- 画扇面
- 3.3 软件工程师的职业发展
- 3.4 技能的反面
4. 两人合作
-
4.1 代码规范
-
4.2 代码风格规范
- 缩进、行宽、括号、{ }、分行、命名、下划线、大小写、注释
-
4.3 代码实际规范
- 函数
- goto 什么是goto?
- 错误处理：参数处理，断言
-
4.4 代码复审
- 自我复审
- 同伴复审
- 团队复审
-
4.5 结对编程
- 极限编程
-
4.6 两人合作的不同阶段和技巧
- 正确给予反馈
5 团队和流程
- 5.1 非团队和团队
- 5.2 软件团队的模式
- 5.3 开发流程
6 敏捷流程
- 6.1 敏捷的流程简介
- 6.2 敏捷流程的问题和解法
- 6.3 敏捷的团队
- 6.4 敏捷总结
- 6.5 敏捷的问答
7. 实战中的软件工程
- 7.1 MSF简史
- 7.2 MSF基本原则
- 7.3 MSF团队模型
- 7.4 MSF过程模型
- 7.5 实战中的软件工程
8. 需求分析
- 8.1 软件需求
- 8.2 软件产品的利益相关者
- 8.3 获取用户需求——用户调研
- 8.4 竞争性需求分析
- 8.5 功能的定位和优先级
- 8.6 计划和估计
- 8.7 分而治之
9. 项目经理
- 9.1 PM是啥
- 9.2 微软PM的来历
- 9.3 PM做开发和测试之外的所有事情
- 9.4 领导力——高效的团队讨论
- 9.5 PM和风险管理
10. 典型用户和场景
- 10.1 典型用户和典型场景
- 10.2 用例
- 10.3 规格说明书
- 10.4 功能驱动的设计
11. 软件设计与实现
- 11.1 分析和设计方法
- 11.2 图形建模和分析方法
- 11.3 其它设计方法
- 11.4 从Spec到实现
- 11.5 开发中的源代码管理
- 11.6 实战中的源代码管理
- 11.7 代码完成
12. 用户体验
- 12.1 用户体验的要素
- 12.2 用户体验设计的步骤和目标
- 12.3 评价标准
- 12.4 贯穿多种设备的用户体验
13. 软件测试
- 13.1 基本名词解释及分类
- 13.2 各种测试方法
- 13.3 实战中的测试
- 13.4 运用测试工具
14. 质量保障
- 14.1 软件的质量
- 14.2 软件的质量保障工作
15. 稳定的发布阶段
- 15.1 从代码完成到发布
- 15.2 不同频率和不同覆盖范围的渐近分布
- 15.3 发布之后——事后诸葛亮会议
16. IT行业的创新
- 16.1 创新的迷思
- 16.2 创新的时机
- 16.3 创新的招数
- 16.4 魔方的创新
- 16.5 创新和作坊
17. 人，绩效和职业道德
- 17.1 领导力
- 17.2 领导力——知人善任
- 17.3 领导力——带领团队成长
- 17.4 猪、鸡和鹦鹉的故事
- 17.5 其实还是人的问题
- 17.6 绩效管理
- 17.7 萝卜与白菜
- 17.8 软件工程师的职业道德
提出问题
-
问题1: 成为一个好的程序员需具备哪些条件与素养？
-
问题2：没有多少项目经验，基础又不是很好的话，该怎样提高自己的能力，该如何调整自己呢？
-
问题3：在结对编程中，如何才能更好地分配两个人的工作？如果由于某些原因，你的同伴未能完成相应的任务，可是这个任务必须马上要提交，这时候该怎么做？
-
问题4：做软件测试必须有哪些的知识储备？
-
问题5：100%的代码覆盖率并不等同100%的正确性，那么要怎么样才能保证100%的正确性？
-
问题6:软件质量的保证涉及太多方面，哪一方面是最重要的？哪一方面是最容易出纰漏的？
王旌含：对于我们团队的模式来说，我认为我们现在处于业余团队模式，或者更像是明星模式，而最优的模式当然是功能团队模式，这个模式将沟通、协作的作用发挥到了极致。在我们团队的萌芽期，我们应该如何摆脱懒散、打酱油的情况？如何能向功能团队的模式进发。是团队当前所面对的最大的难题。
秘密团队模式和一窝蜂团队模式都具有很大的自由度，为什么秘密团队模式却有效的多？
书中提到了过早优化的问题，那么如果编写的程序过大，等到编写完的时候再优化是不是会很繁琐？
如何能有效的确定优化和泛化的时机，是软件的优化达到最佳效果？
蔡文琛：JAVA开发流程设计和前期框架构建的重要性。程序开发团队应该如何组织？在使用程序时，用户是否需要详细的使用方法，为什么？对于用户的短期刺激和长期影响，哪个更有参考性？程序开发是否需要设计者的感情设计？