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

一、个人总结

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

类别	具体技能和面试问题	现在的回答
语言	最拿手的计算机语言之一,代码量多少? (偏web前端，PC/Mobile App)	Java，大概应该有一万吧
语言	最拿手的计算机语言之二,代码量多少? (偏后端，数据处理，网站后台，机器学习，等)	c++，大概五千？
软件实现	(阅读代码的能力，实现，单元测试) 你有没有在别人代码的基础上改进，你是怎么读懂别人的代码的，你采取了什么办法来保证你的新功能不会影响原来的功能 ?你在开发中碰到最复杂的bug 是什么，你是如何解决的?这个bug 出现的原因是什么，你在将来应该怎么去避免bug 再出现?	有在别人的代码上改进，读懂别人的代码首先要清楚各个类，变量的含义，其次通过注释理解代码，要是没有注释的话读代码就比较吃力。新开发的功能最好单独做一个模块，尽量避免有所交集，实在无法避免需要仔细缕清代码，不能有二义性，影响原有功能。开发较少，还没有碰到很复杂的bug。
软件测试	(测试方法、测试工具、测试实践、代码覆盖率)你如何测试你自己写的代码?你如何测试别人的代码?你掌握了多少种测试工具和方法?你写过测试工具么?你如何对一个网站进行压力测试和效能测试?你如何测试一个软件的人机界面(UX/U1)?	通过自己写测试代码，eclipse有自带测试工具，其他没用过，也没写过测试工具，不懂。
效能分析	效能分析，效能改进,你写过的最复杂的代码是什么? 你是如何测量和改进它的效能的，用了什么工具，如何分析的?	没写过
需求分析	(需求分析，典型用户，场景，创新)你做过多少个有实际用户的项目，用户最多有多少?你的项目有什么创新的地方?	做的项目没发布过，最近做的记账小程序发布了，目前用户应该有20，因为还在开发阶段，创新的地方还没写出来。
行业洞察力	你最感兴趣的领域是什么? 这个领域过去10年经历了哪些创新?你分析过这个领域前10名产品么? 请分析一下他们的优劣，你要进入这个领域，应该如何创新?	web前端技术，主要是网页设计的核心技术--HTML、CSS和JavaScript
项目管理	你参与过项目管理么? 请描述一下两个当下流行的开发方法在你的项目中的具体应用情况;请问你如何决定项目中各种任务的优先次序，有什么理论来支持你的做法如果你突然发现项目不能按时完成，你作为项目领导，有什么办法?	最新的项目使用敏捷开发，目前alpha阶段已经完成，刚开始beta阶段。各种任务的优先次序取决于项目的进度和任务的紧迫程度。
软件设计	你做过架构设计，模块化设计，接口设计么? 请说明一下你为何是这样设计，你比较过什么不同的设计方式，你的设计取得了什么结果?	做过设计，以架构为中心，功能模块化，具体到接口、类。
质量意识	(代码复审/代码规范/代码质量) 你是怎么做代码复审的，你加入我们团队后，能帮我们提高代码质量么，请具体说怎么提高?	检查是否符合代码规范，检查代码的重复率，检查是否代码具备其功能。
工具/社区	Software Tools (performance tool,version control,work item,TFS)你在各种开发平台(web,linux,PC,mobile,machine learning) 都使用过什么样的工具，自己写过什么工具来改进工作效率?给社区贡献过什么工具和代码? Github有分享代码么?你写的技术博客坚持了多久，读者最多的是哪一篇?	vc6.0，vs2015，eclipse，微信web开发者工具、devC++等，代码有上传至git。大二开始有写博客。
团队协作	Work with others (协同工作，提供反馈，说服别人)请描述你在项目中如何说服同伴采用你提出的更好的解决方案，或者你如何听取了别人的意见，改进了自己的方案?你如何说服懒惰的同伴加紧工作，实现团队的目标?	我会列举出我提出的方案的好处，以及原有方案的劣处，别人的意见好仔细思考，真的有用要听取改进。同伴懒惰时，要以身作则，指出我们共同的目标，鼓励他。
理论素养	你上过什么数学，计算机或其他理论课，请举出具体的例子，说明你学到的理论知识如何帮助你解决实际问题	高等数学、离散数学、线性代数、概率论、数字逻辑等，太多了，也想不起来具体帮助了我什么，但是我知道一定有用。
自我管理	全年级你专业排名多少?你从刚入学(大学一年级) 到现在的排名有变化么?如何解释你的排名的变化?	二十几吧，排名基本没大的什么变化，但是还是有所浮动。与掌握的知识技能有关，还与考试的状态有关？

二、回答问题

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

Q1：初级软件工程师如何成长？什么是好的软件设计思想？什么是好的软件工程思想？

软件工程师可以如此成长
- 我认为，初级工程师之所以为“初级”，是因为本身能力有限，那么就需要打磨自己的专业，“较小的领域”更容易做出让人印象深刻的成绩，作为初级工程师，要在较小的领域精益求精。
- 第二点是不懂就问，虚心求教。没有人一开始就什么都懂，都是一点一滴积累起来的知识。听来的学问一定要和实践结合，深刻理解并运用才算真正的掌握。
- 第三，要能有效管理自己的工作，最好是有一套指标来衡量，越是有明确的指标，就越有能力推动研发的行为。
好的软件设计思想

软件设计是从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。

好的软件设计思想是能够把上面提到的任务很好地完成并连接在一起，从一开始就必须想好怎么实施，将问题或事物分解并模块化使得解决问题变得容易。

好的软件工程思想
还是有四个要点：迭代开发、以系统架构为中心、持续的质量保证以及管理变更和资产。要做就要做一个有“生命力”的软件，不断修复bug，更新版本，注入新的活力软件才能存在得更久。

Q2：结对编程会出现的问题

我认为结对编程的利弊还是因人而异了。结对的双方若是编程水平差太多，或者两人根本不熟悉也不了解对方的编程习惯，结对编程的作用很明显就会弊大于利了。当然在工作中一般不会出现水平相差太多的情况，毕竟能成为同事也是不容易的事呢。如果说为了长远的利益，结对编程是必要的，那么就有必要花些时间去磨合了，不管是以什么样的方式。
反之，结对编程的好处就会多多了。就如书上提到的那样：

在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。

Q3：在稳定和发布阶段，无关大局的缺陷非得马上解决吗？修正方案中又有缺陷怎么办？

到了稳定和发布阶段，软件已经成型，bug一直都有，有的可以解决，有的目前无法解决，自己也经历过了敏捷开发，明白其实无关大局的缺陷不必马上解决，尤其是快要发布的时候，那时可能做不到修正缺陷后再发布，所以可以等到适合的时机再行修改。软件都会有迭代，一般来说，每次迭代，都会修复已发现的bug，或是新增其他的功能，对用户来说，最重要的是要有良好的体验，在不影响这一目标的情况下应当允许某些bug的暂时存在。前面也说了，bug总是会有，世上没有完美的东西，也不会有完美的软件，给你完美的感觉只是当下，只是浅层面的，后面迭代的至少都会比之前的版本好。

三、再提问题

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

Q1：书本P16提到很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。

我认为“Bug”也是因人而异的，对某些人来说是缺陷，对某些人来说这正是特点。就如书上举的例子，裤腿上有洞的牛仔裤，像是年轻人就认为这很fashion，没什么问题，而“老年人”就认为有洞是质量不好，应该拿去退换。汽车有那么多品牌，各有各的好，有些人注重性能，有些人在意外观，等等，在他们眼里“好”是不同方面的，而销售人员就需要针对不同需求的用户推销适合他们的产品，结果才是皆大欢喜，否则最后销量未必理想。

Q2：书本P79提到谁来做代码复审？即最有经验、熟悉这一部分代码的人。

最有经验、熟悉这一部分代码的人难道不是开发者本身吗？复审者是在替开发者干开发者本应干的事情那么是否需要安排专门的人来做代码复审呢?

Q3：书本中第五章列举了很多团队模式：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式等等。

这么多模式，怎么清楚定位自己的团队是什么模式呢？而且我认为每个阶段的模式可能不一样。

Q4：书本P122提到敏捷对团队的要求和简单：自主管理（Self-managing）、自我组织（Self-organizing）、多功能型（Cross-functional）

事实上我们大学生还不能算一个成熟的团队，敏捷开发对我们来说很困难，每个人毛病挺多，能力也不强，所以老师让我们敏捷冲刺，也只是在时间驱动下完成项目而已。或许老师只是让我们体验一下敏捷开发的流程，但是我们真的能有所感悟就好了。就如书上所说：

如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要经历多次失败/总结/改进的过程才能让Scrum走上正轨。

Q5：书本P281提到的“灰箱”是什么？我们该怎么选择白箱、黑箱、灰箱呢？

所谓白箱就是机制和结构完全明了的系统，如同电视机对电视发明制造者来说就是“白箱”。

所谓灰箱，就是相当部分的结构机制已经明了，但并没有完全明了的系统，如电视机对一个并不高明的修理者来说就是“灰箱”。

所谓黑箱就是结构机制完全不明了，仅仅知道输入输出信息之间某些简单关系的系统，如电视机对一个根本不懂电器的用户来说，他只知道打开钮就亮、闭掉钮就灭一样。