个人作业4--Alpha阶段个人总结

一、个人总结

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

类型 具体技能和面试问题 现在的回答 毕业时找工作
语言 最拿手的计算机语言之一(偏前端),代码量是多少 js,代码量大概2,3千左右
语言 最拿手的计算机语言之二(偏后端),代码量是多少 java,代码量大概1万左右
软件实现 有没有在别人的代码基础上进行改进,你是怎么读懂别人的代码的,
你采取什么方法来保证你的新功能不会影响原来的功能,
你在开发中碰到最复杂的bug是什么,你是如何解决的?
这个bug出现的原因是什么,你在将来应该怎么去避免bug再出现
1.有,可以说满经常;
2.读懂别人的代码分两种情况,一种是写代码的本人在你旁边(这是目前比较常见的情况),最简单的办法是直接问写代码本人代码写了什么。
另一种是写代码本人你问不到,这就首先要根据代码的注释,其次根据函数命名可以大概知道函数的功能,最后是运行一下,看运行结果也能知道代码在写什么;
3.大的框架不变,只修改要改进模块的代码,函数的返回值如果有修改,调用函数的地方都要相应修改
4.遇到的bug有的是原有代码就存在的bug,有的是改进的代码与原有的代码函数结果不一致。解决的办法可以直接写几句输出代码,看看问题出现在哪个范围的代码,如果是Java写的,可以用Java的调试,就可以一步步看代码的运行结果。
测试软件 你如何测试自己的代码?
你如何测试别人的代码?
你掌握了多少种测试工具和方法?
你写过测试工具么?
你如何对一个网站进行压力测试和效能测试?
你如何测试一个软件的人机界面(UX/UI)?
1.测试自己代码就可以先写测试用例看看能不能得到自己想要的结果,或者使用测试工具,比如java自带的测试工具,JUnit单元测试和代码覆盖率,效能分析可以用JProfier(但是其实这个软件的测试结果,我分析起来还是蛮费劲的)
2.测试别人的代码,主要要先懂得别人的代码,其他的测试跟测试自己代码是一样的
3.目前掌握的测试工具有Java自带的测试工具,测试方法有测试用例,代码覆盖率,可以在需要测试的代码,写一些输出代码,可以看代码运行到哪
3.没有写过测试工具,因为也是学了软工才对测试有概念
4.我还没有写过可实际运行的网站,所以也没有进行过压力测试和效能测试
5.没有进行过真正的人机界面测试
效能分析 你写过的最复杂的代码是什么?你是如何测试和改进它的效能的,用了什么工具,如何分析? 1.我写过最复杂的代码就是学生选课系统,因为整个系统都是自己做的,时间就只有一周,考虑的问题有很多,比如,有多名选课数据的刷新,重复选课等。2.那时候还不懂得使用测试工具,写完后能运行出想要的结果就结束了。现在的话,会使用测试用例进行测试,用JProfier进行效能分析。
需求分析 你做过多少个有实际用户的项目,用户人数多少,你的项目有什么创新的地方? 目前有实际用户的项目就是我们现在团队开发的i词汇,现在目前的用户数量为43人。项目的创新在于把游戏与学习相结合,既能玩游戏又能学习,还能起到复习单词的作用
行业洞察力 你最感兴趣的领域是什么?这个领域过去十年有哪些创新?
你分析过这个领域前10的产品么?请分析一下他们的优劣,你要进入这个领域,应该如何创新
我最感兴趣的领域是微信小程序。微信小程序是比较新的东西,也是近几年才发展起来,与一开始的开发工具相比,现在的开放工具已经友好很多了。要是它的开发工具的有代码调试或者报错了可以指向错误的代码就好了
项目管理 你参加过项目管理吗?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况
如何决定项目中各个任务的优先次序,有什么理论来支持你的做法?
如果你突然发现项目不能按时完成,你作为项目领导,有什么办法?
1.参加过项目管理。开发项目具体使用过的有主治医师模式和敏捷开发。主治医师模式在项目开发过程中一旦主要开发人员没有进展,整个项目基本跨了,而敏捷开发,是大家一起开发,各有各的任务,周期也比较短,大家的积极性也比较高。
2.项目的任务的主次是根据团队定义的MVP,属于MVP版本的就是主要任务,不属于MVP的任务属于次要任务。因为敏捷开发就是先做出各可交付的版本。
3.如果突然发现项目不能按时完成,第一先寻求别人的帮助,如果还是很紧急,你那就调整项目的时间安排,通过增加工作时间来保证完成任务。如果觉得还是不能按时完成,就让开发不是MVP版本功能的开发人员重新分配还未完成的任务。
软件设计 你做过架构设计,模块化设计,接口设什么?请说明一下你为何是这样设计,你比较过什么不同的设计方式,你的设计取得什么结果? 我做过接口设计,这样设计首先让代码看得很清楚,其次减少代码的冗余。我还未使用过其他设计方法,所以无法进行比较
质量意识 你是怎么做到代码复审的,你加入团队后,能帮助我们提高代码质量么,请具体说怎么提高? 从代码是否符合需求和规格说明,设计是否考虑周全,代码可读性高么,代码容易维护么,代码的是否有错误处理、边界处理、资源利用等,代码的效能如何等方面进行代码复审。提高代码质量首先要有代码规范,其次要减少代码冗余,对代码进行模块化设计和接口设计,做到一个功能写一个函数,一个函数不要含有很多功能。
工具/社区 你在各种开发平台都使用过什么工具,自己写过什么工具来改进工作效率?给社区贡献过什么工具和代码?Github有分享代码么?你写的技术博客坚持了多久,读者最多的是那一篇? 还未在开发平台使用过工具。主要是用码云来分享代码。写技术博客两年了,读者最多的篇章是201521123005 《Java程序设计》 第九周学习总结
团队协作 请描述你在项目中如何说服同伴采取你更好的方案,或是听取别人的意见改进自己的方案?你如何说服懒惰的同伴加紧工作,实现团队的目标? 我先讲一下我的方案是什么,然后讲我的方案有什么优点,为什么我要采取这种方案,与同伴互相交流彼此的想法。别人的意见,首先要听懂并理解,根据自己方案的特点与需求,看是否要采纳别人的意见,多与别人多交流,如果没有采纳别人的意见也要说出原因
理论素养 你上过什么数学,计算机或是理论课,
请举出具体的例子,说明你学到的理论知识如何帮助你解决实际问题。
1.大学学了高等数学、概率论、数学逻辑、离散数学等
2.哪最简单的例子,数学逻辑学的,逻辑与或在写MD5算法的时候就很好的运用,用最简单的式子来表示算法过程,需要用与或表达式来化简。
自我管理 全年级你专业排名多少?
你从刚入学(大一年级)到现在的排名有变化么?
如何解释你的排名的变化?
1.我的专业排名波动比较大,目前专业排名第7。
2.有变化。
3.大一大二学的更多的是基础课,专业课比较少。大一大二参加的社团也比较多。大三专业课比较多,花在学习上的时间也比较多。

二、回答问题

我们在课程开始之初,曾经要求大家针对软件工程提出问题:个人阅读作业2,那么在经过alpha阶段,大家是否对软件工程有了一定的了解?请结合自己提出的问题进行回答
个人阅读作业2

Q1、通过好的单元测试就能说明程序是好的吗?

经过alpha阶段,实际测试后发现,通过好的测试单元虽然不能说明这个程序都没有问题,但是它可以找出程序很多bug。项目本身就是一个不断的找bug,修复bug的过程。可以这样说没有完全没有bug的项目。现在我们也知道有些bug不是bug,而是项目本身就是如此设计的。所以好的测试单元还是很重要的,不要太纠结于它是否可以判定一个程序的好坏。程序的好坏应该进行效能分析,才更有信服。

Q2、有关敏捷流程的问题--如果在第一步没有计划好,是否导致整个项目的失败?

敏捷冲刺的好处就是它快,在Alpha阶段开发出MVP版本就可以,然后在进行不断的迭代。所以第一步没有计划好会影响Alpha阶段的具体事项,但是Alpha阶段结束后它有一个总结,可以总结在第一阶段没有计划好,或者可以改进的地方,然后再进入Beta冲刺极段,这样其实对整个项目的影响不会严重到失败,可能会影响项目的进度。

Q3、对于软件测试方法的理解--对于现实生活中的项目,这十三种测试都需要一个个测试吗?

关于测试真的要应项目而异,因为不同的项目有不同测试要求。拿我们团队Alpha阶段的MVP版本来说,因为这个项目在Alpha阶段还未连上数据库,那还要进行服务器、数据库的测试吗?显然就没必要了,即使你测试了得出的结果也是无用的。比如测试数据库的性能,你都没有进行数据库操作,如何测试?测试方法的存在提供了测试的方向,可以让刚学习测试的学员,知道可以测试什么,用什么测试,测试的结果如何分析。

三、再提问题

同时,大家一定会在实践过程中产生更多问题, 结合你的读书(教材,博客,参考书), 实践, 再提出关于软件工程的 5 个问题。

在每个问题后面,请说明哪一章节的什么内容引起了你的提问,提供一些上下文。
列出一些事例或资料,支持你的提问 。
说说你提问题的原因,你说因为自己的假设和书中的不同而提问,还是不懂书中的术语,还是对推理过程有疑问,还是书中的描述和你的经验(直接经验或间接经验)矛盾?
一个模板可以是这样:
我看了这一段文字 (引用文字),有这个问题 (提出问题)。 我查了资料,有这些说法(引用说法),根据我的实践,我得到这些经验(描述自己的经验)。 但是我还是不太懂,我的困惑是(说明困惑)。【或者】我反对作者的观点(提出作者的观点,自己的观点,以及理由)。

Q1、针对大学生的项目开发PM的角色是否适用?###

本书第194页,作者提到

PM做开发和测试之外的所有事情

但是经过Alpha阶段,我发现PM在团队项目开发的过程中还是需要做开发的事情。因为团队成员没办法做到每个人都有能力完成开发的事情,冲刺阶段时间也赶,没办法空出一个人去只做PM的事情。团队成员较少的情况下,只能一人承担多个角色。就拿这次冲刺阶段,我们团队没办法安排出一个专门做测试的人员,队员大家前期都是做开发的事情(包括PM),后期才转去做测试的。所以导致了PM要做的事情很多。如果有的团队的成员不给力,会不会最终项目都是PM一个人完成。这样不就会出现主治医师模式的弊病吗?
作者在书196页回答了问题:

如果PM也来开发,是不是项目进展更快?

作者的回答是

在软件行业发展初期,软件都是为了维持机器本身的运行服务,或是做科学计算,这时候也许看不出PM的作用。随着产业的发展,软件应用的深度和广度、软件的复杂度、软件团队的复杂度都有极大地提高了,这时候我们需要一些人,起到沟通、交换、影响、润滑、讨价还价的作用--就像商业社会的金钱一样--PM就是这样的角色。

我认为作者没有回答到点上,这个问题问的是PM还可承担开发的事情,来加快项目的进展,而不是问PM的重要性。我觉得在大学生开发项目,PM相当于一个小组长兼开发人员。因为PM需要对技术熟悉,你也没办法让一个不会写代码来承担PM的角色。

Q2、如何提高估计能力?

本书第181页,作者提到

这时候,我们可以考虑参考前人的经验,打听一下当地人跨越大峡谷要几天。

我第一次看到这章内容的时候觉得说得挺有道理的,就像我们做课设的时候,问一下上一届的学长学姐,也可以大概对项目有一定的把握。但是我们团队这次做的是微信小程序,因为这个技术比较新,有关这方面可以参考的资料,或者人比较少。
作者还说到

即使和你具体情况有种种区别,还是可以作为参考,例如你想徒步走遍全国,貌似前无古人,但是不妨看看一个骑自行车走遍全国的例子。

这种情况就好比我们数据库的搭建。我们首先网上找了有关数据库连接的资料,可以说很少有人亲切的写具体如何连接,相当于前人参考经验几乎为0。那就参考类似的比如用java连接数据库,这个我们做过,觉得还挺简单的,数据库选的是MYSQL也接触过。根据这些经验,我们团队计划连接数据库最多两天就可以了吧。结果与计划大不相同。造成这样的结果,是我们高估自己的能力。所以光是参考前人的经验是不够的。
作者又说到

另一个办法是快速原型法--用一两个先锋去探路。

首先对大学生很不友好,大学生做项目的时候选择课题时候,并没有那么长的时间让你去试哪个项目的成功率更高。大家选的时候一般是先考虑项目内容而不是技术。然后选了课题后,真正要开发的时候才发现,哎呀这个技术好难啊,做不下去了。对于这种对技术了解不到位,没有很好的前人参考经验,如何去估计任务时间呢?

Q3、及时发布一个能够解决用户问题(应该说部分问题)的软件,用户愿意使用吗?

本书第180页,作者提到

所有软件公司都希望在修正所有缺陷之后才发布软件。但是,第一,什么叫“缺陷”?如果只是一些无关大局的问题,用户可以绕过去的,我们非要马上解决么?第二,什么叫“改正”?如果修正方案又有“缺陷"怎么办?做商用软件的人都是为此苦恼,只有优秀的软件公司能够找到一个平衡点,及时发布解决用户问题的软件,并且能及时修改软件中的问题--注意,这两个"及时"并不一定是同一时间。

如果为了及时发布,发布了一个满足部分用户的软件(比如书中提到的没有复制粘贴功能的iPhone),用户用了以后还会满意吗?我想起曹老师跟我们说的一个例子。他说他有个朋友开公司的,他说开发软件就是要先开发出开胃菜,先稳住客户,然后再端出满汉全席。可是,用户用了你的开胃菜,还会期待你的满汉全席吗?用户用了以后,还会想再用你的软件吗?

Q4、工程师有可能高效地开发一个顾客不喜欢的软件,那么这位工程师还是优秀的工程师吗?

本书第36页,作者提到

PSP的目的是记录工程师如何实现需求的效率,而不是记录顾客对产品的满意度。工程师有可能很高效地开发一个顾客不喜欢的软件(例如用户界面很差,功能未能解决用户实际问题,等等),那么这位工程师还是优秀的工程师吗?

我不知道这是作者对读者的问题,还是他觉得工程师有可能高效地开发一个顾客不喜欢的软件,那么这位工程师不是优秀的工程师。但是,从角色分工来说,一个软件开发不单单只有开发人员还有需求调研人员,测试人员,PM等,而开发人员就是专心写代码的人,他是不负责除开发以外的事情。工程师开发出一个用户不喜欢的软件,也不能说是工程师的错,不应该把需求分析错误的问题扔给没有进行需求调研,只是根据需求规格说明书安静的写代码的工程师。从企业来说,能高效的开发软件的工程就是他们所需要的,就是优秀的工程师那么一个工程师高效率的开发一个软件,不就说明他是一个有优秀的工程师吗?

Q5、关于IT行业的创新之创新就是冒险家?

在书的第16章,作者说了有关创新的八大迷思,在书347页,作者提到

谁不喜欢创新呢?然而细细想来,创新就是做和以前不一样的事情,那并不是所有人都喜欢”不一样“

归根结低,都是要看创新出来的”不一样“是否符合自身利益。这不意味着你的创新有可遇到失败。就像移动公司走的TD-ScDMA的技术,理论上这个技术是很优秀的,但是移动公司推行开始技术就不成熟,又有很多新的技术出现,如4G、WLAN。这不就意味着,创新是有风险的。

但是在书347页,作者提到

其实根据研究,创新人士的关键点不是喜欢冒险,也不是躲避风险,而是从错误中恢复继续努力,就像文言文说的”屡战屡败“。

如果对于一个可能性几乎为0的创新,还要继续坚持下去吗?我们现在知道创新成功的例子都是创新成功后,大家才知道的,但是还有很多创新后就失败的真实案例。大家都一味的追求创新,是否是正确的?既然创新大家都想要,那么为什么教育又是应试教育?这是否意味着,创新是冒险?

【附加题】

请将问题提交至豆瓣:https://book.douban.com/subject/27069503/,
并在博客中给出链接在豆瓣页面的最下方 “读书笔记” 那里发言, 《构建之法》的作者会亲自答复问题

链接:https://book.douban.com/annotation/54370216/

原文地址:https://www.cnblogs.com/yangxy/p/9033260.html