软工网络15我的做业4——alpha阶段我的总结

时间 2020-06-21

原文原文链接

1、我的总结

在alpha 结束以后，每位同窗写一篇我的博客，总结本身的alpha 过程；
请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。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	（带领团队）团队中每每会有矛盾产生，做为领头人，怎么办？	不但有明确和一致的处理原则，并且对于影响团队士气的任何事情追究到底

2、回答问题

问题一数据库

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

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

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

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

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

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

问题三和四放在一块儿回答。其实这个问题我如今也没有想明白。可能每一个企业都有本身的评估规。我的猜测是，对于大公司而言，若是一个新的项目风险过大，即便将来会带来很大的利益，这个新项目也不会实行。但对于个体（即一我的），须要经历太多不得已，最后才能有所得——甚至，还有一无全部的风险。此次是人生。（忽然扯远了……）
问题五

有不少种团队合做方式。个人问题是：咱们须要尝试着其余团队合做模式吗（尽管我以为并不适合）

能够小小尝试一下，首先没有人会蠢到选择一个彻底不可行的方式执行，干吗要折磨本身折磨你们呢？那么就算换一种团队合做方式也应该选择一种看起来最可行的团队合做方式。若是发现并不合适，立马换掉。拒绝纠结！拒绝拖拉！！
问题六

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

通过Alpha阶段以后，对这个问题有了答案。学习各种语言才能知道本身适合什么。在不肯定本身的就业方向时应该普遍学习，在有了方向以后，则应该有所侧重。在这次的微信小程序开发中，我发现不一样小组用不一样的编程语言进行前端后端的开发，好比Python、Java等等。因此说不管什么语言，学精是很重要的。

3、再提问题

问题一

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

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

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

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

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

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

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

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

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

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

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

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

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

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