3月18日作业重点及点评
教师本想偷懒一下,奈何有人催逼前行啊。
谢谢冉华同学迅速更新。
0. 重要 预习要求
0.1 学习scrum案例
[http://www.cnblogs.com/Chronos/p/5030912.html]
[http://www.cnblogs.com/bugphobia/p/5047025.html]
0.2 预习 四象限
0.3 学习 [https://en.wikipedia.org/wiki/Minimum_viable_product]
选择一个功能,先写出可执行的代码。
部分作业截止
到截止期3月24日24:00,收到作业及站立会议报告34份。
请继续提交每日站立会议报告,本周要求5个工作日。
请往下面看,作业缺项的同学注意 你需要一份 check list,本周要交的作业内容。
互评
请各位同学开始互评吧,不然到周五上课前,工作量巨大。
抢跑项目
选做加分项 在此贴下回复认领此项目,限前3位同学。3位同学分别做3个不同的版本。
吴军同学、齐嘉亮同学 认领完毕,还剩2个名额。
如果别人做完的自己就不用再做一次了,就少了一次进步的机会。实验和学习的目的,最主要的不是达成结果,而是过程。
把 [http://www.cnblogs.com/xinz/p/3852177.html] 的量表做成APP或网上调查问卷,并发布在微信朋友圈中。
可以借用现有调查问卷系统,自动核算得分,注意版本引用和致谢,注意排版美观。
齐嘉亮同学的样例 [http://www.sojump.com/m/7505837.aspx?from=groupmessage&isappinstalled=0],正在讨论选项的分值。
吴军同学的样例 [http://www.sojump.com/m/7505121.aspx?from=timeline&isappinstalled=0]。
4人小组
-
耐撕团队: 郑蕊组长,齐嘉亮,刘伟硕,濮成林,将完成抢答器。
-
OneZero团队: 夏一鸣组长,王巍,冉华,张敏,将完成记账本。
-
fantacy团队: 杨若鹏组长,郭又铭,臧润强,何美琪,将完成词频扩展。
-
爆打团队: 严一格组长,包玲玲,吴军,彭杨,将完成四则运算扩展。
每日站立会议
批评 21日,第一个工作日 以下团队未提交每天都应提交的站立会议更新: 耐撕团队、fantacy团队、暴打团队。
表扬 OneZero团队及时提交。
1. 作业点评
1.1 冉华 [http://www.cnblogs.com/ranh941/p/5291504.html]
词频统计 及 PSP。
由程序员成长为工程师的途中。
1.2 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5294329.html]
scrum的总结,非常精准。请各位同学前去围观。
1.3 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5293887.html]
与王巍的结对编程体会,值得一读。三周已过,我发现值得一读、值得一批、值得讨论的技术博客多起来了。祝贺各位的进步。
1.4 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5299256.html]
OneZero团队非正式站立会议。持续1小时,讨论需求、边界。三人参加,一个事后参与讨论。
OneZero团队的计划产品是 记账软件。
1.5 张敏 [http://www.cnblogs.com/zhangminss/p/5300136.html]
OneZero团队启动 报告。要点清晰。
1.6 郭又铭 [http://www.cnblogs.com/guoyouming/p/5300220.html]
个人能力提升训练;
fantacy团队 词频扩展 需求讨论。
1.7 郭又铭 [http://www.cnblogs.com/guoyouming/p/5300315.html]
词频扩展 的UI原型
1.8 王巍 [http://www.cnblogs.com/shirlywangwei/p/5301682.html]
结对体会。PSP,进度条。
1.9 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5301526.html]
OneZero第一次站立会议报告。可圈可点,下了功夫。
1.10 张敏 [http://www.cnblogs.com/zhangminss/p/5305748.html]
OneZero团队的站立会议刷屏中。
1.11 张敏 [http://www.cnblogs.com/zhangminss/p/5305892.html]
The Return of the Queen.
1.12 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5306397.html]
耐撕团队21日站立会议报告,22日更新。
团队中一人病倒,一个病着站立,但是团队还在。
高风险问题都已开始讨论,内容专业,值得细读。
1.13 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5306582.html]
OneZero 3月22日站立会议。注意到控制时间,并且控制得不错(似乎受到教师的启发以前就注意到了)。
高风险问题都已开始讨论。
1.14 濮成林 [http://www.cnblogs.com/charliePU/p/5307039.html]
词频需求等开始更新,结对体会颇深。
1.15 濮成林 [http://www.cnblogs.com/charliePU/p/5307620.html]
原创git安装教程。
总结经验教训,记笔记发博客(因此以后自己也容易找到),是以后提高的不二法门。
此文堪为典范,可以炫耀。
1.16 严一格 [http://www.cnblogs.com/yyyyg/p/5308384.html]
爆打团队站立会议,开始 四则运算扩展需求。
四则运算完全可能有巨大~~的下载量,加油 !
1.17 濮成林 [http://www.cnblogs.com/charliePU/p/5308510.html]
耐撕团队3月22日站立会议。
两位成员病倒,团队未倒。
UI原型值得一观。
1.18 包玲玲 [http://www.cnblogs.com/linglingbao/p/5308665.html]
结对,4个项目,PSP。
站立会议的独立报告,很好。对于同一个会议,大家会有不同的观点和角度。
如果别人做完的自己就不用再做一次了,就少了一次进步的机会。
1.19 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5309062.html]
结对,词频。赞刘伟硕和濮成林对结对的独立报道,都可圈可点。
1.20 郭又铭 [http://www.cnblogs.com/guoyouming/p/5309096.html]
Fantacy团队第一次站立会议,22日。赞在组长之外独立思考和报道。
请各位同学去围观我的点评,并回复各位的点评。对于“好”“学习了”跟“顶”一样没有营养,不算点评。
1.21 杨若鹏 [http://www.cnblogs.com/robinYangRP/p/5309109.html]
Fantacy团队第一次站立会议,22日。
请各位同学去围观我的点评,并回复各位的点评。
1.22 郭又铭 [http://www.cnblogs.com/guoyouming/p/5309232.html]
结对编程体会,对结对的负面评价。
1.23 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5310794.html]
读“软工实践总结作业”有感。这是杨贵福明确各位同学文字谈感想的作业,你完成的如何?
1.24 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5311784.html]
OneZero第三次站立会议(2016.3.23)。在继续需求,建议开始编程。各位同学的评论很积极。
1.25 彭杨 [http://www.cnblogs.com/pengy813/p/5312417.html]
结对编程体会不错。4人小组项目词频的需求和技术讨论。
1.26 彭杨 [http://www.cnblogs.com/pengy813/p/5312426.html]
KNN算法,聚类。技术积累。
1.27 吴军 [http://www.cnblogs.com/wujunzero/p/5312557.html]
爆打团队站立会议。选择了SCRUM工具。请立即开始编程。
1.28 郑蕊 [http://www.cnblogs.com/zhengrui0452/p/5312911.html]
开始第三周作业。快速迭代,先占位置,是正确策略。
1.29 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5313120.html]
”耐撕“团队 2016.3.23 站立会议。恢复为三名成员,郑蕊参加站立会议,齐嘉亮倒了。
1.30 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5313251.html]
漫长的PSP。
只要不病倒,持续努力。把玩的时间用来编程和进步。在我看来,这只是此前多少年逍遥自在的补课。我也是这样的,我还在补大一的离散数学和高中落下的英语。加油 !
夏一鸣 加油,赞努力。我用十多年追赶,欢迎你加入。
1.31 臧润强 [http://www.cnblogs.com/zangrunqiang/p/5313385.html]
结对,站立会议。虽然具体内容和感想还没有写,但是大纲已经有了。
1.32 严一格 [http://www.cnblogs.com/yyyyg/p/5313405.html]
作业大纲 及 PSP。
1.33 郭又铭 [http://www.cnblogs.com/guoyouming/p/5313526.html]
第一位回应NABCD模型的同学,有心人。请各位参见下文的3.4节。
1.34 郭又铭 [http://www.cnblogs.com/guoyouming/p/5313776.html]
PSP,积累进步的证据。
1.35 何美琪 [http://www.cnblogs.com/heyjoymq/p/5314096.html]
补交作业。欢迎归队,战士。
1.36 张敏 [2016.3.24 OneZero站立会议]
产品BACKLOG需求。期待本轮迭代的可执行代码。
1.37 濮成林 [http://www.cnblogs.com/charliePU/p/5317410.html]
耐撕团队站立会议 24日。数据流图。
1.38 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5316550.html]
OneZero站立会议。开发环境和架构选择。
1.39 郭又铭 [http://www.cnblogs.com/guoyouming/p/5317863.html]
需求分析 词频,根据《构建之法》第8章需求分析。
2. 作业重点
2.1 齐嘉亮同学的整理
2.2 请不要忘记
2.2.1 PSP 和 进度条 是每周都要求的
2.2.2 4人小组项目开题需求、站立会议每工作日更新。
2.2.3 技术博客应包括 scrum sprint, 需求、计划
补充要求1 站立会议每日更新要包括 burn down、甘特图,截图粘贴到技术博客中。
会出错不可怕,错误是正常应该出现的,错误帮助成长;最大的错误是为了防止犯错而退缩。
需求怎么写、站立会议应该包括什么,甚至需求和站立会议是什么,其中的细节杨贵福是不会讲的。
凡是课本或网上你容易找到的东西,都不会在课堂上讲,这是对您身为硕士研究生的尊重。祝贺你有机会获得尊重。
补充要求2 本周的迭代,不仅应有总体需求和计划,应包括架构的 代码实现,参见 RUP 的 architecture-centered。
2.2.3 词频/四则运算 的代码改进 是每周都要求的,缺需求spec的请补上。要求结对进行。
当你终于发现需求spec的价值的时候,词频/四则运算就由编程大作业演进为了项目。
重申参考 用户需求及spec: 四则运算 [http://www.cnblogs.com/jiel/p/4810756.html]
这条线索不要求 burn down 和 甘特图。
2.2.4 重申部分
- 文字给出的感想呢?
邹欣老师指出:
这的确是一个要点。 建议让同学们看看以前学生的总结:
http://www.cnblogs.com/malinlin/p/5058509.html
各位同学,读完什么感想,请文字给出。
请不要说“老师你记性真好”,我只是重新又读了一遍。你也能做到,请从此刻开始,养成严谨的习惯,不要等到这个习惯养成再去工作。
-
你欠邹欣老师和杨贵福的回答
-
互评。
已作为惩罚性作业,要求评论所有人的所有技术博客。即使你评“没啥可评的”也是开启双向交流,毫无行动,就是放弃交流。
3. 预习和思考题
3.1 单元测试
幻飞龙博士的 极简单元测试示例
谢谢牛宝乐老师供应资料。
3.2 汉堡模型
结对或4人小组吵架的时候,请参考邹欣老师的汉堡模型
3.3 编程 vs. 工程
在课堂上,杨贵福提到 代码鉴赏力。那么,什么是 好的 代码,什么是 坏的 代码,代码之好坏是否可能因环境或需求的变化而变化?
什么是好的工程项目,什么是坏的工程项目,是否可能 代码很好但是由它形成的工程项目糟烂,是否可能 代码糟糕而形成的工程项目不错?
3.4 功能 vs. 用例
邹欣老师提到:
一个反馈: 看到大家列出很多想做的功能, 很好! 但是, 如果是一个公开发表的软件, 建议从用户的需求出发。 列出用户有什么痛点需要满足, 我们如何满足。 而不是从程序员的角度出发,罗列各种可能的功能点。
请看 http://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html
请特别注意最初选择的用例,要现实、可以按期完成。
第一周仅有可执行框架,也在可接受范围内。
3.5 来自工业现实的声音
“无效的昵称”说: (感谢 无效的昵称 先生)
在我们这里,基本上都是短平快。从需求提出到上线,时间短,而且今天确定是这个需求,明天做完了,后天需求变了。需求一般深度教浅,先上线再说,效果好就继续迭代。产品更新速度快,产品今天上去了,明天可能就死了。在这种环境里面,TDD开发,代码可读性,注释等问题一般写代码的人是不会关注的,只有读代码的人才去了解一下。一般代码都是先上线,上线看到有这个那个问题,然后就再迭代改进,改进一般都是在大的结构范围内,细节基本上没有,比如:A系统调用B系统,调用耗时较多,就会加个缓存,但A系统内部有没有文档,有没有单元测试,基本上很少关注。不过现在在开始重视单测,不对是开始重视自动化测试,减少人工嘛。另外我们这边对性能关注较多,性能测试一般是必须的,不过到了大促了有一个不好风气就是堆机器,大促完成后,看到机器多了,第二年就又是各种性能优化。
工程实践并不局限于经典教材中的标准答案。
请各位同学思考,这里哪些是软件工程经典教材里提到过的手段,如果在 质量、范围、时间、代价 间妥协?为什么实践中工程师会这样选择,你会如何选择,这些手段与经典教材中的理论矛盾么,为什么?
接下来的讨论在[http://www.cnblogs.com/younggift/p/5240521.html#3385640]。