一、个人总结
1.在alpha 结束之后, 每位同学写一篇个人博客, 总结自己的alpha 过程;
经过本次alpha阶段的冲刺,首先学到了很多,收获了很多,同时也蛮辛苦的。其实我觉得作为组员我有很认真地去对待这次项目、这次冲刺,但是我的PM还是特别辛苦,几乎在冲刺阶段每晚都处于熬夜阶段,没有她就没有我们现在的项目,在这里表示感恩,我们的羽晴大佬!
冲刺阶段,我们会约个固定的时间一起做,大家互相分享自己学到的新知识(哈哈,我们都是小白),我觉得这个做法很好,有效率;因为往往一个人对待一件陌生的事情就会不想做,有了他们我才有了动力。算是度过了一个辛苦却又愉快的alpha阶段。
然后,我现在去了另一个小队了,要准备开始新的一阶段了,继续加油!
2.请用自我评价表:http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。
第一部分:硬的问题
第二部分:软的部分
保持高标准,不要受制于破窗理论(broken windows theory)。
当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候,不要想 “既然别人的代码已经这样了,我的代码也可以随便一点啦。”
**一直主动这样做 **主动解决问题。当看到不靠谱的设计,糟糕的代码的时候,不要想“可能别人会来管这个事情” ,或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了。
一直主动这样做经常给自己充电,身体训练是运动员生活的一部分,学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享(面对面的分享,写技术博客等)来确保自己真正掌握了新技术。
有时分享DRY (Don't Repeat Yourself)——别重复。在一个系统中,每一个知识点都应该有一个无异议的、正规的表现形式。
这要讲场合消除不相关模块之间的影响,在设计模块的时候,要让它们目标明确并单一,能独立存在,没有不明确的外部依赖。
想做,但是不知道怎么衡量效果通过快速原型来学习,快速原型的目的是学习,它的价值不在于代码,而在于你通过快速原型学到了什么。
从来没听说过设计要接近问题领域,在设计的时候,要接近你目标用户的语言和环境。
大概同意,但是怎么接近用户呢?估计任务所花费的时间,避免意外。在开始工作的时候,要做出时间和潜在影响的估计,并通告相关人士,避免最后关头意外发生。工作中要告知可能的时间变化,事后要总结。
一直主动这样做图形界面的工具有它的长处,但是不要忘了命令行工具也可以发挥很高的效率,特别是可以用脚本构建各种组合命令的时候。
正在学习命令行工具有很多代码编辑器,请把其中一个用得非常熟练。让编辑器可以实现自己的定制,可以用脚本驱动,用起来得心应手。
没有任何定制理解常用的设计模式,并知道择机而用。设计模式不错,更重要的是知道它的目的是什么,什么时候用,什么时候不用。
从来没听说过代码版本管理工具是你代码的保障,重要的代码一定要有代码版本管理。
经常用在debug的时候,不要惊慌,想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具,善于分析日志(log),从中找到bug。同时,在自己的代码里面加 log.
只会printf重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事,不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设,你认为不可能发生的事情在现实世界中往往会发生。
从来没听说过只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常,会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。
一直主动这样做善始善终。如果某个函数申请了空间或其他资源,这个函数负责释放这些资源。
一直主动这样做当你的软件有多种技术结合在一起的时候,要采用松耦合的配置模式,而不是要把所有代码都混到一起。
从来没听说过把常用模块的功能打造成独立的服务,通过良好的界面 (API) 来调用不同的服务。
一直主动这样做在设计中考虑对并行的支持,这样你的API 设计会比较容易扩展。
考虑在适当的层次支持并行在设计中把展现模块 (View) 和实体模块 (Model) 分开,这样你的设计会更有灵活性。
没搞清楚啥是V,啥是M重视算法的效率,在开始写之前就要估计好算法的效率是哪一个数量级上的(big-O)。
我的数据量不大,无所谓在实际的运行场景中测试你的算法,不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序,数据是否支持多语言)会导致算法效率的巨大变化。
想用,但不知道工具经常重构代码,同时注意要解决问题的根源。
一直主动这样做在开始设计的时候就要考虑如何测试 ,如果代码出了问题,有log 来辅助debug 么? 尽早测试,经常测试,争取实现自动化测试,争取每一个构建的版本都能有某些自动测试。
项目没有安排时间,我也没有提这事代码生成工具可以生成一堆一堆的代码,在正式使用它们之前,要确保你能理解它们,并且必要的时候能debug 这些代码。
一直主动这样做和一个实际的用户一起使用软件,获得第一手反馈。
一直主动这样做在自动测试的时候,要有意引地入bug,来保证自动测试的确能捕获这些错误。
如果有明确要求,我可以做好如果测试没有做完,那么开发也没有做完。
签入代码,就是做完了适当地追求代码覆盖率:每一行的代码都覆盖了,但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。
一直主动这样做如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。
一直主动这样做测试:多走一步,多考虑一层。如果程序运行了一星期不退出,如果用户的屏幕分辨率再提高一个档次,这个程序会出什么可能的错误?
一直主动这样做
二、回答问题
我们在课程开始之初,曾经要求大家针对软件工程提出问题:个人阅读作业2,那么在经过alpha阶段,大家是否对软件工程有了一定的了解?请结合自己提出的问题进行回答
个人阅读作业2
问题一:要成为领域的专家,才能创新。
关于我的问题,为什么诺基亚没有再次成功;当时的诺基亚虽然做出了各种补救,但唯一没有的就是创新,过久地留恋不合时宜的塞班系统,未能及时推出换代产品而延误了战机,从而给竞争对手创造了赶超自己的机会,为自身发展留下了后患。
问题四:关于单元测试一定要本人写?
我现在想想还是觉得不一定非要本人写,因为在团队一起工作时,我写的部分的测试就不是我写的,感觉也没什么问题。
问题五:为什么要结对编程?
关于这个问题,之前不理解是因为觉得大三下很忙没时间;现在做了之后又觉得结对挺好的,遇到困难,有个人一起商量,解决;可能会有摩擦,但我觉得利大于弊,真的挺不错的。
三、再提问题
同时,大家一定会在实践过程中产生更多问题, 结合你的读书(教材,博客,参考书), 实践, 再提出关于软件工程的 5 个问题。
问题一:为什么一定要踢人出团队?
这点我是真的很不理解,说是模拟企业里换人,但是如果我们的团队就是很好很团结很nice,为什么一定要换呢?!
问题二:当你做PM的时候,如何兼顾自己手中的工作,怎么平衡自己的工作量?
P177
PM做开发和测试之外的所有事情
对于我们这次团队,我们的PM开发是很厉害的,其他人比较弱一些,如果PM不做开发和测试,可能我们都无法完成alpha阶段冲刺;但如果又做开发,又兼顾整个团队,PM也太累了,我们PM alpha阶段一直熬夜,太累了,他做后端,有时候想帮忙,反而会更耽误他时间,因为不了解还要去问他等等。
问题三:怎么要在一定的时间内,完成自己想要的任务量?
之前学长说,在软工上一天两个小时就很够了;但对于我们这次做的微信记账小程序,我是从来没接触过的,都是要重新学习,感觉写了几篇博客就开始了alpha冲刺,我有点冲不起来,完全做不到一天两小时就可以完成冲刺,连五一假期都在赶之前没做完的,有点难以在一定的时间内完成相应的任务。
问题四:如果项目中的基本功能或者杀手功能在项目快要结束了还差一部分才能完成,也要砍掉吗?
P312
有一个模块看来不能实现预期的设计需求,时间快到了,怎么办?
砍
这个我觉得不能那么绝对吧,对于我们这种基础不太好的团队,准备打算实现的功能本来就不多,如果因为没做完就砍掉功能,那可能最后也么啥功能了。
问题五:最后一个问题是关于博客,博客量是否过多?
在前期大家完全不懂这个项目的时候,迫切需要学习的时候,加上平时其他课程的任务,还要花大量时间去完成博客;在开发过程中的时候,每天忙着代码,设计等等,还要再去完成博客;开发结束了,还在写博客。心累,自从大二开始了博客这个东西,就一直在写博客了。
软工个人作业4——Alpha阶段个人总结的更多相关文章
-
网络软工个人作业4——Alpha阶段个人总结
1.个人总结 (1) 类型 具体技能和面试问题 现在的回答 毕业时找工作 语言 拿手的语言 Java 软件实现 有没有在别人的代码基础上进行改进,你是怎么读懂别人的代码,你采取什么方法不影响原来的功能 ...
-
[软工*理解组] Alpha阶段测试报告
[软工*理解组] Alpha阶段测试报告 在测试过程中发现了多少Bug? 测试阶段发现并已修复的bug: 尚且存在,但是难以解决或者不影响使用的bug: 计算重修课程的时候,如果重修课程的课程号和原 ...
-
[软工*理解组] Alpha阶段项目展示
目录 团队成员 软件介绍 项目简介 预期典型用户 功能描述 预期目标用户数 用户反馈 团队管理 分工协作 项目管理 取舍平衡 代码管理 程序测试 代码规范 文档撰写 继续开发指导性 用户沟通 需求分析 ...
-
[软工*理解组] Alpha阶段事后分析
目录 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 质量提高 会议截图 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰 ...
-
[软工*理解组] Alpha阶段团队贡献分评分
评分总表 下述表格适用于前端.后端.爬虫开发者的评分,基础分数为50分,在此基础上进行增减. 类别 程度 加减分 准时性 提前完成 +0 按时完成 +0 延后完成,迟交时间一天内或未延误进度 -2 延 ...
-
[福大软工] Z班 团队Alpha阶段成绩汇总
团队成绩汇总表 团队 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 总分 Dipper 9 85 90 26 42 27.5 120 74 25 111 19 628.5 SW ...
-
软工网络15个人作业4——alpha阶段个人总结
软工网络15个人作业4--alpha阶段个人总结 一.个人总结 用自我评价表:http://www.cnblogs.com/xinz/p/3852177.html 总结Alpha冲刺过程. 由于直接用 ...
-
软工网络15团队作业4——Alpha阶段敏捷冲刺1.0
软工网络15团队作业4--Alpha阶段敏捷冲刺1.0 1. 各个成员在 Alpha 阶段认领的任务,以及整个项目预期的任务量(使用整数表示,与项目预估的总工作小时数一致.比如项目A预估需120小时才 ...
-
软工网络15团队作业4——Alpha阶段敏捷冲刺2.0
软工网络15团队作业4--Alpha阶段敏捷冲刺2.0 1.提供当天站立式会议照片一张. 2.每个人的工作 成员 昨天已完成 今天计划完成 郭炜埕 熟悉微信web开发者工具 完成新建话题界面的设计 郑 ...
随机推荐
-
手机APP功能测试经验分享2016.06.06
1.登录时,Android和IOS同样的操作,提示信息不一致: 2.注册等页面切换成横屏容易不兼容.把内存卡去掉,再发送图片.音频.视频容易出错. 3.Android和IOS同样的功能,同样的原型图, ...
-
iOS: FFMpeg编译和使用问题总结
iOS: FFmpeg编译和使用问题总结 折磨了我近一周多时间的FFmpeg库编译问题终于解决了,必须得把这一段时间来遇到过的坑全写出来.如果急着解决问题,编译最新版本的FFmpeg库请直接看第二部分 ...
-
【转】IOS NSTimer 定时器用法总结
原文网址:http://my.oschina.net/u/2340880/blog/398598 NSTimer在IOS开发中会经常用到,尤其是小型游戏,然而对于初学者时常会注意不到其中的内存释放问题 ...
-
性能瞬间飙升!教你如何组RAID0磁盘阵列
性能瞬间飙升!教你如何组RAID0磁盘阵列 1组建RAID0磁盘阵列之Intel篇回顶部 前言:传统硬盘由于工作原理的限制,在性能上的提升非常缓慢.而固态硬盘价格昂贵,短时间内难以被普通用户接受.因此 ...
-
我为什么坚持DBA一定要懂开发
我为什么坚持DBA一定要懂开发时间 2016-03-23 15:34:08 张碧池的幸福生活原文 http://pottievil.com/我为什么坚持dba一定要懂开发/主题 DBA 数据库最近手头 ...
-
LinkCode 整数排序II
http://www.lintcode.com/zh-cn/problem/sort-integers-ii/ 题目 给一组整数,按照升序排序.使用归并排序,快速排序,堆排序或者任何其他 O(n lo ...
-
《Pro SQL Server Internals, 2nd edition》15w
第三章 统计 SQL Server查询优化器在为查询选择执行计划时使用基于成本的模型.它估计不同执行计划的成本,并选择成本最低的一个.但是,请记住,SQL Server并不搜索可用于查询的最佳执行计划 ...
-
Android Notification通知栏的使用,通知栏在Android8.0系统不显示的问题;
1.正常使用通知栏: /** * 创建通知栏管理工具 */ NotificationManager notificationManager = (NotificationManager) getSys ...
-
.NET 类库研究必备参考 添加微软企业库源码
前不久,为大家提供了一个.NET 类库参考源码的网站,扣丁格鲁(谐音“coding guru”),使用了段时间,发现一些不方便的地方,特意做了一些更改,希望大家多提意见,下面是此次更改的地方. 更改1 ...
-
hdu 4544 优先队列+贪心
题意:最近,减肥失败的湫湫为发泄心中郁闷,在玩一个消灭免子的游戏.游戏规则很简单,用箭杀死免子即可.箭是一种消耗品,已知有M种不同类型的箭可以选择,并且每种箭都会对兔子造成伤害,对应的伤害值分别为Di ...