软工网络15个人作业4——alpha阶段个人总结

Posted 2020-11-06 jml1225

一、个人总结

第一部分：硬的问题

类别	具体技能和面试问题	现在回答	毕业找工作时
语言	最拿手的计算机语言之一，代码量多少？	java，三千左右
语言	最拿手的计算机语言之二，代码量有多少	C，一千五左右
软件实现	（代码阅读能力，实现，单元测试）你有没有在别的代码的基础上改进，你是怎么读懂别人的代码，你采取什么办法保证你的新功能不会影响原来的功能？你在开发中碰到最复杂的bug是什么，你是如何解决的？这个bug出现的原因是什么，你将来应该怎么样去避免bug出现？	有；直接看啊，不懂的就问原作者，不知道原作者就百度；修修补补；没什么最复杂的bug,要么问同学要么就百度解决；出现的原因是因为自己能力不够；未来为加强自己的能力。
软件测试	（测试方法，测试工具，测试实践，代码覆盖率）你是如何测试你自己写的代码？你何如测试别人写的代码？你掌握了多少种测试工具和方法?你写过测试工具吗?你如何对一个网站进行压力测试和技能测试？你如何测试一个软件的人机界面（UX/UI）？	先运行一遍试试，再用各类工具去测试；只会简单使用eclipse和intellij idea；都是通过直接使用。
效能分析	（效能分析，效能改进）你写过的最复杂的代码是什么？你是如何测试量和改进他的效能的，用了什么工具，如何分析？	最复杂的是大一的C语言课设、大二的Java课设和现在正在进行的软件工程团队项目；直接使用。
需求分析	（需求分析，典型用户，场景，创新）你做过多少有实际用户的项目，用户量是多少？你的项目有什么创新的地方?	以前没做过，只做了现在的团队项目；创新就创新在没人做过我们的产品，而我们的产品又非常有用，符合广大师生的需求，且现在已经可以使用了。
行业洞察力	你最感兴趣的领域是什么？这个领域过去十年有什么创新？你分析过这个领域前十的产品吗？请分析一下他们的优劣，你要进入这个领域，如何创新？	最感兴趣的是人工智能和大数据
项目管理	你参加过项目管理吗？如何决定各个任务的优先顺序？如果项目不能及时完成，你要怎么办？	没参与过；哪个重要哪个先做；不能及时完成就加班加点补救
软件设计	你做过架构设计，模块化设计，接口设计么？请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果?	做过；这样做可以减少代码量，还可以增加代码可读性
质量意识	（代码复审/代码规范/代码质量）你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说明怎么提高？	按代码规范的框架来做
工具/社区	Software Tools(performance too l,version control,work item,TFS)你在各种开发平台（web,linux,PC,mobile,macheine learning）都使用过什么样的工具，自己写过什么工具来改进工作效率？给社区贡献过什么工具和代码？GitHub有分享代码么?你写的技术博客坚持了多久，读者最多的是哪一篇？	eclipse、intellij idea、codeblocks、devc++、vs等；没写过；没贡献过；没写技术博客，写的都是博客作业
团队协作	Work with others（协同工作，提供反馈，说服别人请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取别人的意见，改进了自己的方案？你如何说服懒惰的同伴加紧工作，实现团队的目标？	给同伴讲解我的方案的所有优点，比原先的方案好在哪；无论怎样，哪个好就采用哪个；当然是催啊一直催催催
理论素养	你上过什么数学，计算机或者其他理论课，请举具体的例子，说明你学的理论知识如何帮助你解决实际问题。	高等数学、离散数学等各种数学类课程、C语言、计算机组成原理、Java、数据结构等；如何帮我解决问题？当然学会了很多知识，学会敲代码，我现在才能做软件工程这个团队项目。
自我管理	全年级你专业排名多少？你从刚入学（大学一年级）到现在排名有变化么？如何解释你的排名的变化？	排名中下，因为只学自己有兴趣的想学的。

第二部分：软的问题

编号	问题	回答
1	当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。”	不但主动做，还会影响同事一起做好
2	主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了	不但主动做，还会影响同事一起做好
3	经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。	一直主动这样做
4	DRY （Don‘t Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式	这要讲场合
5	消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。	想做，但是不知道怎么衡量效果
6	通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。	不但主动做，还会影响同事一起做好
7	设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。	大概同意，但是怎么接近用户呢？
8	估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。	不但主动做，还会影响同事一起做好
9	图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。	正在学习命令行工具
10	有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。	没有任何定制
11	理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。	每写100行程序，我就尽量用一个模式。
12	代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。	不但主动做，还会影响同事一起做好
13	在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log.	不但主动做，还会影响同事一起做好
14	重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。	想用，但没有时间
15	只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。	不但主动做，还会影响同事一起做好
16	善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源	不但主动做，还会影响同事一起做好
17	当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。	不但主动做，还会影响同事一起做好
18	把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。	不但主动做，还会影响同事一起做好
19	在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。	考虑在适当的层次支持并行
20	在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。	一直主动这样做
21	重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。	主动测试程序效率，以验证估算
22	在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。	不但主动做，还会影响同事一起做好
23	经常重构代码，同时注意要解决问题的根源。	一直主动这样做
24	在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。	目没有安排时间，我也没有提这事
25	代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。	不但主动做，还会影响同事一起做好
26	和一个实际的用户一起使用软件，获得第一手反馈。	想做但是没有机会
27	在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误	不但主动做，还会影响同事一起做好
28	如果测试没有做完，那么开发也没有做完。	一直主动这样做
29	适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件	不但主动做，还会影响同事一起做好
30	如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。	不但主动做，还会影响同事一起做好
31	测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误?	一直主动这样做
32	（带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜	不但主动做，还会影响同事一起做好
33	（带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。	不但主动做，还会影响同事一起做好
34	（带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。	不但主动做，还会影响同事一起做好
35	（带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。	不但主动做，还会影响同事一起做好
36	（带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。	不但主动做，还会影响同事一起做好
37	（带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。	不但主动做，还会影响同事一起做好
38	（带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？	不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底

二、回答问题

问题一：

我看了这一段文字

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

那么软件工程到底有什么用呢？

回答：

• 软件工程的思想目的和其他学科的工程方法（比如土木工程等）并无太大差异，主要是降低软件系统的复杂性、提高其可控性，以此在软件开发、维护、测试等各个阶段提高效率。
• 让整个软件系统“大而不乱”，井井有条。减少程序员工作的负荷并提高软件需求、设计、开发、测试、维护的效率。

问题二：

我看了这一段文字

从学生到职业程序员，并不是更加没完没了地写程序——花在写代码的时间反而少了许多。

职业程序员的能力比学生强多了，会做的东西就更多了，就会敲更多的代码了。那为什么职业程序员花在写代码的时间反而少了许多呢？

回答：

因为职业程序员任务的质量要求不一样。职业程序员在“需求分析”和“测试”这两方面明显地要花更多的时间。但在具体编码上，花费的时间会比学生少。从学生到职业程序员，并不是更加没完没了地写程序——花在写代码上的时间反而少了许多。

问题三：

我看了这一段文字

在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。

那么敏捷流程到底是什么东西呢？

回答：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。总结如下：

• 不断交付软件以满足客户需要
• 欢迎需求的变化
• 可以工作的软件是进度的主要衡量标准
• 对卓越技术与良好设计的不断追求将有助于提高敏捷性
• 简单——尽可能减少工作量的艺术至关重要

感觉敏捷是态度而不是流程，是氛围而不是方法。

三、再提问题

第4章 两人合作

我看了这一段文字

代码复审就是看代码是否在“代码规范”的框架内正确地解决了问题。

Q1：

那如果开发人员在写代码的过程中就严格按照代码规范来写，做到完美，那此时代码复审不就毫无意义了？复审者本就是在替开发者干开发者本应干的事情，那意味着开发者自己做好的话，复审就没必要了？

第5章 团队和流程

我看了这一段文字

软件团队有各种形式，适用于不同的人员和需求。基于直觉形成的团队模式未必是最合适的。

Q2:

如果要开展一个全新的项目，到底该怎么选择“合适”的团队模式呢？课本中仅仅是介绍了各种模式，但并未教我们到底该如何选择。

第7章 MSF

我看了这一段文字

二柱：软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没那么难，主要靠的还是程序员自身的修养和完成工作的素质。

Q3：

我觉得这段话讲得很有道理啊，请问你怎么看呢？

第12章 用户体验

我看了这一段文字

用户体验设计的一个重要目的就是要降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异。

Q4：

既然用户体验设计的目的就是为了用户，那是不是可以理解为要根据大众的想法来设计？但我们平时使用的一些软件，比如知乎，这些公司对于用户体验设计应该都是很在行的，但为什么在用户体验这一方面会越做越烂呢？
我的问题是，是什么原因导致了这种情况的发生。每次出新版本，每次都会受到用户的大量吐槽，为何会一直在错的路上一直走下去呢。如果在内容和功能上，加入了可以获利的东西尚可理解，毕竟一个公司都是需要收入的。那么UI越做越丑，怎么就不会改回去呢。

第16章 IT行业的创新

我看了这一段文字

不但大众不喜欢创新，甚至连创新者自己都不例外，有些创新者甚至恨创新。

Q5：

我反对作者的这个观点，而且反对作者关于这句结论的一个设想。

作者说：假设你发明了电报，创办了电报公司，并花费毕生的精力建起了覆盖全国的电报网。这时有个年轻的发明家上门推销他的创新——电话。这个早期的电话看起来其貌不扬，后面还拖着一条尾巴。可是你敏锐地看到，这个创新将会颠覆目前的电报产业，它预示着你辛辛苦苦建立起来的电报公司将会失去市场，这是你会怎么想？会不会恨这个发明？

依我的看法，作者的结论是错的。这并不是说有些创新者不喜欢创新或者恨创新，这根本就是利益冲突的问题，是一个创新者的利益被另一个创新者所破坏，不是不喜欢创新或者恨创新。单就创新而言，若创新者不喜欢创新抑或恨创新，那他如何创新？他如何实现创新？他做不了，他根本就不会成为一个创新者。