第一章随笔&&思考题

　　《构建之法》已经到手了，但是还没开始看，只翻看了前几页，和传统的教材区别很大，没有大篇幅的理论，比教材看起来有意思。第一章中还提到了‘bug’的由来，第一次听说，感觉挺有意思。

　　第一周上课老师提问什么是软件，同学们认为软件就是程序，我也是这么想的。但是为什么他要叫软件，而不叫程序呢？对于程序，比较通用的定义是：程序=算法+数据结构。但是算法和数据结构组合起来能构成软件吗？答案是不够的。所以《软件工程概论》中，将软件定义为程序、数据及其相关文档的完整集合（软件=程序+数据+文档）。程序可以没有输入数据，可以没有文档，但是软件不行。软件是要根据用户的输入需求，进行计算，将结果反馈给用户，所以软件要由数据组成。同时，软件需要维护，如果没有文档记录，这样的软件一定不能长久存活。随着软件越做越大，代码越来越来，没有文档辅助解释，对于后续的软件工程师来说，很难理解之前的程序，也就很难进行维护完善。在《构建之法》的开篇，同样给了软件的定义，这本书中将软件定义为：软件=程序+软件工程。通过两个概念的对比，我们可以推出一个结论就是：软件工程=数据+文档。如果就是这样的话，那么两个定义就没什么区别。软件工程又是什么呢？书中也做了介绍，软件工程的核心部分是构建管理、源代码管理、软件设计、项目管理等这些和软件开发活动相关的内容。仔细想想，这些内容从某种意义可以说是数据和开发文档的组合，所以两本书中关于软件的定义实际上是没有什么区别的。

 

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\分割线\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

关于如何衡量个人在团队的绩效

 

首先想到的肯定是谁做的部分多、难，谁的分高。但是接下来的问题也很多

1.如何定义每个人的工作量或者效率

如果单纯的以工作时间以及代码行数来作为衡量标准，那么会造成程序员故意把程序写的复杂冗长。本来只需要3条指令可以完成的事，为了增加代码长度，可以增加到10条、20条，但是这对整个项目来说不仅是没有好处，还会带来危害。代码是越短越好的，那我们是不是可以根据谁的代码短来评价成员的工作呢？这也是不行的，首先，组内每个成员的分到的任务就是不一样的，有点任务比较复杂，有点比较简单。那么对应的代码肯定不一样的。而且如果特意减少代码，很有可能会有潜在的bug。我觉得这部分不能很好的定义，所以我的策略是不考虑这一部分。

2.关于工作时间

显然，工作时间也不是越长越好的。所以我的策略是，规定好每个成员的工作时间，对于缺勤并且没完成任务的进行处罚，对工作时间超过个人计划的时间，不进行惩罚，也不鼓励，只要按时完成分配给他的任务就行了。

3.关于工作难度

谁解决关键问题，应该获得更多的得分。但是，分配给每个人的任务不一样。如果为了得到这部分的成绩，那么每个人都会要求做最难的部分，谁去做简单的任务呢？而且，也不是每个人都能解决得了。所以，对于这一部分，我的想法是每个组员的成绩都一样，组长根据小组项目的成绩比组员多一点分数。

最后，我的结论是：个人成绩=小组成绩+组长加分+未完成任务扣分

转载于:https://www.cnblogs.com/13070016-vic/p/5246047.html