| 项目 | 内容 |
|---|---|
| 作业归属课程 | https://www.cnblogs.com/nwnu-daizh/ |
| 作业要求 | https://www.cnblogs.com/nwnu-daizh/p/12369881.html |
| 我的学习目标 | （1）学习GitHub的基本操作； （2）通读《构建之法》，并提出3个有意义的问题； （3）学会使用Markdown |
| 参考文献 | [1]邹欣.构建之法——现代软件工程：现代软件工程[M].人民邮电出版社，2014 |
一、初步了解
上周经老师推荐得知《现代软件工程——构建之法》这本书，提及“软件工程”我便觉得这对于我来说无疑是很大的困难，我的编程能力并不强，但是软件工程在我的认知里就是需要将理论与实践相结合，而且更注重于实践，这对于实践能力不强的我，可以算是一个很大的挑战。上课的时候老师说这本书写的浅显易懂，大家可以以很放松的心态来读，仔细阅读之后发现确实如此。本书用一些贴近实际的语言和例子，塑造了不同的鲜活人物形象，通过例子给我们阐述软件工程的基本理论知识，从不同方面诠释所谓“构建之法”
二、三个问题
1.问题一：什么是足够好的软件：
问题描述：在阅读书P15的时候读到一个问题
“市面上有这么多不完美的产品，软件团队为什么还要把这些不完美的软件发布出来呢?为什么不能等到它们完美之后再发布?软件工程的一个重要任务，就是要在时间、成本等多种约束条件下决定一个软件在什么时候能“足够好”，可以发布。”
刚刚看到这个问题的时候，我充满疑惑，一个“足够好”的软件到底是什么样的，它既然作为软件创造的目标，我们要如何达到这一水平呢？
根据邹欣老师在书上写的，结合我的理解也就是说一个“足够好”的软件，绝不是一蹴而就的，而是经历一定的软件流程，通过全体团队成员的努力，在一个长期阶段内，逐步完成的。对于现实生活中的软件团队来说，一个好的产品不是一个英雄长期加班突击出来的。
根据我查到的资料，如Ed Yourdon 发表在 IEEE Software 上的一篇文章所描述的，你可以训练自己，编写出足够好的软件——对你的用户、对未来的维护者、对你自己内心的安宁来说是足够好，你会发现、你变得更多产。而你的用户也会更加高兴。你也许还会发现，因为“孵化期”更短，你的程序实际上更好了。
对此可见一个“足够好”的软件需要满足用户、未来维护者以及自己内心的需求，也就是说在用户满意度、可维护性、可靠性和软件流程的质量都可以满足大家需求的软件才能够被称为是“足够好”的软件。
那么，现在大学的学校、学院使用的教务管理系统，它可以方便学生进行个人选课资料、考试安排、考试成绩等信息的查询，也方便了学校教务老师的管理和与学生之间的沟通。但是，当它面临“开学选课”时，就会出现二维码无法发送、页面无法打开、选课信息跳转延迟等情况。那么，我们的教务管理系统能被称为是“足够好”的系统吗？
2.问题二：为什么单元测试必须由最熟悉代码的人（程序的作者本身）来写？
问题描述：在读到书第二章P25的时候读到一个问题
“单元测试必须由最熟悉代码的人( 程序的作者)来写。”
看见这个问题的我非常不理解单元测试应该就是白盒测试，它必须要保证每个被测试的函数里边很高的路径覆盖，这样才能保证程序在各种情况下都是按照预期运行的。那么为什么单元测试应该由程序员来写呢？如果说，程序员写代码的时候都要满足易读性，那遵循“术业有专攻”的道理，让程序员专心写程序，由专人来做单元测试的工作岂不是效率更高才对吗？
对于这个问题，我查了许多资料，但是也没有查到比较权威的答案，只是有很多人在说“单元测试是程序员的基本功”、“单元测试决定细节，细节决定成败”这样的话。我也可以想得明白如果这么说有个很显然的原因就是程序员写测试的工程也是他验证自己思路的过程，因为程序员知道他自己写代码的期望结果，所以在程序出现错误的时候，他能够第一时间做出判断。
大部分上来讲，我也可以比较赞成这种说法，但是联系实际想想，如果一个程序员，他写的程序出现了问题，而单元测试和程序的作者又都是他本人，那么他的思路和解决模式会不会因此而受到限制，是不是因为这样而没有意识到一些或许很简单的问题呢？这个时候是不是需要其他人帮忙点明思路呢？还是说单元测试只需要知道程序的主题思路就可以，所以要由程序的作者本人来做呢？
3.问题三：如何对于团队成员进行绩效管理？
问题描述：在读到书第十七章P402的时候里面提到
“如何衡量一个人的绩效考核呢？”
这个问题我们平时也可以用到，许多时候，大家越来越多的以“团队”身份出现，共同努力去完成一件事情，此过程中也必定会出现“三个和尚没水吃”的情况，大家都会有惰性思维也都会对互相依赖，有时候可能还会拖慢进度，如果能够善用绩效管理仿佛可以有效解决这一问题，那么如何对于团队成员进行绩效管理呢？
对此我专门查询了微软和谷歌两大公司的绩效管理方式，其实他们的绩效考核总结出来差不多就是：
（1）绩效管理一视同仁：
这一点倒是比较容易理解，大体上讲就是不能搞特殊化，要对团队所有成员一视同仁；
（2）兼顾公司业绩与个人发展：
微软将绩效管理分为两个部分，分别是公司业绩和个人发展，微软是一个知识化的公司，当员工的个人发展得到提升的时候，公司水平自然得到提升，那么公司业绩也必然会更好，以此来形成良性循环，互相促进。也就是说，在团队中的每个成员都得到良好的发展的时候，团队也会变得更好，这样也就会形成良性循环；
（3）考核和战略紧密结合：
在谷歌，会有公司的领导层和专家对要开发的项目进行集体评议,对于项目负责人做出的规划大家都会进行评议，通过多数专家的思想交流，确定你所做事情的合理性。在此条件下如若你提交的方案预计3个月完成，而你花了四个月的时间，是一定会被扣奖金的；
（4）评估的周期与标准、考核决定待遇与发展
可是我还是不太理解的是有时候团队人员做的事情是相互依赖的，有些事情并不是一个人独立做完的，那么我们就不能够从功能的用户喜爱程度或功能的好坏来评价。而且如果是根据工作量来进行绩效管理的话,我们该怎么样来确定每人的工作量呢?如果是根据每人完成的任务数来确定,但是那样又会出现每人完成的任务困难度不一样,按任务数来确定又不太公平。那么我们应该怎么来给每人确定他们的绩效呢?
三、总结
通过本次实验，我大致通读了《构建之法》这本书，对于其中的一些软件工程的问题产生或多或少的疑惑，这也激起了我学习软件工程这门课的兴趣，希望在这一个学期的认真学习中，能够大概解决我心中的这些疑惑，使自己的知识更加深入，理解更加透彻。