一、个人总结
自我评价表
| 类别 | 具体技能和面试问题 | 现在的回答(注明年级) |
|---|---|---|
| 语言 | 最拿手的计算机语言之一,代码量多少?(偏web前端，PC/Mobile App) | C语言，代码量没有具体计算过，大概两千行左右 |
| 语言 | 最拿手的计算机语言之二，代码量多少? (偏后端， 数据处理，网站后台机器学习，等) | Java，代码量会比C语言多一点，也是几千行 |
| 软件实现 | (阅读代码的能力，实现，单元测试) 1.你有没有在别人代码的基础上改进, 2.你是怎么读懂别人的代码的， 3.你采取了什么办法来保证你的新功能不会影响原来的功能? 4.你在开发中碰到最复杂的bug是什么，你是如何解决的? 5.这个bug出现的原因是什么，你在将来应该怎么去避免bug再出现? |
1.有改进过别人的代码 2.之前改的代码有的没有代码规范，所以只能一行行看，有的有代码规范的还可以参照一下规范，我一般从主函数看起，然后根据主函数用到的子函数或模块去找它们的编程过程 3.我会把源代码拷贝一份，在备份上进行修改，一般都是通过编函数再调用，尽量避免在主函数或原有的函数上直接修改 4.最复杂的bug可能是之前课设设计的网站在登录时没有考虑到安全问题，就是如果不登录，直接从某个界面进入网站依然能对网站进行操作，后来由于技术能力不足并没有解决这个bug 5.原因有很多，没有提前考虑到，而且本身的能力也有限。我觉得bug是无法避免的，重要的是要找出bug并解决，如果bug可以避免，那还要测试干嘛 |
| 软件测试 | (测试方法、测试工具、测试实践、代码覆盖率) 1.你如何测试你自己写的代码? 2.你如何测试别人的代码? 3.你掌握了多少种测试工具和方法? 4.你写过测试工具么? 5.你如何对一个网站进行压力测试和效能测试? 6.你如何测试一个软件的人机界面(Ux/UI) ? |
1.之前Java的时候有直接用eclipse上的测试工具直接在test上写测试用例对代码进行测试，后来软工课上也介绍过一些测试工具，在结对编程和团队项目的时候也有用上过 2.测试别人的代码也是用一些工具做性能测试，然后用测试用例测试代码的执行找bug，在各种硬件设备上测试 3.熟练掌握的没有，但是用过的有JUnit，还有微信开发者工具的测试，看别人用过效能分析的一些工具 4.没有，倒是用JUnit写个测试用例 5.用测试工具，网上有一些压力测试和效能测试的工具 6.带动身边的人帮忙，让大家试用一下软件的功能给出意见和反馈 |
| 效能分析 | 效能分析，效能改进 你写过的最复杂的代码是什么?你是如何测量和改进它的效能的，用了什么工具，如何分析的? |
我写过最复杂的代码应该就是这次软工的团队项目了，虽然说我负责的部分难度不大，但是还要考虑前后端交互，虽然以往的一些程序设计难度很大，但是也只是在程序设计过程，不需要考虑太多。测试的话就是用微信平台自带的测试工具测试，还有就是针对整个模块不断运行，找bug |
| 需求分析 | (需求分析，典型用户，场景，创新) 你做过多少个有实际用户的项目，用户最多有多少?你的项目有什么创新的地方? |
一个，目前项目还在开发阶段，现有四十多个用户，最终用户数量无法确定，创新的地方就是让学习变得有趣 |
| 行业洞察力 | 你最感兴趣的领域是什么?这个领域过去10年经历了哪些创新? 你分析过这个领域前10名产品么?请分析一下他们的优劣， 你要进入这个领域，应该如何创新? |
我对IT行业的了解通常都是来自互联网和一些老师上课给的资料，当初也是凑巧学了网络工程的专业，说实话，我对IT的了解真的少之又少，至于我感兴趣的领域，可以算是UI吧，因为之前的科研立项对前端有一点点接触，但是具体没有太多了解，只知道一点HTML和CSS |
| 项目管理 | 你参与过项目管理么?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况; 请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法？ 如果你突然发现项目不能按时完成，你作为项目领导，有什么办法? |
因为能力问题，缺乏自信和技术所以没做过PM，仅仅是作为团队成员完成一些难度较小的任务，我们团队结合敏捷开发和迭代开发，在敏捷冲刺alpha阶段七天完成一个MVP，打算在beta阶段的敏捷冲刺完善并增加一些功能 任务的优先次序需要根据项目的开发流程和项目所需要的数据，资源，耗时等来决定 精简项目的功能，先争取完成MVP |
| 软件设计 | 你做过架构设计，模块化设计，接口设计么?请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果? | 没做过架构设计，模块化设计之前的项目倒是偶一些简单的尝试，至于设计的原因需要再说明项目的内容，比较复杂 |
| 质量意识 | (代码复审/代码规范/代码质量) 你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说怎么提高? |
通过测试和试用实现代码复审，提高代码质量可以提高测试来实现，找到的bug越多，代码的质量也会提高 |
| 工具/社区 | Software Tools (performance tool, version control, work item, TFS) 1.你在各种开发平台(web, linux, PC, mobile, machine learning)都使用过什么样的工具，自己写过什么工具来改进工作效率?2.给社区贡献过什么工具和代码?Github有分享代码么? 3.你写的技术博客坚持了多久，读者最多的是哪一篇? |
1.使用过一些平常的工具，比如eclipse、visual studio、Dreamweaver、微信开发者工具等 2.有在Git上建项目和上传代码 3.博客最长时间坚持了一学期，读者最多的是Java课程设计—学生成绩管理系统 |
| 团队协作 | Work with others(协同工作，提供反馈，说服别人） 1.请描述你在项目中如何说服同伴采用你提出的更好的解决方案， 2.或者你如何听取了别人的意见，改进了自己的方案? 3.你如何说服懒惰的同伴加紧工作，实现团队的目标? |
1.首先要整理好自己的意见，清楚的描述给团队成员，确保你的意见正确表达，结合项目的要求和团队对项目的看法说明自己的方案的优缺点 2.听取并思考别人的意见，列出优缺点，在根据项目选择如何进行改进，不一定要全盘接受，但是要吸收优秀的意见并作出改进 3.每个任务设定一个截止期，要求每个成员除特殊情况必须在截止前完成 |
| 理论素养 | 1.你上过什么数学，计算机或其他理论课， 2.请举出具体的例子，说明你学到的理论知识如何帮助你解决实际问题。 |
1.高数、概率论、离散数学、C语言、Java、数据结构、数据库、算法、操作系统等等 2.算法和数据结构里面有一些对程序设计很有帮助，包括一些路径选择的算法、生成树的算法等。比如在做四则运算的时候就可以用上生成树的算法 |
| 自我管理 | 1.全年级你专业排名多少? 2.你从刚入学(大学一年级)到现在的排名有变化么? 如何解释你的排名的变化? |
1.全年级排名在前30左右 2.从大一开始排名有细微的上升，排名的变化其实并不意味着什么，我的编程能力还是偏弱的，想要提升但是总是没什么进步，思维比较呆板 |
二、回答问题
我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答
①关于专与精
当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是“演奏家满场奔走，操作各种乐器”呢? 当工程师设计软件的时候，工程师的设计、修改错误等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被正确地执行。当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维护知识，以及和硬件、商业模式相关的各种事件的需求。如果这大部分运维工作都是由一个运维工程师来完成，那么这位工程师的确是“全栈”。--《构建之法》第三章
当可以写各个乐器的乐谱的作曲家，或是可以操作各种乐器的演奏家有什么依据吗？
答：
每一个现代化的项目，都是一个非常复杂的构成，需要一个人来掌控全局，他不需要是各种技术的资深专家，但他需要熟悉到各种技术。对于一个团队特别是互联网企业来说，有一个全局性思维的人非常非常重要。全栈工程师是指掌握多种技能，并能利用多种技能独立完成产品的人，也叫全端工程师(同时具备前端和后台能力)。当可以写各个乐器的乐谱的作曲家，或是可以操作各种乐器的演奏家其实都需要自身具备比较广泛的知识面。“可以写各个乐器的乐谱的作曲家”从软件工程师的角度来说就需要掌握多种程序设计语言，包括前端（HTML、CSS、JavaGUI等）和后端（Java、c、Python等）；“可以操作各种乐器的演奏家”对软件工程师而言就是要熟练掌握各种程序设计工具的使用方法，包括各种编程工具、测试工具等。
②关于过早优化
大家也要注意避免没有做分析就过早地进行“效能提高”，刚才有人提到我们可能要提高排序的性能，但是从图2-6 来看，system.collections.Arraio 只占了FreqOneWord( )不到1/50的时间，如果我们不经分析就盲目优化，也许会事倍功半。我们在第三章还会讲到过早优化的其他例子。--《构建之法》第二章
过早优化: 既然软件是“软”的，那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似可很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部可题上陷进去，花大量时间对其进行优化、无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切罪恶的根源”。--《构建之法》第三章
关于程序优化的时机，这真的是一个令人头疼的问题，在程序设计或课设过程中，对于某个模块既希望优化使其能具有更强大的功能，但又担心能否在最终将其全部功能都充分利用到而纠结半天，究竟怎样才能避免过早优化，怎样确定程序优化的时机？
答：
程序优化的时机对整个项目的开发来说尤为重要，有一些问题如果能尽早解决会给后期的开发带来很大的便利，如果在前期被忽视了，到后期开发很难发现原因。“现代计算机科学的鼻祖”Donald Knuth曾说过“过早的优化是万恶之源”，因为：让正确的程序更快，要比让快速的程序正确容易得多。其中讲了7个原则，简单罗列如下：
1. 究竟要优化什么？
2. 选择一个正确的优化指标
3. 优化在刀刃上
4. 优化层次越高越好
5. 不要过早优化
6. 依赖性能分析，而不是直觉
7. 优化不是万金油
③关于软件设计思想与软件工程思想
对通用的软件设计思想和软件工程思想的理解。这一方面就比较虚，什么是好的软件设计思想? 什么是好的软件工程思想?一个工程师开了博客，转发了很多别人的文章，这算有思想么? 另个工程师坚持做任何设计都要画UML图，这算有思想么?--《构建之法》第三章：初级工程师的成长-3
我认为初级软件工程师的成长确实应该包含对软件设计思想和软件工程思想的理解，但是要如何才能做到正确理解这两种思想，在我们实际生活中，包括软件设计与实现的过程中，很容易会出现让自己觉得矛盾的想法，而网上的资料又各执一词，要如何才能确定我们的理解是正确的，又或者说如何才能正确理解软件设计思想与软件工程思想？
答：
软件是一种知识型产品，需要创造性，并依赖每个开发人员的创造力和积极性。所以引导人们新的思考，引导人们不断认识软件工程而建立独特的软件工程思想。
软件工程在过去几十年的发展历程中，也形成了一些鲜明的新思想。例如，IBM 提出了软件开发思想的4项要点——迭代开发、以系统架构为中心、持续的质量保证以及管理变更和资产，其中只有“持续的质量保证”和传统工业工程是十分吻合的，而其它3项具有软件特性所拥有的思想。软件的变更比较频繁，自然对其管理的高要求，进一步促进迭代开发的合理性。很多思想都是要靠实践去证明其是否是正确的，当你没办法确定自己的想法是否正确，那就尝试去实践，把想法变成一个实体，虽然可能结果不一定是对的还会浪费时间，但是你能更加确定自己的想法。
--参考：软件设计思想
④关于软件开发的质量与re-work（返工）
软件开发的工作量和质量怎么衡量呢? 第2 章提到的PSP认为有下列4个因素:
a.项目/任务有多大?
说明项目的大小，一般月代码行数(LineOfCode,LOC) 来表示; 也可以用功能点(Function Point) 来表示。
b.花了多少时间?
可以用小时、天、月、年来表示。一组人所花费的时间可以用(人数x 时间)来表示，例如某项目花费了10个人x 月。
c.质量如何?
交付的代码中有多少缺陷? 交付有两个定义:①在代码完成（code complete）时，交付给测试人员；②在软件最终发布时交付给顾客。--《构建之法》第三章
笔者认为，re-work 只是表明在软件开发过程中花费的时间，re-work 的多寡并不跟最终的质量成正比关系，软件开发过程很大程度上是一个探索和实验的过程，不同的re-work能帮助工程师深人了解项目的各个难点，尽早交付原型，找到最优解决方案，等等。因此，re-work是有价值的。当然，如具一个程序员为了一个简单的问题而不断地re-work,其工作效率就不是太高一这可以用时间花费来衡量。--《构建之法》第三章
为何说re-work 的多寡并不跟最终的质量成正比关系，我的想法是：当工程师从程序中发现了问题并进行re-work，这样程序的质量也会随着提高，发现越多的问题，进行越多次的re-work难道不应该使最终的质量更好吗（虽然会消耗更多的时间）？
答：
这个还是要具体问题具体分析，如果代码本身是一个半成品，那么其本身的bug肯定会比完善的代码的bug更多，如果单独从bug的多少来判断代码的质量是片面的，比如一段四则运算代码返工了10次但是它仅实现了加减操作，而另一段四则运算代码返工5次，但是它实现了加减乘除四种运算，显然返工的次数并不能代表代码的质量，还是要看代码实现的功能的完整度。
⑤关于非团队与团队
A.在讲团队之前。我们要讲讲什么是“非团队”。
王屋村里经常发生这样的一幕:
王屋村的居民大智要把一堆砖头从村头搬到村尾他来到顶球酒吧前，看到前面三三两两地蹲着一些人，有些人面前放着一块包装箱纸板，上面写着“Java,五毛一行”;“网页前端，不酷不要钱”;“专做PS,擅长人体”;“通吃SQL、NoSQL"，等等。
大智冲这些人喊了一嗓子: 搬砖的有没有?一百块砖一毛钱! 地上蹲着的一些人抬头看了看，有一两个人慢慢站起来了。大智看了看人数，又喊了一声: 中午有盒饭! 这时七八个人都站起来了.拍拍尼股就凑到大智面前。大智就带着他们走了。
这七人个人是团队（Team）么? 不是，他们只是一群乌合之众，临时聚集在一起，各自完成任务就领钱走人。--《构建之法》第五章-团队与非团队
B.可以看出，团队有共同的特点:
1.团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。王屋村搬砖的“非团队”成员则不然，每个人想搬多少就搬多少，不想干了就结算工钱走人。
2.团队成员有各自的分工，互相依赖合作，共同完成任务。王屋村搬砖的“非团队”成
员则是各自行动，独立把任务完成，有人不醉而别，对其他的搬砖人无实质影响。--《构建之法》第五章-团队与非团队
我还是无法理解为什么文段A是在描述非团队这个概念，我觉得他们也是有一致的集体目标（把一堆砖头从村头搬到村尾），也要一起完成这目标，成员有各自的分工，互相依赖合作，共同完成任务。对于团队而言，也有成员由于某些原因而退出的情况，这与“不想干了就结算工钱走人”难道不是一样的道理吗？
答：
在经过alpha阶段敏捷冲刺之后，我对团队合作有所理解，不是一群人凑齐了就是一个团队，团队里的每一个人都有自己的角色，一旦缺少某一个，那么团队就会收到影响，而且整个团队之间的交流和协作尤为重要，而不是像流水线一样，各司其职，对其他环节不管不顾。团队项目合作都是一环扣一环的，每个成员既要完成自己的任务，还要考虑整体工作进展。
三、再提问题
结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
①关于用户体验
12.3评价标准
1.尽快提供可感触的反馈
系统状态要有反馈，等待时间要合适。现在程序发生了什么，应该在某一个统一的地方清晰地标示出。一个目标用户能够只靠软件的主要反馈来完成基本操作，而不用事先学习使用手册。系统的反馈可以是视觉的、听觉的、触觉的（例如手机振动）。但是要避免简单重复的提示。
5.适合各种类型的用户
我们没有必要为了将就初学者，把操作都摆到UI最显眼的位置。交互设计的一个原则是：如果某个看似不明显的交互操作解释过一次之后就很容易理解，那么这就是一个好设计。
——《构建之法》第十二章
在alpha阶段复审过程中发现了一个问题，很多团队交付的产品使用起来并不是很顺手，举一个**记账小程序而言，我需要通过长按日期才能查看我当天的记录，但是一开始并没有任何提示，还是通过问开发人员才知道这个操作，但是这个操作在开发人员而言是一个很明显简便的操作。如何界定一个操作是否需要提示，做到让初学者容易上手又让老用户不觉得复杂麻烦？
②关于伙伴测试（Buddy Test）
在一个复杂系统的开发过程中，当一个新的模块(或者旧模块的新版本)加人系统中时，往往会出现下列情况。
1.导致整个系统稳定性下降。不光影响自己的模块，更麻烦的是阻碍团队其他人员的工作。
2.产生很多Bug。这些Bug都要录人到数据库中，经过层层会诊( Triage),然后交给开发人员，然后再经历系列Bug的旅行，才能最后修复，这样成本就变得很高。
如何改进呢?一个办法当然是写好单元测试，或者运用重构技术以保证稳定性等。我们这里要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴(Buddy)，在签入新代码之前，开发人员做一个包含 新模块的私人构建( Private Build),测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开
发人员再正式签入代码。
在项目后期，签入代码的门槛会变得越来越高，大部分团队都要求缺陷修正(Bug Fix)必须经伙伴测试的验证才能签人代码库。——《构建之法》第十三章
如果采用伙伴测试，那么测试人员需要在代码签入之前对其进行完整的测试，在签入之后又要对整体代码进行一次整体的测试，这样虽然降低了在代码签入后产生许多bug，但是却加重了测试人员的负担不是吗？
③关于测试的角色(Test)要独立出来么
首先，有分工是好事，软件团队中应该有独立的测试角色。所有人都可以参与QA的工作(报告Bug什么的)，但是最后要有一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布时，必须得到此角色的签字保证(SignOf)。分工是社会和行业进化的结果，开发和测试其实是软件工程的两个分支，对于不同的软件/服务，测试的方式和程度都有所区别。独立的测试角色从用户的角度出发验证产品质量。独立专业的测试等同于代表客户对产品进行认证。
如果你的软件团队做的事情和上面的情况类似，那当然不必分工。你们做的很可能不是商用软件，你的软件团队大概也不用受什么软件工程规律的束缚。正如本书前面提到的，也许还处在“做纸飞机”那种幼稚而无忧无虑的阶段。但是，任何产业成熟到一定阶段，独立的质量保障角色都是不可避免的。团队内部有QA角色，团队外部也有独立的QA角色。——《构建之法》第十四章
我记得之前说过，单元测试需要有最熟悉代码的人（代码的作者）来写，是否所有与代码有关的测试都需要作者来写，那这样测试人员是否还需要负责代码方面的测试？又或者说，开发人员只负责开发，将测试都交给测试人员？
④关于发布之后——事后诸葛亮会议
阿超给小芳一个讨论的模板， 同时也嘱咐小芳不定要拘泥于模板，要见机行事，根据会议的进展灵活地变动计划。要牢记会议的核心问题:“如果你可以重新来过，什么方面可以做得更好?”另外，在问“为什么”的时候，要多问几次，层层推进，找到问题的根源。
例如:软件发布后用户报告了一个大问题。“为什么?”
因为程序没有考虑某种边界条件。“为什么在测试阶段没有测出来?
因为这个代码是测试的最后阶段才加进去的。“为什么不通知PM/Test?
因为Dev认为没有问题的，是很简单的修改。“为什么不通知别人?
因为Dev认为那些都是软件工程无聊的规定...D..是大牛人，不必遵守的。“为什么? !
问到这个层次，就把问题根源暴露出来了。
这种分析方法也叫5WHY(五问法)，其关键在于，从现象和结果人手，不管面子问题(“这样问下去果冻脸上会挂不住啊”)，不管小团队的边界(“这是他们团队的事，我不清楚”)，沿着因果关系链条，打破砂锅问到底，直至找出原有问题的根本原因。如果针对一个问题能从各个方面深人探究，我们很可能得到一颗树状图，根部就是问题，各个枝干是分类，各个叶节点就是县体的原因。这种图也叫“因果图”、“鱼骨图”(Ishikawa Diagram)。对丁重要问题的分析可以像下图那样，列出各类因素中主要和次要的原因，并可以讨论改进的方法。——《构建之法》第十五章
我觉得五问法挺好的，我的疑惑在于如果问题一层一层深究，那么成员之间可能会出现一些不好的情绪，像文中从Dev到Test和PM，难免给人推卸责任的感觉，但是如果不深究，又找不出问题的关键，这要如何取舍？
⑤关于燃尽图
再说说燃尽图。有些燃尽图只是列出了任务的数目，这种图无法展现项目的拖延情况，一个任务有大有小，它们在图表中都是一一个点，一个16小时的任务需要3天完成，一个2小时的任务出于和种原因也花了3天时间，它们在图表中的表现是一一样的。在实践中，我个人认为以时间为度量的燃尽图更有效果。
说到燃尽图，助教曾经在我们的alpha阶段总结中跟我们提出了这个问题，由于燃尽图的任务是在项目开始前划分的，而在开发过程中会出现燃尽图中没有的任务，这个时候应该怎么办？可以在开发过程中往燃尽图添加任务吗？
【附加题】：请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接
在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题
豆瓣链接：https://book.douban.com/annotation/54355345/