软工总结
问题回顾
1
2.1 "所以，写单元测试没有比作者更适合的人选了。"
现在想来，当初的我是把单元测试神格化了。我的脑子里似乎认为单元测试就是测试的所有，这次当了半个多学期的测试我才认识到单元测试只是测试环节中的很小的一部分，而且在非测试驱动开发的模式下确实应该由作者本人来编写。因为单元测试的目的就是验证写出来的代码和脑子里的代码一致，而验证脑子里的代码这一步应该由其他测试环节保证。
2
3.1 "软件工程的奠基人之一瓦茨·汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%—95%的比例。"
我的意见没有发生改变，我依然认为他的这番话不是对个人的评价，而是整个软件的工程实现。
3
3.3 技能的反面
我现在觉得需要分情况决定是否应该进行大量的训练来将低层次的问题解决变成不用经过大脑的自动操作。
让我改变想法的原因是这次我切实地感受到“时间不够用”的问题。和以前我熬一下夜、赶一下工就能解决的“时间不够用”不是一个量级，这次的时间不足度可能会是需要已有工时的四倍、五倍才足够。我在想，如果我是一名编写测试样例的老手的话，或许效率能是现在的好几倍，毕竟能省去太多试错、思考的时间了。
但我依然觉得这应该是有所取舍的，过长时间执着在一个点上，对于我们这个行当的“匠人”而言并不是良好的发展方式。我们需要时常去看看新的东西，去学习新的东西，所以一样事物的练习时间不应该过长。
4
4.2 "另外，注释（包括所有源代码）应该只用ASCII字符，不要用中文或其他特殊字符，否则会极大地影响程序的可移植性。"
我事后想了想，诚然，utf-8正变为主流，但是考虑到对过去产品的兼容性，确实ASCII字符会有更好的可移植性。
5
4.3 "函数最好有单一的出口，为了达到这一目的，可以使用goto。"
意见不变。
6
4.4 在todo标记那里加上人名
现在我觉得这在某些开发模式下确实是个好习惯，因为像是敏捷开发时，每个迭代的人员基本不会变动，而且像是我们这次的开发过程中，项目管理和版本控制是非常紧密地联系在一起的，所以在代码中使用人名指定任务确实是个不错的做法。
不过，当然，也有不适合的开发模式，以一个较长时间为周期进行开发的模式就不适合这种。
7
4.5 "如果团队的人员要在多个项目中工作，不能充分保证足够的结对编程时间，那么成员要经常处于等待的状态，反而影响效率。"
意见不变，而且还要追加对scrum meeting的质疑。我们并不是全职的软工课程学生，每个工作日都要求我们在软工项目上有所进展是太不合理的要求了。
8
5.2.5 秘密团队
意见不变。
知识点总结
需求
需求方面让我眼前一亮的是“黑客”，这类恶意的存在，也是我们的用户，不过是恶意用户。他们也会为我们提供需求，不过我们要做的是防止他们的需求被满足。需求分析不应该只对理想用户，而是应该考虑到所有可能与产品产生交互的存在。
设计
这次前端和UI的设计交互让我感觉很欣赏。他们首先决定由UI进行主导，然后UI会反复询问前端、PM，对设计的可行性、合理性进行讨论，同时前端还会对设计的方法为了可行性而进行限制。这样一套设计方法真的很有效。
实现
实现方面，其实我感受最深的是实现的进度管理问题。良好的commit记录能让进度管理变成一件很舒心、轻松的事情。commit记录本身就包含了“完成时间”、“复杂程度”、“项目进度”等等信息。
测试
最大的收获是领悟到了“测试应尽可能不干涉开发”。这体现在多方面，像是版本控制应独立、应尽可能让测试配置与生产配置相似、代码的依赖性应是单向而且尽量松散的等等。项目刚开始的时候因为没有意识到这件事情，我做了太多无用、甚至有害的工作了。
发布
发布……俺一窍不通诶，这部分俺一点也没了解。要说的话，领悟到的是一项产品一旦进入到市场中的话就应提供与市场主流一致的、或者同等级的服务，而不管这项产品的投入是多少。因为投入与回报并不是一个线性曲线，如果提供的服务没有到一定的线的话，是一点回报也不会有的。
维护
“数据维护”，这是我领悟到的一点。我以前对维护的认识局限于“服务维护”、“代码维护”，但这次了解了数据库以后（我大三上没修数据库），我才意识到数据库现在原来如此重要、复杂。我意识到了现在的维护中很大很大的一块应该是数据维护，这包括现在的数据存储格式的向后兼容性、已有数据的备份等在整个项目生命周期上的数据保障。
个人心得
我本来以为我很会敲代码、很会开发的。这种自傲并非空穴来风，我姑且还是读过一些大工程的源码（主要是游戏的就是了x），也写过很多很多代码，也和别人共事做过东西（那时候我还是leader呢，虽然现在回想起来很不称职），我确实是有一些自傲的资本的。但是我也切实地感受到了自身经验、能力的严重不足。
在结对编程的时候，我缺乏手段去满足一个高难度的需求。是的，那确实是非常高难度的，凭我的算法能力肯定无法解决，但这并不代表我就一定没有任何手段去做到。当时的我直接放弃了。现在我回想起来不禁打了一个寒战，怎么可以放弃？那是一个产品的需求，怎么可以放弃？确实，我当时做了很多工作来说服自己去放弃，那些工作也确实是有效的，但我的思路太过狭隘了。我仅仅是说服了自己“凭我和我搭档的算法水平是无法解决这个问题的”，仅仅只是说服了这点，我就说服了自己去放弃一个需求。明明除此之外还有不计可数的手段。真正的产品开发中，可以依靠的远不止自身的基础能力。我以前就明白一些这个道理，我知道去寻找别人已经造了的轮子，但我的理解还是太过狭隘，肯定还有更多更广的思路。现在的我还没有那个经验与能力去讲明白那些思路，我还有很长的路要走。
团队项目中也是，我深深地意识到了工时是一件多么严苛的事情。事实上，要完成所有我预期的目标的话，我估计需要的时间是这次的实际工时的五倍。我缺乏经验，无畏地给自己填充目标、任务，对它们的时间估计不合理。我缺乏能力，有很多期许的愿望最后并没能实现，它们在我脑中虽然存在绘景，但那与现实太过遥远，我的想象太过朦胧而与现实脱节，要让这份想象具象化需要太多试错、努力了。我现在甚至觉得，哪怕让我重来一次，我也依然做不到我的理想，我做不到，这不是先验先知就能解决的问题，而是时间本身就限制着问题的解决。哪些是一定要做到的——我怠惰地、自傲地将太多工作都划进了这类工作里，结果导致工作反而失去了优先次序。
说起来似乎每次完成一个项目的时候我都是这种感觉，“自己有太多的不足了”。这些问题不是一套软工方法就能解决的——我察觉到了这件事情。诚然，这其中有大量的问题都源自非编码工作，它们似乎可以用一套软工方法来解决，我以前都是这么觉得的。但事实上，这次实践了一段时间后，我才察觉到要实践那些规范本身就要求着丰富的经验与出色的能力。举个例子，我对工时的估计的错误，这不是我提前估计就能估计得好的，而且我连任务划分本身都可能是错的，不过任务划分是错的是很正常的事请就是了，一个好的工时估计应该是哪怕出现这种意料之外的情况也不会偏差太多。
总结的来说，就是一句很讽刺性的话，要想做好一个项目，就需要做坏很多项目。希望我以后做坏项目的时候，至少也能交差吧（笑）。
