bug终结者 团队作业第一周

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开发流程设计和前期框架构建的重要性。程序开发团队应该如何组织?在使用程序时,用户是否需要详细的使用方法,为什么?对于用户的短期刺激和长期影响,哪个更有参考性?程序开发是否需要设计者的感情设计?

原文地址:https://www.cnblogs.com/1623bugkiller/p/7617567.html