78
社区成员




项目 | 内容 |
---|---|
这个作业属于哪个课程 | 课程社区 |
这个作业的要求在哪里 | 作业要求 |
我在这个课程的目标是 | 积累软工经验,进行软工方法论实践,提高工程能力 |
这个作业在哪个具体方面帮助我实现目标 | 了解软件工程基础概念及其方法论 |
条目 | 内容 |
---|---|
位置 | 3.2 软件工程师的思维误区 |
疑问 | 如何合理运用抽象避免过早扩大化/泛化?是否有可以量化/具体化的标准? |
类型 | 不能回答的问题 |
本书 3.2 软件工程师的思维误区 下面的段落:
过早扩大化/泛化:软件的“软”还表现在它可以扩展。在写一个程序的时候,需要某个函数可以处理整数类型和字符串类型的信息,有的程序员往往灵光闪现——哎,能不能把类型抽象出来,让这个函数处理所有可能的类型?这样不就一劳永逸了么?有些软件本来是解决一个特定环境下的具体问题,有的程序员一想,我们能不能做一个平台,处理所有类似的问题,这样多好啊!
而《代码大全》里面也提到了一个设计概念“松散耦合”(通过应用类接口中的合理抽象、封装性及信息隐藏等原则设计出相互关联尽可能最少的类)。那么作为一个软工经验有限的程序员,我该如何保证我的代码抽象是在一个合理的层次上?是否有可以量化/具体化的标准?
条目 | 内容 |
---|---|
位置 | 4.1代码规范 |
疑问 | 如何保证语义有关的代码是符合代码规范? |
类型 | 不能回答的问题 |
计算机只关心编译生成的机器码,你的程序采用哪种缩进风格,变量名有无统一的规范等,与机器码的执行无关。但是,做一个有商业价值的项目,或者在团队里工作,代码规范相当重要。
例如谷歌的代码规范,虽然一些缩进、命名方式可以通过一些自动化方法进行测试(例如checkstyle),但是如何保证语义有关的代码是符合代码规范的?(例如一些代码规范中循环变量,很多代码规范要求运用更具体的变量名而不是i、j这种进行命名;又或者一些成员变量要求加上m_前缀)
而如果人工来检查这种类型的代码规范又是否过于麻烦?
条目 | 内容 |
---|---|
位置 | 8.5 功能的定位和优先级 |
疑问 | 如何看清自己的团体在功能分析的象限? |
类型 | 不能回答的问题 |
本章中根据 杀手功能( Core ) / 外围功能( Context )和必要需求( Mission Critical ) / 辅助需求 (Enabling ) 提出了功能分析的四个象限:
但是如果对于一个较为复杂完善的软工项目(兼具上述四种特质),如何确定自己在哪个象限?对于这种项目是否四个象限的建议均可以并行进行,还是优先于进行某个象限的方向?这样一来四个象限是否有优先级/等级上的差距?
条目 | 内容 |
---|---|
位置 | 13.2 各种测试方法 |
疑问 | 不同测试方法之间是否有优先级差距? |
类型 | 不能回答的问题 |
本章介绍了软工设计常用的很多测试方法,包括单元测试、代码覆盖率测试、构造验证测试、验收测试、“探索式”测试、回归测试、场景 / 集成 / 系统测试、伙伴测试、效能测试、压力测试、内部 / 外部公开测试、易用性测试、Bug Bash。
不过当时间有限时,显然使用上述所有方法开展充分测试是不可能的,那么是否应该优先某些测试(例如单元测试)暂时不使用其他测试?例如下图(本书14.2.2 和测试角色相关的问题)提到的测试是否在一般的开发过程中使用的次数明显高于其他测试方法?
条目 | 内容 |
---|---|
位置 | 17.6 绩效管理 |
疑问 | 对于一个学生软工项目,是否有较好的绩效评价实践? |
类型 | 不能回答的问题 |
在软件团队中, 不合理的绩效考核不但影响各人的收人, 而且会影响人员的士气 、 流动 、 后续
的合作以及产品质量, 不能不慎重。
既然绩效评价如此重要,那么是否有对学生软工项目进行绩效评价的良好实践吗?就我目前参加过项目经历而言,作为队长,很多时候很难量化一个队员的绩效,例如一个人虽然效率低贡献量有限,但是他非常努力花费了其他队员两倍的时间工作;又或者某个人进行了某种尝试,花费了很长时间,但最后方案没被我们接受。作为队长,这种很难用代码量任务量直接评价的客观因素怎样加入到绩效的考评中?
而作为队员,有时也会对最后项目的贡献度分配表达不满:我完成了比他人更多的工作却换算成相同的贡献度。这种情况如何安抚队员情绪呢?
书中提到了很多的绩效分配实践,但是个人感觉对于一个7人的软工小组中这些概念还是比较模糊,那么是否有更好更具体的方法呢?
对于Q5。绩效分配本身就是一个模糊的概念,什么是绩效?绩效的分配决定了什么?是工资还是升职还是加分?组内有没有特殊人群?组里有小情侣怎么办?有的时候我们甚至不能确定是由组内成员来决定如何进行绩效分配,还是绩效分配的方式决定了谁是成员,比如一个不满意绩效分配的人很有可能会离开这个组,而留下的人则逐渐适应。
对于不同的团队,绩效分配方式是会有极大差异的,这与组内成员极大相关。我并不清楚你们组内成员,因此无法给出很具体的建议。