Ⅰ 回顾第一周计划
课程之前主要想对编程的整体理解(Programming Overall)、程序理解（Programming Comprehension）、程序的设计（Programming：Design）、效能分析（Programming：Performance）、线程之间/进程之间/不同平台的进城之间（Programming：communication）个人软件过程 ：个人源码管理、估计，记录工作量，并逐步提高(Personal Software Process)7个方面。除线程与进程之间没有理解，其他方面有了较大的提高，但是里目标还很远。
对于程序的理解，首先它是一门语言，重在交流，自身的语法，规则会在使用过程中逐渐理解掌握，并且会慢慢出现一些idioms等等；另一方面，程序是可执行的语言，需要计算机来执行，所以它的语法规则等等又不能像自然语言那样久而久之会弱化语法，相反它一直需要做到语法可执行。对于编程的整体理解，程序是语言，编程就是交流，所以对于新语言，先要做到熟悉语法，实现简单功能，做到program与programmer交流即可。对于熟悉的语言，在保证programmer与program交流的同时，有人应该保证program与computer更好的交流。就比如我们用julia做[NER](Named-entity recognition)的时候，一开始是要先熟悉语法，实现简单的例子，做到programmer基本可以与program交流，而不是一上来去实现NER的功能。程序的设计，在团队合作的时候，模块化设计和接口设计很是重要。我们组一直很注重这一点，接口设计与模块化。个人源码管理，便是进一步熟悉了github，以前只是按照那些命令一步一步来，也没有太注意每个命令的意义，经历团队编程，对于每个模块都有了更深的理解。
Ⅱ 回顾之前阅读《构建之法》提出的问题
1. P92 看到图5-8，5-9，5-10那些瀑布模型的流程图
对于那些瀑布模型的流程图，内心是认同的，也觉得有道理。可以一般的实践过程中，用户分析很重要，是很重要，但是如果对于一个在校大学生，这个
用户合不合格，真不真实确实是个问题。也许这个用户就是老师作业中的一个角色，亦或者说就是自己，即使每个流程图把用户分析放到第一步，没有实战过，不挨老师的几次批评，还是不知道用户分析的重要性。这里是不是可以先把这一步去掉以提问的方式说最开始缺少了哪一步？或者其他手段来表达出这个重要的理念？就是怎么让我知道真的真的知道没有需求分析，一切都是白搭展现出来，让我们以后一见到用户就觉得用户需求很重要
Ans：我们组不面向用户，但是“为你对联”那组他们的用户的确很重要，他们一直在为用户考虑，直到最后的bug都是用过用户找到的。所以任务一开始就需要知道面不面向用户，实现一篇论文，或者刷高一个leaderboard并不需要太多的用户，而像别的组的就仿佛时时刻刻与用户交流，所以有没有用户需求是取决于自己，而不是用户。
2.第六章 敏捷流程
P102 6.1 敏捷开发的原则，第五点，以有进取心的人为项目核心，充分信任他们。
P102-103 6.2敏捷的流程中有提到了同伴每天都会开例会
P104 有提到了燃尽图
P109 6.3 敏捷的团队 提到Scrum Master不是招呼大家开开会，记录每个人的进度而已，而是要在两种语境中自由切换相当于像个项目经理
P115 表6-2敏捷的适用范围要求有资深程序员带队
这里强调了这个Scrum Master的能力，进取心与责任心，。但是这样的工作量其实很大，而敏捷流程的开发周期很短，我们会不会想到“结对编程”，如果有两个资历，责任心，进取心差不多的程序员，能不能他两扮演领航员与驾驶员，一人两周，轮流当驾驶员。驾驶员需要统领大局，他得到的信息与发现的问题最多，也最操心这件事，还要完善燃尽图，照顾进度；领航员虽然在领航，但是也在天天开例会，不会说出现对项目不熟的情况。两周后驾驶员去解决那两周来难啃的骨头与一些测试，并担任起领航员的角色。之前的领航员称为驾驶员，又开始一波敏捷，因为例会天天开，之前的问题领航员心里有底，不会出现返工之类的情况。
ans：当PM还有dev迷茫的时候，我们应该换个PM继续工程，而不是消极怠工，错误大多都要从自身出发。
3.第八章 需求分析 P144 获取用户需求 —用户调查
这里提到了如何获取“用户需求的东西”，这里我P147页微软公司隐藏单向玻璃窗背后观察目标用户的举动的实验很感兴趣，因为其他的什么调查问卷，深入面谈，以前都试过，最终都是是失败告终，因为即使用心做好了自己，也没法左右别人。但是微软的这个例子，这个是很好，但是能不能让用户先站在后面，让技术人员演示一遍，然后用户在开始操作。因为我们知道，其实很多东西都是有教程的，而且3min左右的视频教程越来越流行，如果看了教程还找不对，那必然是值得去改，但是找一个本来没什么心情，又不熟悉的人来做这件事，背后的我们自然着急。就像是给老一辈用有道词典查英语，其实他对有些概念比如发音，词根，英语有对应的汉语这些概念只是知道，拿到一个单词他并不会去点击那个发大镜的图标来搜索，顺便看看例句，词组和词根。
Ans：这里我忽视了”集合“这么一个重要的观念，用户调查，调查的这个对象的集合包含了 期望的用户就算是合理了，集合大一点，包含了其他的人，最多有点“过拟合”，但是至少不会像“欠拟合”那样找不出适合用户的最佳“model”。
4.第12章用户体验
这里围绕用户讲了很多，很实用。同时我在想一个问题，用户体验，是非要直接来源于用户吗？双11的体验来自于美国的”黑色星期五”；滴滴起初良好的用户体验多多少少借鉴了Uber；百度也有google的影子。很多东西他们他们中国化一下就可以获得很好的用户需求，当然有人会问，中国化不就牵扯到了用户需求吗？是没错，因为这多少是间接性的，对用户需求获取的一点点补充。于是呐，我们可以间接地分析成功与失败的案例，在别人的体验上改进一下就可以达到很好的用户体验，只有在直接获取用户的体验上'小改'。
Ans：用户体验可以来自于竞争对手，或者合作伙伴。比如这次团队作业的两个“对联”组，一个网页版的可以体会到微信小程序更符合用户的使用习惯；对于仅有对联，用户对于更青睐古诗+对联两个功能都有的。
**5.第16章 16.2 创新时机 **
我看了黄金点游戏，有个问题: 这个是博弈的思想吧。 我查了下，博弈和创新是并列关系，不存在包含与被包含的关系，那么以这个例子说明创新时机的时候，我一直在想这个是一直在博弈，只不过是先验信息越来越多。再者如果按创新的时机来理解，创新一小步就会赢得大部分人，创新太多想法就会搁置，那么我是该将创新一次进行到底呢，下次在从另一角度突破？还是将我的创新分成一小块一小块，实现一部分就发布，抢占先机？
Ans： 我觉得其实创新无大小，实现分先后，一定阶段是要更新一个版本，发布一些新的功能，既能抢占先机，又可以持久发展。
Ⅲ 新的问题
-
在一个组存在实力悬殊的情况下，各司其职是一种合适的选择方案。那么什么的氛围和怎样开展工作是一种”提高式“的开展。
-
在项目进行快结束的时候，感觉到项目的立意等等都与最初设想不同怎么办，比如我们想做一个面向用户的团队合作项目，做着做着发现自己在刷leaderboard。这时候是放弃这个项目，还是重新开始一个项目。
Ⅳ ”事后诸葛亮”感想
事后诸葛分析还是需要认真去写的，不然真不知道自己做的怎么样，而且只有alpha阶段好好写了，beta阶段才有可能发挥得更好。由于我们不能够正确评价julia AI的难度，所以事后诸葛亮也是大致的回答问题，没有做到真正的领会，导致beta阶段做的不是很好。
Ⅴ 有什么收获是不能用数字衡量的？
在团队合作开发过程中，有助于PM对于每个人的pros和cons的了解，对于项目出现的一些新情况，新问题。可以选择更加合适的人更efficient的handle。从一个项目自己的反思对自己的成长，比如以往学习新的语言参考别人的博客，现在觉得官方文档以及查阅官方文档进行编程是熟悉一门语言最快最好的方法，在实际操作中遇到的问题，可以先从官方文档入门，不可，在入手博客和stack overflow。
Ⅵ 一年之后，回头看这门课，意见和建议
选题，不可否认能力强的人会把很差的选题做出很好的效果，但起码在给选题的时候，应该都多多少少面向用户，面向工程实际一点。比如四个组，juliaAI是学术风，其他三组多多少少都是面向用户，切合实际一点，这样就导致，juliaAI一组的思维和其他三组一再一起，感觉展示起来也不是那么的理想，有点做跑题了还在硬着头皮做工程的感觉。