一、个人总结
在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
请用自我评价表： 有比较才会有进步。
| 类别 | 具体技能和面试问题 | 现在的回答（大三） | 毕业后的回答 |
|---|---|---|---|
| 语言 | 最拿手的计算机语言之一，代码量多少？（偏web前端，PC/Mobile App） | 可能是js吧，代码量大概2千左右 | |
| 语言 | 最拿手的计算机语言之二，代码量多少？（偏后端，数据处理，网站后台，机器学习，等） | 应该是java，代码量5、6千左右吧，并没有就具体的算过 | |
| 软件实现 | (阅读代码的能力，实现，单元测试)你有没有在别人代码的基础上改进，你是怎么读懂别人的代码的，你采取了什么办法来保证你的新功能不会影响原来的功能？你在开发中碰到最复杂的bug是什么，你是如何解决的？这个bug出现的原因是什么，你在将来应该怎么去避免bug再出现？ | 1. 有在别人的代码基础上进行改进；2. 如果代码的编写者是认识的或者是就在身边的，会直接问她代码的具体事项，像是代码的变量的设置是怎么样的，是怎么编写的等等，如果代码编写者并不是认识的话，那么就会自己先将代码通篇看下来，进行代码粗略了解，记录好相应的变量设置，再根据注释进行详细的理解。3. 可能就是不会动代码的主要框架，只是对其中某些模块进行修改或者增加一些需要的模块，主体是不变的；4. 大概会自己先根据提示的错误，进行修改，如果修改后还是不行，就会去网上搜索些资料，或者通过询问同学来解决问题。要是还是不行的话，就去问老师来解决。5. 有些bug出现的原因有可能是因为编写时出现的错误，应该在编写代码时注意好自己编写的代码是不是有逻辑上的错误。 | |
| 软件测试 | (测试方法、测试工具、测试实践、代码覆盖率)你如何测试你自己写的代码？你如何测试别人的代码？你掌握了多少种测试工具和方法？你写过测试工具么？你如何对一个网站进行压力测试和效能测试？你如何测试一个软件的人机界面（ux/ui）？ | 1. 一般在编写过程中，会通过print输出来查看自己的代码是否有问题。代码编写完后可能会通过一些测试工具对其进行测试或者通过JUnit单元测试和代码覆盖率来进行测试。2. 测试别人的代码的方式和测试自己的代码的方式没有什么区别。3. 例如JUnit单元测试和代码覆盖率，使用一些软件自带的测试工具，云真机这些测试方法。4. 没有写过测试工具。5. emmm，本身并没有做过实际可运行的网站，所以其实并没有进行过相关的测试。6. 一般可能就是找些用户进行实际体验和使用网上的云真机软件进行测试。 | |
| 效能分析 | 效能分析，效能改进，你写过最复杂的代码是什么？你是如何测量和改进它的效能的，用了什么工具，如何分析的？ | 1. 我写过最复杂的代码应该是网上购物系统吧。2. 那时候就只是使用一些软件自带的工具进行测试，也没有想过要测试效能。 | |
| 需求分析 | (需求分析，典型用户，场景，创新)你做过多少个有实际用户的项目，用户最多有多少？你的项目有什么创新的地方？ | 1. 我做过的有实际用户的项目，大概就只有现在在做EASY记微信小程序，用户最多大概有30人。2. emmm，好像没有什么地方是创新的，大致网上都有。 | |
| 行业洞察力 | 你最感兴趣的领域是什么？这个领域过去10年经历了哪些创新？你分析过这个领域前10名产品吗？请分析一下他们的优势，你要进入这个领域，应该如何创新？ | 1. 我最感兴趣的领域大概是java方面的开发。2. 像是美团，阿里等都是使用java进行开发。3. emmm，其实没有分析过，大概他们的优势在于现在的行业前景比较好，比较被重视，是行业中的领头人物，创新方面也有人才，和创新性高。应该会根据市场进行创新吧，使得他们更贴近用户的需求。 | |
| 项目管理 | 你参与过项目管理么？请描述一下两个当下流行的开发方法在你的项目中的具体应用情况；请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法？如果你突然发现项目不能按时完成，你作为项目领导，有什么办法？ | 1. 参加多项目管理。2. 我们在项目开发的过程中使用了敏捷开发的模式来进行，通过每天的站立会议和7天的冲刺阶段，完成我们的项目开发。3. 我是根据任务对于我们项目的重要程度来决定其优先次序，也会根据我们的项目的核心功能是什么来决定我们要先做什么任务。因为我们做Alpha阶段的目标结果就是完成MVP——即项目的主要任务。4. 可能就会重新将不能按时完成的那部分任务进行分配，安排给还有能力和时间的人员来完成，并且需要延长工作时间，以确保可以完成这项目。 | |
| 软件设计 | 你做过架构设计，模块化设计，接口设计么？请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果？ | 1. 只是在java开发中做过接口设计、模块化设计。2. 我是将项目中一些共同的功能设置接口，这样的话，整体的代码会比较方便管理和而且代码简洁明了。emmm，没有做过不同的设计方式，所以也就没有比较过。 | |
| 质量意识 | (代码复审/代码规范/代码质量)你是怎么做代码复审的，你加入我们团队后，能帮助我们提高代码质量么，请具体说怎么提高？ | 1. 我是根据项目开发时所制定好的代码规范进行代码复审，看是否代码有符合规范，再看代码的可读性和是否将可能的情况都包含在内了。2. 大概会减少不必要的代码，降低代码的冗余程度，规范好代码的编写规范。 | |
| 工具/社区 | Software Tools(performance tool,version control,work item,TFS)你在各种开发平台（web,linux,PC,mobile,machine,learning）都是用过什么样的工具，自己写过什么工具来改进工作效率？给社区贡献过什么工具和代码？Github有分享代码么？你写的技术博客坚持了多久，读者最多的是哪一篇？ | 1. 有eclipse、eclipse jee、vc6.0、vs、NetBeans、微信web开发者平台。没有自己写过什么工具。2. 一般都是些java方面的代码和这次项目的代码。一般是在码云上上传代码的。 3. 我写的技术博客大概有两年了，读者最多的是《Java课程设计+购物车WEB页面》。 | |
| 团队协作 | Work with others（协同工作，提供反馈，说服别人）请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取了别人的意见，改进了自己的方案？你如何说服懒惰的同伴加紧工作，实现团队的目标？ | 1. 一般是会将我的方案会有什么样的结果和同伴的方案会有什么的结果，都表述出来，用事实来说服他们，用事实告诉他们哪种方案会更加优秀。2. 会根据他们的提出的意见进行自我方案的审视，看否自己的方案真的出现了同伴提出的问题，然后结合他们所提出的的意见来改进自己的方案，以便能够达到最好的效果。3. 可能会和她来一次私下的谈话，将我们任务紧迫程度告诉她，和她交谈她的态度问题，然后会在她身后催着她完成任务。 | |
| 理论素养 | 你上过什么数学，计算机或其他理论课，请举出具体的例子，说明你学到的理论知识如何帮助你解决实际问题。 | 1. 高等数学、离散数学、线性代数、概率论、数字逻辑、操作系统等课程。像是写代码时，有时候会用到一些数学知识，类似于计算水仙花数啊这样子的。 | |
| 自我管理 | 全年级你专业排名多少？你从刚入学（大学一年级）到现在的排名有变化吗？你如何解释你的排名的变化？ | 1. 大三上34名。2. 从刚入学（大学一年级）到现在的排名有变化。3. 主要可能是学习上不是特别的主动，有惰性，导致成绩起伏不定，而且很迷茫，不知道自己应该学点什么。 |
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
问题一：
d. 进一步说，“覆盖率”有下面几个层次：
- 1.函数的覆盖，这个模块的每一个函数都覆盖了么？
- 2.语句的覆盖，这个模块的每一个语句都覆盖了么？
- 3.分支的覆盖，这个模块的每一个条件分支都覆盖了么？
- 4.条件的覆盖，这个模块的每一个布尔表达式的TURE|FALSE都覆盖了么？
在读2.1.2 好的单元测试的标准时，在P27中读到了上文，作者说代码覆盖率需要考虑到每个模块是否覆盖到了每个函数，是否覆盖到了每个语句，是否覆盖到了每个条件分支，是否覆盖到了每个布尔表达式的TURE|FALSE。但是在实际的软件工程中，在进行单元测试时，我们真的要保证有100%的代码覆盖率吗？是否只要保证了单元测试覆盖了所有的代码路径之后，像是语句覆盖之类的就可以不用全部代码覆盖了呢？就像如果出现了《》中提到的情况那样，某段代码功能看起来很简单，没有条件，没有循环，没有转换，没有任何复杂的东西，只是一段简单的老胶水代码。那么这时候我们也需要对它们进行代码覆盖，进行测试吗？这类的代码我们是否也要对它们保证完全覆盖呢？
- 答：对于我们在开发过程中来说，单元测试是一种保证代码质量的手段，但是即使如此我们也不必过于教条主义，不一定非要达到100%的覆盖率，想要达到最好的单元测试的效果，获得代码质量高，这主要的关键就是我们需要在软件的质量、开发进度、开发成本之间达到一个平衡，如果仅仅一味要将单元测试的覆盖率达到100%，有时候并不能开发出好的软件，反而浪费了时间和精力。
问题二：
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。
在读4.5.2 为什么要结对编程时，在P85页读到了上文的内容，作者说两人结对编程时，程序的质量将取决于水平较高的一位，也就是说在编程过程中是由水平较高的程序员作为主导。但是这样的话，在进行编程的过程中，是否会出现水平较高的程序员长时间的掌控着键盘，而水平较低的程序员是否也会觉得由水平高的写代码能够更好地完成项目或者课设，然后自己基本上没有做什么核心任务这种情况呢？那么到项目结束时，就会出现不会的人还是不会，会的人更加会了的情况。像这样的情况在我们的课设中也是可以看到的。如果我们想要避免出现这样的情况，那么在编程初期我们应该怎么样分配工作才能够保证即有质有量地完成编程任务，不会出现代码来不及写的情况，又能够让两个人都能够都参与到主要代码的编程中？怎么样的工作量才能够让结对编程的两个人都能够有所收获呢？
- 答：进行结对编程时，想要恰如其分地发挥出两个人优势，将任务很好地完成，那么就需要我们把控好与结对对象之间合作的度。而且首先我们在选择结对对象时，就应该了解好我们要选择的对象，看是否她真的适合作为我们的合作搭档。其次，在开始进行项目编程时，就应该根据两人之间的能力进行了解，根据两人的实际情况来分配每个人的劳动量，这样就可以避免有人会因为多做而觉得吃亏或者是不爽，也避免了代码写不完，出现任务没法完成的情况。而且我们在进行一个项目时，并非一定要教条式的自始至终进行结对，尤其是在项目初期选择一些模块进行结对即可，结对主要还是让水平低的能跟着水平高的养成良好的习惯，形成统一的规范，并不是希望水平低的同学可以一下子达到特别高的水平。
问题三：
得到了需求之后，软件团队就要考虑实现这些需求。一个公司可能有多种软件产品和服务，它们各有不同的战略意义。一个软件或服务也由很多功能组成，它们有机地结合起来，才能解决用户的问题，产生效益。
在读8.5 功能的定位和优先级时，在P171页读到了上文的内容，作者说开发一款软件需要在需求分析时将所收集到的用户的需求按照不同的着重点来开发不同的功能。但是我们要如何来确定每项功能的优先级呢，如何确定那种功能是这款软件的杀手功能呢？是根据市场上其他软件的使用情况来决定，还是根据对目标人群的调查来决定？而且根据书上P174—P175中的三幅图来看，我们是不是不仅仅要将杀手功能决定好定位，并做好它，还需要在这基础上添加一些市面上同款软件没有的功能呢？就像我们在去餐厅就餐时，如果有一家餐厅卫生又好吃，还不时有些小活动，我们一般都爱去那吃，那么在开发软件上也应该要做到这样的吧，这样才能够产生效益。
- 答：如果我们是开发的话，那么在初期时，我们就暂时不要把精力放在杀手功能的确定和开发这个上面，我们所需要的是安安心心、老老实实地把产品经理定义好的功能实现出来，做到软件没有bug，拥有良好的性能这就很成功了。如果我们要开发我们软件的杀手功能至少应该在我们软件开发初期结束之后，根据市场的实际情况来进行开发，不仅仅要根据市面上同类型的软件进行开发，还应该根据我们的目标人群的需求进行开发。但是我们并不是要在自己的软件中添加上多少的功能才可以，要知道我们在软件的核心功能的开发上是没有止境的，并不是说我们做到什么程度就算做好了，而是我们要不断根据实际来发展我们的核心功能，并且一个好的软件并不是靠功能堆出来的，并不是我们把软件的功能做的有多少多，就可以把我们的软件做的有多出色。
问题四：
好的用户体验当然是所有人都想要的，如果它和产品的质量有冲突，怎么办？牺牲质量去追求用户体验么，用户能接受吗？
在读12.1.6 用户体验和质量时，在P269页读到了上文的内容。确实，在开发软件时或者是更新软件时，难免会遇到上述的情况。如果用户的需求，用户的体验和我们的优化的功能或者软件起冲突了，那么我们是该顾着用户的需求呢，还是继续推出优化软件？作者在这段话后面引用了一个案例来说明了作者自己的答案，但是似乎太片面了，并不是所有的情况都可以是顾用户的需求，舍功能的优化的。并且当两者利弊都差不多时，我们该怎么选择呢？是否能有个准则来让我们衡量呢？
- 答：一般来说用户体验属于锦上添花，俗话说：“皮之不存，毛将焉附”，如果我们不能够将我们的软件推陈出新，进行优化，那么我们的软件早就被市场淘汰了，哪里要会有什么用户体验，而且一千个读者，就会有一千个哈姆雷特，不同的用户对于我们的软件的体验想法也是会不同的。很多问题都没有标准答案，需要我们根据具体的情况去判定，看是否大部分用户都对这次的优化不满意，是否不改进这一点会影响我们软件的市场份额和软件使用率呢，如果关系重大，那么我们就应该考虑用户的意见。
问题五：
可以看出，在算法和数据库领域，创新的想法一开始往往不被接受，而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。
在读16.1.2 迷思之二：大家都喜欢创新时，在P349-P350页读到了上文的内容，结合前文的内容，不难看出作者认为更新升级往往比起创新更容易让人们接受。确实，就像是如果你还不容易学会了某种常用的编程语言，例如C语言，java等，结果一段时间后，开始使用某种新的编程语言进行编程了，又只能从头学起了，这样的话，确实只是更新会比创新更让人接受。但是，如果仅仅只是更新换代，不进行技术的创新的话，那么科技的发展就只能停留不前了。我们现在的社会不也是一步步从原来的创新中建立起来的吗？如果我们否定了创新，那么我们是不是也否定了现在呢？那么我们该如何打破人们对于创新的偏见呢？
- 答：其实创新和升级从来就不是矛盾和对立的。有时候，一些事物升级到了一定的地步，当它不能够再继续升级时，那么就会出现一次关于这个事物的创新。就像是计算机的内存一样，当它升级到了极点，再也匹配不上cpu的运行速度时，那么必然会出现一次新的改革，一次关于它的创新。所以其实他们两者之间并不是矛盾与对立的。
三、再提问题
同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
- 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。
- 列出一些事例或资料，支持你的提问 。
- 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
- 一个模板可以是这样： 我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
###问题一：
单元测试必须由最熟悉代码的人（程序的作者）来写。
在第2章的P26中讲述到，单元测试必须由最熟悉代码的人（程序的作者）来写。emmm，大部分来说，我还是赞同这个观点的，毕竟代码的作者是最了解代码的目的、特点和实现的局限性，由代码的作者来写单元测试是再好不过了。但是，是不是有时候往往会因为这代码是自己写的，自己的想法就已经局限在这里面了，就没有意识到某些问题呢？这时候是不是就需要有其他人来提供他们的帮助或者是关于这个代码的测试意见呢？是不是这个也是必要的呢？还是只要有代码作者的想法就够了呢？
###问题二：
带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件。
在第9章中讲述了关于项目经理的相关知识，像是在P198中讲述了一些关于PM在一个项目中的具体任务。但是在我看到第6小点时，我有了这个问题——PM需要带领其他成员确保项目保持功能/时间/资源的合理平衡，但是PM应该从什么角度上确保PM决定的是对的呢？怎么样才是真正合理的平衡？是否需要想我查找到的《产品开发项目的离散时间/成本/质量平衡问题研究》这篇文章中提到的那样——“根据产品开发项目的特点，通过人力资源价格计算产品开发项目成本，采用质量功能展开技术对项目质量进行量化计算。”来进行计算项目的平衡吗？还是根据PM自己的感觉走就好了？
###问题三：
软件的开发过程有三个主要的特性：“好”、“快”、“便宜”。
在第14章中的P311中提到了软件的开发过程有三个主要的特性：“好”、“快”、“便宜”。但是我看了这句话后，有个疑惑是否软件在开发过程中，如何确保在开发进程快又成本便宜的情况下，软件的功能又好？软件的质量与“快”、“便宜”相关，那么我们该怎么来平衡三者的关系，如何取得一个平衡点呢？而且如果像是书上P313中所说的那样，我们采用CMMI模型管理项目的理论的话，那么是否我们的软件就一定可以达到最佳值？
###问题四：
软件团队如何做人员的绩效管理？
在第17章中的P403中提到了关于团队任务结束之后进行绩效管理的问题，就像书中问的那样软件团队如何做人员的绩效管理？有时候团队人员做的事情是相互依赖的，有些事情并不是一个人独立做完的，那么我们就不能够从功能的用户喜爱程度或功能的好坏来评价。而且如果是根据工作量来进行绩效管理的话，我们该怎么样来确定每人的工作量呢？如果是根据每人完成的任务数来确定，但是那样又会出现每人完成的任务困难度不一样，按任务数来确定又不太公平。那么我们应该怎么来给每人确定他们的绩效呢？
###问题五：
在Beta阶段中，需要我们换掉一个成员，再加入一个成员。那么这种机制真的对于我们来说有帮助吗？原本已经磨合好的团队，又因为换人机制，导致团队又得重新磨合，而且还得分出时间来帮助新进组的成员尽快熟悉项目，但是不是从头跟到尾的话，是不是会对这个项目的理解会比较困难，出现不能够理解我们的意图的情况？而且我们又怎么确定将哪位成员换掉呢？是不是就是将贡献最少、能力最差的成员换出去呢？这样是不是对那位成员不太好呢？
4.【附加题】：请将问题提交至豆瓣：， 并在博客中给出链接在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题
