提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	这个课程
这个作业的要求在哪里	在这里
我在这个课程的目标是	体会软件工程的时间流程，锻炼团队协作能力和开发能力
这个作业在哪个具体方面帮助我实现目标	回顾课程刚开始所提的问题
提问博客的链接	软工个人阅读作业#2

一、尝试对在自己曾经提出的问题进行解答

问题1

阅读教材3.3技能的反面，作者以精通玩魔方为例表述了何谓真实的“技能”：

离开了口诀的话，我只能把魔方的一面拼出来。从这点来看，我的魔方技能应该是：“能够独立地还原一面，其他看口诀可搞定。”那么，我这真实的“技能”还值得写进简历么？看样子是上不了台面了，那什么才是“技能”呢？

又以“不精通”的IT专业大学生面试为例，说明其编程过程实际上是一个解决问题的过程，针对一些变量的定义等语法的细节，该面试者“平时都是上网查的”，所有的时间都花在解决低层次问题上，因此面试官试图考察“算法技能”或者“C#程序设计技能”的目的无法达到。这说明面试官对面试者精通一项技能的要求，在于对该技能相关的低层次问题能达到自动操作的程度。

而后文又提到：

年轻学生都志向远大，上了一些课，就很想解决高层次的问题。一些学生非常想做高层次的“科研”，觉得“工程”是基础，没意思。

是否说明此类学生掌握的技能仅通过课程学习达到的程度无法言之精通？也无法写入简历？

经过一学期的学习，发现掌握技能的过程才是学习的核心部分。也就是说，面试官对面试者的精通要求，并不是说从结果上展示自己的能力，而是通过学习某项技能的过程展现出能力。就自己本身第一次接触前端而言，仅通过课程的学习达到的程度显然无法言之精通，但是学习全新知识并将它转化成产出这个进行过前端开发的过程是能够写入简历的。

问题2

在软件工程师的成长中作者分享了这样一个故事：

两个劫匪在亡命的路上看到一副绞刑架，劫匪小弟说，大哥，如果这世界上没有绞刑架，咱们的职业就好干多了。大哥说：你真笨！如果没有了它，这世上做劫匪的人怕是太多，我俩恐怕竞争不过同行，早就饿死了！

在软件工具和软件工程理论发展迅速的今天，软件开发变得越来越容易，把绞刑架看作风险与原则，那么这个例子表达的应该是失去风险或失去底线的高回报产业会产生激烈的竞争。那么要上软件工程的绞刑架，应该要做到删库跑路、贩卖源码这种程度。这个问题的关键也在于竞争会给我们带来许多困难，然而激烈的竞争会造成恶劣的生存环境，最终会导致某些软件工程师扛着绞刑架变成劫匪。

如果将来成为了软件工程师，竞争的激烈程度无法预料，但是软件的开发必然在相互合作中完成，再有以下案例：

程序员小飞原计划三天完成某个任务，现在是第三天的下午，他马上就可以做完。但是在实现功能的过程中，他越来越意识到自己原来设计中的弱点，他应该采取另一个办法，才能避免后面集成阶段的额外工作。但是他如果现在就改弦更张，那势必要影响自己原来估计的准确性，并且会花费额外的时间，这样他的老板，同事也许会因此看不起他。如果他按部就班地按既定设计完成，最后整个团队还要花更多时间在后续集成上，但那就不是他个人的问题了。怎么办？

在这种个人与团队的矛盾、合作与竞争的矛盾、原则和利益的矛盾下，软件工程师能够沉下心来开发吗？

答案是能，但并不完全能。所谓能，是因为对于项目有自己的目标和预期，在实现这个成果的过程中虽然会受到矛盾的影响，但是初心不改，最终就能够沉下心来开发。而并不完全能，是因为过多的矛盾产生会导致软件工程师对于预期的预计已经变成了“达咩”，源源不断的矛盾产生会渐渐地消减软件工程师的热情和抹杀对项目的期望，最终的结果要么是躺了，要么是鸽了，要么是最具有挑战性的成了。

个人与团队的矛盾在设计上有时能够更好的激励团队进行讨论，但是在进度上同时也会严重影响团队，这种影响的确会搞崩心态，但是在时间的逼迫下也想不了那么多。合作与竞争的矛盾并没有体会到，因为基本上只有组内的合作与组外的竞争，原则和利益更是如此，团队利益至上。

问题3

文中所言，结对编程要求不间断的复审，以达到发现、解决问题的目的：

结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。

文中提到结对编程能够解决传统意义上的程序员之间的互相复审的问题，如缺乏对程序的深入了解，缺乏持久、定时的安排，缺乏对需求和设计的了解等，但是综合前提都是对程序员的要求，结对项目的开发过程中，代码复审所花费的时间是否有效？通过代码交流是否优于直接交流，能够避免双方各司其职的情况吗？

这个问题已经得到了郑蕊老师的回复，原文有如下内容：

复审是不断地审核，提高设计和编码质量的过程，结对编程让复审随时随地发生，这样才能及时地发现问题和解决问题，避免把问题拖到后面的阶段。

对于问题3中提到“能够避免双方各司其职的情况吗？”

同时，结对编程避免了“我的代码”还是“他的代码”的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。

结对编程就是需要两个人坐在一起，先直接交流，再共同编码。一个显示器一个键盘，两双眼睛，共同的代码，才会避免双方各干各的。

在结对编程的实践中已然体会。

问题4

在阅读到PM和风险控制时，提到市场上创业公司失败的主要原因有42%为没有实际市场需求，在我看来，创业公司成功的主要原因很大程度上在于找到市场，例如短视频类软件在我国盛行前已然在国外推出，但反响不够明显，很大一部分原因就是我国市场大。

由于项目开发的投资必然被项目功能所分摊，但是在8.4竞争性需求分析的框架中对竞争产品分析时，企业除了在用户需求端与对手竞争外，还开发了占比更大的对用户无用的功能，这样的功能在市场上并无优势，却占用了不少资源，是有必要存在的吗？

是有必要存在的，但是它具体有什么作用，其实作用并不大。其存在性毋庸置疑，在开发过程中我们讨论了许多关于功能的增删，很多功能都是核心功能之外的加分功能，这些功能看似能够增加软件吸引眼球的能力，但是并没有很多用户会去真正使用，因为这类功能的灵感来源和产生的解释是：如果用户就是想在这个情况下使用这个功能呢？从另外一个角度，我们会反驳：正常的用户不会在这个条件下想用这样一个功能，因为它违背了用户使用我们软件的初衷(自测/提升自己)，这并不合理。这种对例如试题答案开放性的讨论最终结果是允许用户随时查看，虽然在设计初认为这种功能在主观上不能更好地帮助到用户，但是有的用户在这种时候就是想查看答案，所以它必须存在。可能这就是软件将市场扩大的一种方式，但是我愿意宁缺毋滥。

问题5

文中十六章IT行业的创新中，关于创新的迷思有提到一个观点：

要成为领域的专家，才能创新。

这个想法看起来非常合理，但是：

统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。

在我看来，这些创新者的成功之道，不仅仅在于自己是拿手领域的专家，更在于他们成为一个专家的过程中积累的能力，从而产生对于创新的可能性的敏感，进而与其他领域交叉，迸发新的灵感，才达到非凡的成就。

再者，文中提到一个迷思：

技术是创新的关键。

作者认为创新不仅仅在于技术，还有商业模式、生态系统、用户体验的创新。而我认为，企业创新的根本目的是满足用户需求，在追求创新精神的今天，倡导的是人人创新，然而，技术力不足的企业进行产品的创新是否过于盲目？

的确过于盲目。技术力是非常重要的，在开发过程中讨论出来的种种特色功能，即画饼的过程，最终都会因为实现的难易度改变。创新也是一样，创新不仅仅是产生好的想法，更重要的是将好的点子变现，而这是技术力才能支撑的。作为前端的初学者，面对陌生的领域和讨论出来的各种各样的功能，都是一步步摸索才能想到办法来实现，基础的功能也是如此，更不用谈创新了。

而在完成基础的功能后，依赖已有的技术力，提出符合技术力的创新也不是不行，因为在开发过程中比赛的快问快答模式就是我在小组讨论中提出的一种创新，在这个功能与我相关性比较大的时候，我就会去思考怎样实现，而在删除了一些难度较高的实现预计时，将简单的、能够实现的操作去与适合软件的方面进行联想，这样产生的快问快答比赛功能在结果上也符合预期。

二、是否产生了新的问题？如果有，请提出

1、敏捷开发的产品最终好不好是由主要用户决定、精通开发的老师、软件工程师决定还是由开发者自己是否符合设计决定？

2、开发的结果极大受到技术力的影响，敏捷开发是否成功是由产品决定还是开发过程决定，团队的人数不与技术力成正比时怎样评判一个团队的开发结果是否符合预期？

三、在实践中学习知识点

需求

需求不仅仅是由开发者主观决定的，虽然开发者在一定意义上也是用户，但是天下之大无奇不有，不同的用户会产生各种需求，因此需求分析一定要进行调研。

设计

设计需要考虑到实现是否困难，以及要考虑迭代性。由于实现过于困难而砍掉的设计不应该在进行设计时产生，这样会连锁反应产生大量对项目错误预期导致的时间损失。而设计的迭代性若不强会影响到后续功能的增加，这一点我们团队做得很好，在每次设计时都考虑了beta阶段。

实现

实现一定要有规范，例如文档。要做到文档的及时更新和信息同步，避免团队信息缺失导致进度缓慢。

实现过程中要合理分工，及时提出自己的问题，针对同质问题通过交流解决能够避免时间的浪费。

实现过程中要注意代码规范，增加可读性。

测试

测试过程中要做到在宏观上了解他人代码，在细节上清晰地知道自己的代码，这些代码的交互可能会产生什么问题。如果测试过程中发现了问题，却处于不了解其他部分代码的实现逻辑，只能等待团队解决，会损失很多时间。

测试产生的bug需要详细地记录，并且每次更新仓库都要进行通知，避免一边在用新版本测试一边在用旧版本的情况。

发布

发布要考虑用户、市场，趁早发布，及时收取用户反馈，及时讨论。

维护

针对用户反馈及时进行小组讨论，并且提出解决办法，同时合理地考虑维护成本。

总结

感谢团队的每一位同学，经历了一个忙碌的学期，团队的同学能够理解我在时间上的难处，作为前端小组的成员，前端小组长给了我很多前端开发的帮助，写了非常多前端的知识文档、接口的使用文档等，手把手让我体验了一把带飞的感觉。第一次前端开发就要写核心功能做题页面，大部分的功能都会跳转到这一个核心页面，从项目开始时压力就很大，并且不可避免地会因为功能的改动导致代码的重构。在学习过程中切实体会到了敏捷开发的紧凑，最终我们的小程序的用户量远超预期，功能的实现都符合自己的想法，也收获了不少好评，这就足够了。