之前提出问题的博客：[BUAA2017软工]个人作业week-1
1.请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
问题1
在第三章软件工程师的成长，有一个很重要的理念，“过早优化是一切罪恶的根源”。所有的提前（换成了“提前”一词，感觉“过早”本身含有贬义）优化都是不对的吗？优化不仅仅是对效率的提升，还有对于一个模块的简化。一段代码写得比较复杂，程序员将其进行了优化，优化后的代码变得更加简洁易懂；或者一段代码有一种情况没有考虑到，程序员进行了优化，代码的质量更高了。这样的优化为什么不值得提倡呢？
在团队项目里，我对“过早优化是一切罪恶的根源”这句话有了更深的理解。首先，什么时候开始优化，什么时候不应该进行优化，这个是没有明确的区分界线的，一切都要看具体的项目情况。在团队项目的α阶段里，我是负责前端工作的，因为我比较熟悉前端的jQuery，所以刚开始的时候我用jQuery来写我负责页面的整体框架。一共写了两天，这两天期间，除了完成基本的模块和调用以外，我还做了一些优化，比如数据的获取和存储，怎样设计变量才能让后面的工作更加方便，以及什么样的组件更加好看，组件用什么样的形式，组件的位置具体是什么样的。在这些工作上我花费了许多精力，凌晨两点多的时候突然想到了一个不错的点子，还下床开机调试。但是，后来得知了前端要用vue.js框架，和我的jQuery框架冲突，也就是说我这两天所做的一切优化都没用了，白白浪费了两天时间。那时我突然就想到了这句话，“一切罪恶的根源”。对于一部分代码，你还不能确定它最后是否会派上用场，就开始盲目的对这部分代码进行优化，只是浪费时间和精力而已。如果这部分代码最后发挥它应有的作用了，优化工作固然是值得的。但是如果这部分代码没有派上用场，那你的损失只能通过后期更高的效率和更长的工作时间来弥补。
问题2
在第九章项目经理，我知道了一个优秀的项目经理需要许多“软实力”，比如沟通能力，对流程的把控，和不同角色的沟通与合作，但是这些能力是不会天生就具有的，需要后期不断的在实践中磨练。但是许多技术人员，比如开发人员、测试人员，他们每天与代码和程序打交道，很难获得锻炼这些能力的机会，那么是不是也就意味着技术人员想要成为一个优秀的项目经理相对团队的其他角色很难？如果很难，我们又希望项目经理也能够懂技术，那么这种人才是不是更加稀少？
不得不说，优秀的懂技术的项目经理和有着良好团队协作能力和沟通能力的技术人员在任何时候、任何企业都是需大于供的。想成为这样的人才也需要很多的项目经历来磨练。但通过这一系列项目，我明白了我在学期初提问时的思维误区在哪里了，“比如开发人员、测试人员，他们每天与代码和程序打交道，很难获得锻炼这些能力的机会”，提问时的这个想法是错的。对于一些项目经理特有的能力，比如对整个项目的把控，设计产品的功能等，技术人员很难获得，但是问题里提到的其他的一些软实力，“沟通能力”，“和不同角色的合作”，这些是一个优秀的技术人员不可或缺的。在结对项目阶段，我们95%的代码都是在两人注视下共同完成的，在写一行代码或者一个函数时，我需要把我想实现的功能说给我的伙伴听，他理解后也需要把他的看法说给我听，这个函数有没有必要？之前几个函数的组合是否可以实现这样的功能？这样写会不会给单元测试增加难度？在判断数独是否多解的时候，我俩还在“重新写一个判断模块还是在之前的模块上进行修改”这个选择上产生分歧。结对项目里遇到的所有问题都需要两人通过沟通来解决。在团队项目期间，在实现PM布置的功能任务时，遇到问题或者想到更好的解决方案需要及时反馈给PM。在α阶段我是负责前端工作的，和另一位负责前端工作的同学需要经常的讨论一些技术上的细节。β阶段里，因为我是转会过去的，环境的搭建和技术的细节我都不太理解，要经常向PM团队的其他成员请教。在商业开发中，没有什么个人的工作是完全和同团队的其他成员无关的，每个人所负责的工作一定是在相互渗透，相互影响，技术人员也要有软实力。
问题3
在第九章项目经理，邹欣老师提到了“从乐观角度分析问题的时候需要创意，从悲观角度分析问题的时候更需要创意”。乐观角度按照我的理解是产品能够产生积极作用的一面，比如说产品怎样可以给用户带来更愉悦的体验，产品某个功能的效率怎样可以更快，或者产品的界面怎样设计更加美观。而悲观角度我理解的是消极的一面，比如产品会有怎样的bug，产品设计的哪一点会让用户感到不爽。那么，“从悲观角度分析问题更需要创意”是因为我们需要发挥更多的创意，尽量想到产品的缺陷以进一步提升软件的质量吗？去思考产品的缺陷比思考产品还能添加什么更好的功能更重要吗？如果是这样的话，我们不可能创造出一个完美无缺的软件，如果一味的去思考缺陷是不是违背了“足够好”的理念？
在经历了团队项目，做出一个实际的软件以后，我对这种软件方面的思想的理解更加深刻了。一个产品如何如何好，如何如何便捷，在用户眼里都是应该的。比如百度搜索引擎，输入关键字以后，搜索结果会在1秒之内出现在用户的浏览器上，并且用户认为这是理所应当的。以我们实际的团队项目为例。α阶段里，我们做的项目是一个校园范围内的资源上传和下载平台，用户在使用的时候，从用户的角度出发，他们认为我们的平台资源应该非常丰富，资源的命名和分类应该非常清晰，资源应该有之前下载的人的反馈，资源的下载速度也不能太慢。转会后，β阶段我们做的项目是博客园的移动端，主要倾向的功能是博客园的班级功能和作业功能，用户在使用的时候，觉得我们的App的界面应该非常美观，博客的加载速度很快，还可以发布作业、提交作业，博客可以评论和艾特其他人。尽管这些功能有一部分已经远远超过了我们的能力范畴（比如资源的下载速度和博客的加载速度），有一些功能根本不在我们的考虑之内，但用户认为这些就是应该做好的，如果做好了不会有太多印象加分，但一旦有一个地方没有做好，用户的体验很差，那么这个缺点带来的影响可能就会覆盖掉软件其他优秀的方面给用户的印象。我们对“没有绝对完美的软件”这一观点深信不疑，但也不能拿这个当作我们减缓“寻找软件缺点”步伐的借口。
问题4
（在和同学的讨论中产生了这样的问题）我是一个体育迷，在职业竞技体育里，比如篮球和足球，会有这样一种现象，就是两三个超级球星加入同一只球队时，大部分情况下，这支球队的战绩会很好。但也有不能忽视的一部分案例，会有球星1+1<2或者1+1+1<3的情况（比如2010年南非世界杯的阿根廷国家队和NBA2016-2017赛季的尼克斯）。那么在软件工程领域，在技术方面有人是技术大牛，有人只是初学者，对于一个团队来说，技术牛人越多，这个团队的工作就一定会越好吗？如果不是的话，那么一个团队除了要有技术牛人以外还要有什么类型的人呢？
优秀的技术人员在一个团队里我觉得并不是越多越好，当然，如果能够增加一个技术强的人对团队来说还是有利的，但如果一个团队全部或者绝大多数人都是技术大牛，反而会造成一定的资源浪费，增加许多成本。这就好比是一滴水不是海，两滴水不是海……，那么多少滴水就是大海了呢，没有明确的标准。假设一个团队一共有6个人，其中要有一个擅长沟通与制定计划，对产品的定位和市场理解明确，能够有效的协调各个方面的资源，并且有一定的领导能力，他不一定要懂技术，但也不能完全不懂，这个人可以来做项目经理。之后要有2到3个优秀的技术人员，他们有着很强的代码能力和学习能力，无论什么语言和工具都能够快速上手，能够攻坚技术上最困难的问题。此外，还要有一个善于学习的新手，在这样的环境里，这位新手可以丰富自己的知识，提高自己的工作能力，这也为团队和企业培养了新的人才。一个优秀的团队绝不仅仅是做完一个好产品了事，也要能够为企业或者更高等级的团队做出贡献。最后还要有1个任劳任怨，工作兢兢业业，认真负责的人，这个人不一定有多么强的技术水平，但做事的态度可以成为整个团队的标杆。没有放之四海的团队标准，各种类型的人员在团队里如何分配需要根据具体情况来定，但有一点可以确定的是，成员类型单一的团队很难成为优秀的团队。
2.是否产生了新的问题？如果有，请提出。
怎样可以提升产品的用户量？许多公司的产品为了提升用户量，不断的砸钱，比如初期的淘宝，商家开店免费，以及uber和滴滴的消耗战。对于我们软件工程课程的项目，有什么可以提高知名度的方法或途径吗？我的一个想法是尽量选取和学校生活有关的项目，这样可以通过学生微信群、QQ群或者学校一些官方的微信公众号来进行宣传，但这也限制了对项目种类的选择。
3.软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
1.需求阶段
有时候用户并不知道他们的要需求是什么。
2.设计阶段
设计阶段除了项目的一些功能和规格以外，还要制定一些大家以后都要遵守的规范，比如变量命名，版本管理等。
3.实现阶段
对于一些需要攻坚的部分，可以采用结对编程的方法。
4.测试阶段
认识到了单元测试的重要性，单元测试不是最后写完代码补充上去的，而是要在开发的过程中边写代码边写单元测试。
5.发布阶段
发布以后要及时的收集用户反馈，尽快的发现自己项目的不足，并加以改正。
6.维护阶段
对于收集到的用户反馈要进行一定的整理，如果是项目的bug就要及时加以改正，还要与用户进行更多的沟通和交流。