提问回顾与个人总结

项目	内容
这个作业属于哪个课程	链接
这个作业的要求在哪里	链接

回顾

第一次作业的博客

这样的结构，由于没有明确的“{”和“}”来判断程序的结构，在有多层控制嵌套的时候，就不容易看清结构和对应关系。下面的改进（格式C）虽好，但是阿超认为还是不够清晰：…
于是我们最后做了这个选择，每个“{”和“}”都独占一行。

当时对这个有疑惑，现在也还是保留着我的意见。在实际的编码过程中，我的左侧花括号是没有另起一行的，这不仅符合WebStorm的codestyle，对于我们小组的阅读来说也并没有产生所谓“不清晰”的地方。但是整体上这段话还是强调了代码习惯良好的重要性，每个人书写的代码需要能够让组员比较容易且快速地看懂，这样也是比较方便调用和使用的。

更严格地说，不要把不同的变量定义在一行上。
Foo foo1, foo2; // bogus

在我们的工程所写代码中，确实没有出现不同的变量定义在同一行的情况。对于每个变量的定义都是直接进行了赋值，一方面是代码量已经可观，出于规范，不宜将多个变量放在一行，另一方面，我也感受到了这个小细节确实具有一定的作用，它是有助于使代码结构更加清晰的。

要分清各种因素的关系, 例如，网站 “改版三列布局” 和 “用户在网站停留时间” 之间是下面的哪一种关系?
·不相关, 当前收集到的数据只是随机的；
·相关, 但不是决定因素；
·因果关系

我仍然保持关于这点的疑问。如果是面对广阔的用户，不经过调研，我们很难确定是什么因素导致了某一情况的发生。在我们的软工实践中，我们可以通过调研同学的想法，了解一下什么才能够使他们提升对这个app的使用时间；那么对于市场上的产品，分析各种因素的关系或许也不能脱离用户调研进行。

PM 文化的盛行有副作用么?

文章提到的是PM设计出的产品“大多了无新意”。PM在统筹整个工程项目的时候，可能会忽略或否决某些成员的想法，这样做的副作用是可能会抹除掉一些具有亮点的点子、想法。这样来看，PM文化的盛行可能在一定程度上不利于产品的创新。PM在保证项目平稳顺利进行上具有重要的作用，副作用也是难免的。

焦点小组中的：讨论者对于他们不熟悉的事物 (例如颠覆式的创新) 不能表达有价值的想法 - 在汽车出现之前, 我们找一帮马车夫来畅想 “未来的交通工具”, 他们未必会贡献很有价值的想法。

这一点我也保留之前的意见。在产品的调研时，我也是询问了我不同专业的各种同学，得到了各种各样的回答。这是让我比较惊喜的一点。这也印证了我的观点，即对不熟悉的事物提出的想法未必是无价值的。

比不犯错误? 软件项目的进展不是一帆风顺的, 总有问题发生, 出现了问题, 就一定会记在相关人员的帐上，以便总结提高。 但是一定会作为绩效评估的依据? 那倒不一定。
如果成员的行为只影响自己, 或者是探索式的行动，则不是坏事。 例如有些成员自行探索最新的技术, 但是最后决定不采用此技术。
如果团队成员的行为影响整个团队 (例如 build break 导致daily build 失败), 则要注意。 在一个里程碑中可以统计谁导致这样的错误最多。 对这样的人可以采取 <移山之道> 中提到的 build master 方法处理。

就我个人体验而言，在团队项目的推进中，我本身就在进行技术的探索和学习。相信在未来的工作中也是这样，在团队的工作中，自己也是要进行相关的很多学习工作的。当工作量起来之后，可能自己自行探索技术的时间确实会少很多。

知识总结

需求

在需求阶段我们学习了NABCD分析法，五个字母分别对应了需求，做法，好处，竞争，推广。这个方法可以把项目的特点总结概括，既明晰了需求，有利于团队明确开发计划和目标。

设计

在设计时前后端一定要交流好。符合需求是最基本的，但是更重要的是这端的接口，那端是否能够很好地（正常地）运用上，不然会做很多无用功，对团队来说是一种打击。因此在设计阶段，在对接口的明晰上，一定要确定好各种细节，如返回值，字段含义，尽可能地保证在开发阶段出现少的（最好不要出现，但是应该不太可能）对接问题。

实现

在新技术的学习过程中已经要多去查询官方文档。不过这次算是不幸碰上了硬石头，会出现官方文档在某个问题或函数并没有给出比较清晰的阐释的问题。这个时候也需要多和团队成员进行沟通，多多请教大佬，共同学习，最终顺利地完成代码的书写，实现出理想中的程序。另外，在整体的是实现阶段，代码管理工具非常的重要。Code Review对于代团队整体代码正确性上也有一定的保证。

测试

测试需要全面，单元测试需要对代码中每一个最小可测试单元进行检查和验证。完成测试后需要给出测试报告。

发布

在发布过程中需要多多进行宣传。如果没有用户用，又何谈用户体验。

维护

在这个阶段通过接受用户反馈进行快速响应。整个团队对于发现的bug需要有快速形成解决方案，并下发到具体成员进行操作，同时在修复过程中如果有关键数据，一定要进行备份。

心得

在这个课程中，我们历经两个阶段，从头开始打造了一个Todo List的app——Okidoki。

对于这个课程“做中学”的方式，我个人是比较喜欢的。相比之前个人体感上实验和理论学习似乎出现大割裂的某些课程，软工这门课让我对于敏捷开发有了实践层次的体验，这比空谈理论重要的多。

同样重要的是，我通过这个项目，学习到了react, react native的相关知识，也进一步学习并运用代码管理工具，更加熟悉了部分git指令的使用，对我提升个人代码能力具有重要的作用。勇于探索自己之前没有学习过的领域，并且成功地把程序做出来，我觉得这是我个人不断进步所必须要经历、未来也一定会不断践行的。

感到遗憾的是，“团队”这一属性我在自身的实践中没能很好地感受到。很感谢PM对这个项目的付出，也希望未来选这门课程的人能够珍惜这样一个团队做项目的机会。希望老师把这门课程越做越好！