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

Posted 2020-11-06 ballonbaby

一、个人总结

在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。

（1）

类型	具体技能和面试问题	现在的回答
语言	拿手的语言	很没有底气的回答：JAVA。此外为了程序的测试，学了一点点Python
软件实现	有没有在别人的代码基础上进行改进？ 你是怎么读懂别人的代码？ 遇到的bug是什么，怎么解决？ bug出现的原因，应该如何避免？	1.经常的事情。 2.一般写的规范的代码都是看的懂的，先根据注释大体看一下实现的功能，然后再详细阅读。实现看不懂的就说一句：“兄弟解释一下？” 3.bug会有很多原因，有两种原因最让我头疼。第一点，糟糕的命名导致最后乱成一团。第二点，逻辑问题，这是很要命的本质问题。 4.至于避免，我觉得是因为缺乏经验导致的，需要多累计经验
软件测试	你是怎么测试自己的代码？怎么测试别人的代码？	1.进行JUnit单元测试，市面上有测试工具来进行性能测试、压力测试等等。 2.测试别人的代码，就是先读懂别人的代码，如同转换成自己的东西，再进行同样测试
效能分析	你是如何测量代码效能的	进行多种测试，比如性能测试、压力测试等
需求分析	你做过多少个有实际用户的项目？ 你的项目有什么创新的地方	1.有实际用户的项目是我们目前开发的微信记账小程序 2.他的创新之处在于可以做预算，计划每天的能花费的钱，并根据实际花费（超支或者剩余）对接下来天数的可用金钱进行调整
行业洞察力	你最感兴趣的领域是什么？你分析过这个领域前十的产品吗？请分析一下他们的优劣，你要进入那个领域，如何创新	人工智能吧。最让我印象深刻的是去年底索尼公司只是面向日本市场推出的robodog系列机器狗，每只售价1800美元 。最突出的一点是，该款产品结合AI技术能够准确识别出主人并在互动过程中感知主人的情绪。换言之AIBO机器狗通过传感器能够具备强大的养成能力，感知到主人的喜好并调整自己的性格及互动行为，成为每个主人身边独一无二的AIBO。它的优势是在于不再是冰冷的机器，而是可以让主人对它产生感情，并且进行情感互动。至于创新，应该就是基于人性化的设计尤为关键吧
项目管理	1.你参加过项目管理么？请描述一下两个当下流行的开发方法在你的项目中的具体应用情况。 如何决定各个任务的优先顺序，有什么理论来支持你的做法？ 如果项目不能及时完成，作为项目领导，有什么办法？	这次的软件工程的项目开发最重要的任务之一就是项目管理，我想很多团队包括我们团队，都是采用“主治医师”的团队模式(不排除一些团队用的是"明星模式";在冲刺阶段采用的是敏捷开发。大家各自其职。 2.PM总是在宏观调控大家的任务与进度，优先顺序自然是把最基本的、适合所有人的功能放在首位。 3.如果不能及时完成，那我们就会选择退而求其次，放弃附加功能，尽力完善基础功能
团队协作	描述你在项目中如何说服同伴采取你更好的方案，或是听取别人的意见改进自己的方案，如何说服懒惰的同伴加紧工作，或者如何听取了别人的意见，改进了自己的方案？	没有出现谁说服谁的情况，遇到问题大家都是一起讨论，找到一个好的解决方案，冲刺阶段项目经理及时跟进，让我们顺利赶出进度
理论素养	你上过什么数学，计算机或是理论课，举出具体的例子，如何帮你解决问题	高等数学，C语言，JAVA等，据说算法课程很有用，可惜我没有选，这些课都是很基础的课，编程能力越高冲刺阶段的敏捷开发就越轻松
自我管理	全年级你专业排名多少？你从刚入学（大学一年级）到现在的排名有变化么？如何解释你的排名变化？	1.二十几名 2.大一是四十几名，大二是三十几名，总体来说是在进步的，给自己朵小花 3.用在学习的时间上多了，不再抱着“及格就行”的心理

（2）自我评分很难，我觉得我才刚走进这个"世界"有很多东西要学，无穷无尽

技能	课前评估（0——9）	课后评估（0——9）
对编程的整体理解	3	4
程序理解	3	4
架构设计、模块化设计、接口设计	0	2
模块实现、逐步细化	0	2
单元测试、代码覆盖率	2	6
效能分析和改进	0	4
代码复审/代码规范/代码质量	2	6
JAVA	3	5
WEB	0	2
个人源代码管理	5	6
个人软件过程	5	8

（3）

技能	自我评估（0——9）
对编程的整体理解	4
程序理解	4
架构设计、模块化设计、接口设计	2
模块实现、逐步细化	2
单元测试、代码覆盖率	6
效能分析和改进	4
代码复审/代码规范/代码质量	6
JAVA	5
WEB	2
个人源代码管理	6
个人软件过程	8
需求分析，典型用户，典型场景，创新	7
测试方法、测试工具	5
数据库	5
美术	5
自主学习能力	8
计划任务	9
质量要求，按期完成任务	10
协同工作	10
报告项目状态	10
在第一线写代码的时间	6
写代码的大致行数	5
所写软件用户量	8
所发布软件的质量要求	7

（4）

编号	问题	我的回答
1	保持高标准，不要受制于破窗理论(broken windows theory)[i]。当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。”	不但主动做， 还会影响同事一起做好
2	主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了。	不但主动做， 还会影响同事一起做好
3	经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。	不但主动做， 还会影响同事一起做好
4	DRY （Don‘t Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。	不但主动做， 还会影响同事一起做好
5	消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。	不但主动做， 还会影响同事一起做好
6	通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。	不但主动做， 还会影响同事一起做好
7	设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。	不但主动做， 还会影响同事一起做好
8	估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。	不但主动做， 还会影响同事一起做好
9	图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。	不但主动做， 还会影响同事一起做好
10	有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手	还会学习和使用各种编辑器的扩展。
11	理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。	模式没用
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	（带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？	不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底

二、回答问题

• 问题一

  若一个新的创新的产生会带来好处的同时它又会带来不好的一面，那么我们应该怎么权衡利弊，我们不能说只享受好的一面，至于负面的就避而不谈。书中的例子明显看出了纺织机的好处，那么失业的工人应该怎么办？
  之前我在网上看到这样一个问题：“未来人类的工作会被百分之50的人工智能取代吗？”不管是医疗教育还是金融管理，此刻在各个领域中，正不断有大量案例，来印证人工智能可以在许多岗位上，以更低廉的成本做的比人类更好。就好比在我父母的那个年代，只要外语能力强就不怕找不到工作，但当智能翻译系统从书面到语音，变的越来越进步之后，未来对翻译人才的需求还会剩下多少？以前的教育重点在传递知识，但就这方面，线上智能或者百科往往能做的比老师更好。所以老师的任务也在不断创新，因此教育这个行业在未来可能就从单纯的传递知识转型成学习服务，它的目的是协助同学，帮助他们产生好奇、缓解焦虑、完善人格。而这些服务端时间内人工智能都没有做的比人类更好。但是如果一个行业是纯技术性的、是不需要与人互动的，那这一行就很有可能会消失。那么这件事到底是好的还是不好的？有又谁来为这些技术性人员的事业而负责？

  最近苹果的新广告：“Apple不为多数人，也不为少数人”。视频中，一位叫 Carlos 的盲人鼓手，用 iPhone 写 Po 文，发动态，用的就是一个叫“旁白”的辅助功能。“旁白”是一种基于手势的屏幕阅读器，可以帮 Carlos 在看不到屏幕的情况下，读出屏幕上的每项内容。再结合简易的手势及语音输入，Carlos 就能和我们一样，自由地在网上发布信息了。不仅是“旁白”这个功能，你还能找到针对视力、听力、学习与读写、肢体与活动能力而设计的各种辅助功能。Apple 所追求的创新，不仅是强大的性能和出众的外观。所以我深信，真正的科技创新，应该让每个人都从中受益，当然也包括残障人士。所以在设计产品时，将所有人都考虑在内，从而让每个人都能无障碍地工作、创作、沟通、健身和娱乐。不为多数人，不为少数人，他们产品设计是为了每一个人。我认为这正是一个好的产品设计的精髓。

• 问题二

  我看过的任何一本书中有关创新内容都是在推崇创新，都在告诉我们创新的必要性。虽然现在国内的教育在逐渐转型，但在教育方面学生还是以一种很依赖老师的学习方式来吸收知识，未来的工作方面绝大一部分人也会默守陈规，何谈创新？该怎么做才能改变自己，让自己跳出原本的圈子，锻炼自己以另一种方式看问题思考问题，不断创新呢？

  创新一词早被说烂，但真正要去定义它，必定不是“在很多人已经做得很好的基础上去做得更好”，应该是“在大家都没有想到的地方开拓荒地、做到极致”。这需要想象力、勇气和执行力。去年底索尼公司只是面向日本市场推出的robodog系列机器狗，每只售价1800美元 。最突出的一点是，该款产品结合AI技术能够准确识别出主人并在互动过程中感知主人的情绪。换言之AIBO机器狗通过传感器能够具备强大的养成能力，感知到主人的喜好并调整自己的性格及互动行为，成为每个主人身边独一无二的AIBO。它的优势是在于不再是冰冷的机器，而是可以让主人对它产生感情，并且进行情感互动。创新一词我们在擅长的领域往往会固步自封，被固有的思想所局限，而对于陌生的领域则是怀揣的对未知事物好奇与探索，更加有可能有所创新。所以，我们要接触其他领域，接触另一个圈子的人，学习吸收新领域的知识来丰富自己并且不怕失败的尝试。在这次程序来发中，有一个团队是通过中文解释与英文单词配对的方式来学习单词，即单词连连看。我觉得他们的想法很有创意、很新颖，给朵花花。

• 问题三

  书中没有提到，当一个可能有风险新产品带来的利润会大于成熟产品的时候，公司该如何抉择？

• 问题四

  在书中提到了公司是追求利益的，当一个创新并没有达到预期的利益的、甚至是前期亏损的状态时，创新还要继续吗？在一百年
  甚至几百年前，新事物的产生往往是由个人发明的。所以就算失败，影响的范围和程度是很小的，但是现如今的创新都是由团队甚至更大的团体发起的，可能这个创新是一个好点子，但是由于无法被人们马上接受导致了没有预期盈利甚至亏损，往往对一个公司的影响的不小的，那么还要继续坚持下去吗？

  问题三和四放在一起回答。其实这个问题我现在也没有想明白。可能每个企业都有自己的评估规。个人猜想是，对于大公司而言，如果一个新的项目风险过大，即使未来会带来很大的利益，这个新项目也不会实行。但对于个体（即一个人），需要经历太多不得已，最后才能有所得——甚至，还有一无所有的风险。这次是人生。（突然扯远了……）

• 问题五

  有很多种团队合作方式。我的问题是：我们需要尝试着其他团队合作模式吗（尽管我觉得并不适合）

  可以小小尝试一下，首先没有人会蠢到选择一个完全不可行的方式执行，干嘛要折磨自己折磨大家呢？那么就算换一种团队合作方式也应该选择一种看起来最可行的团队合作方式。如果发现并不合适，立马换掉。拒绝纠结！拒绝拖拉！！

• 问题六

  我很好奇学校是怎么选择我们将要学习的编程语言的？是继续学习这个基础的、一定有用的东西，还是会随着改变用热门的语言替代某些基础语言，亦或者这些语言我们都要学习？我们之前学的数据结构的课程到底有什么作用呢？

  经过Alpha阶段之后，对这个问题有了答案。学习各类语言才能知道自己适合什么。在不确定自己的就业方向时应该广泛学习，在有了方向之后，则应该有所侧重。在此次的微信小程序开发中，我发现不同小组用不同的编程语言进行前端后端的开发，比如Python、Java等等。所以说无论什么语言，学精是很重要的。

三、再提问题

• 问题一

  第十二章——用户体验。在P159——P164，强调了用户对产品第一印象的重要性，要从用户的角度考虑问题，以及设计的时候不要让用户出现简单的错误，且强调了记住用户选择的重要性。我觉得说的很对，就好比如果我在某个阅读APP上多次读了天文学类的文章，那么这个APP就会自动为推送我天文学类的文章。这真的是很棒的功能。但是在本次项目开发出现了有关“用户体验”的问题。我们开发的是微信记账小程序，我们记账小程序与其他的记账小程序的不同之处在于，我们的侧重点在于规划未来消费。我们有添加计划的功能。选择未来多少天有多少预算，系统就会自动计算平均每天可以花费的金额，如果今天花的钱超出了预算，系统重新计算后未来平均每天可以花的钱就少，反之同理。我本人是非常喜爱这个功能的，但是用户体验效果不好，因为他们不了解这个功能，导致操作的时候出现了很多问题。如果用户一开始体验就不好，三分钟之内他们就会跟这个小程序say goodbye。我的问题是：那作为开发人员要怎么才能良好避免解决用户体验时可能会出现的状况？

• 问题二

  依旧是第十二章——用户体验。

  在P160提到了“要从用户的角度考虑问题”。但是不同用户终归是有不同需求的。拿我们的小程序举例子，因为我们的小程序侧重点在于规划未来消费，所以和其他组的记账记账小程序相比，我们的记账功能比较简单化。有些用户很喜欢这样的简单设计，有一些用户却想要更丰富的功能。就在昨天我在微信小程序里发现“鲨鱼记账”，它有着简单的记账基本功能，如果需要更多地功能，就需要下载他们的APP。

  我的问题是：如何满足不同用户的多种不同需求？是要像“鲨鱼记账”那样有给用户提供多种选择（选择简洁功能的微信小程序或者复杂功能的APP）吗？这样不是会浪费更多精力和资源吗？

• 问题三

  书上P117讲述了“敏捷流程和解法”。

  书中提到“问题未必能在短时间内完成，然而时间不等人，那么程序员会冒着风险先尝试着在某些平台上实现——也许以后要返工”。

  我的问题：书中提到的敏捷开发会出现的问题我们也遇到了。预计的是两周的时间，但其实我们在两周以前就开始行动了，虽然“勉强”将小程序上架了，却还是没有达到理想的目标，甚至是还有一些基本功能没有实现。问题就出在我们没想到中间过程中会出现很多问题，然而修复完错误之后所剩的时间就寥寥无几。（折磨人的敏捷开发！！！）在成果演示的时候，我发现自己组还算是比较优秀的，有很多组没有上架亦或者上架后漏洞百出。因此高敏捷开发的认知是：“是对技术要求提高了，而不是降低了”。这种提高不是那种满口天花乱坠的理论式的提高，而是写最基本的代码上的能力提高。那么敏捷开发的意义是什么？为什么不能心平气和的做完一个优秀的项目？如果组成员能力都不高那么敏捷开发会很吃力，那么他们是不是不适合敏捷开发？如果规定时间内没有做完理想的任务，是延长冲刺的时间，还是尽力而为就好？

• 问题四

  这个问题是我对某个组开发的APP产生的疑问。

  第八章《需求分析》，谈到用户需求性分析，也详述了“NABCD”

  书中说道一个程序的开发，要考虑到用户“最需要的东西”，要展现自己程序的独特之处。在竞争分析需求中，我们要看清楚我方的优势和劣势。

  问题：某一组开发的是一个能查询快递的APP（可以扫码，语音输入单号，或者键盘输入），看起来没什么问题，但是仔细一想，现在很多购物平台不都是在哪儿买就能在哪里查到吗。做为用户我为什么要为了查快递download一个APP？退一步讲，就算我并非在购物软件上买的东西，我为什么不能直接在网站上查询而要下载一个APP？相比之下，我觉得如果设计成微信小程序会更加便捷一些。最后一点，语音功能是什么鬼？我能一口气说那么长的单号吗……

  对这个组并没有恶意，更没有江湖恩怨哈哈，仅发表小小意见。

• 问题五

  第十三章《软件测试》，P282-P283提出了多种测试。在本次程序开发中，我是“测试员”的身份。我认为，功能测试时比较容易评估的，比如单元测试。相对来说功能测试会比较复杂，例如，压力测试中，我们的小程序可支持百人以内的用户同时运行。但是不能再多，那么问题来了，这算质量不过关吗……不能吧，毕竟我觉得100人足以，怎样才能定义这个软件的质量……纠结。

• 问题六

  说一个和本书无关的小小的事。
  最近我们组PM很生气，她一直在碎碎粘：“这不科学，我们组所有内容都是自己做的，评分却比不过别人在网上‘借鉴’的，他们这个代码很有问题……明明某某组程序一堆bug，他们竟然没有看出来，balabala……好气”。
  emmmmm，我觉得很多人在评分的时候，是只关注的界面好不好看，并没有细想功能实现问题……有些程序没上架的我们也测试不了，只能看看他们的截图……另外如果不同类型的程序分开评是不是会更好？（游戏、小程序）