这是软件工程课程最后的小结。在这个软件工程课程中，我参与了 Judy: A Julia Debugger 的课程项目，中间遇到了许多困难，也收获了许多。
回顾课程计划
在开课前，给自己的能力评分是：
| Comprehension | Design | Implementation | Personal Software Process | |
|---|---|---|---|---|
| 分数(0-9) | 4 | 3 | 3 | 4 |
在课程结束后，希望每一项都能达到5分以上。
那么现在课程结束，我认为基本都能达到：
- 在源码阅读方面，因为 Judy the Debugger 的实现需要理解 AST，我们在这方面借鉴了很多 Julia Repl 的源码，通过阅读源码懂得了 Repl 的实现逻辑，并在这个基础上进行了一些代码复用。
- 在架构设计方面，我们一共经历了2次重构，第一次重构是为了将存储结构支持到多文件，第二次重构是为了将存储 Debug 信息的部分从当前实现逻辑上分离出去，达到松耦合的效果。不过最后我们对整个架构还不是非常满意，模块间的耦合度还是太高。所以我觉得这一部分我仍然需要更多的提高。
- 在实现方面，入门一个语言已经非常快速了，我在从刚开始接触 Julia 到写完 Judy 对源码的 parser 部分只花了3天时间。在整个实现过程中，我也比原先更在乎对异常的处理，能够让软件有更高的鲁棒性。
- 个人软件过程方面，对代码的记录、管理有了更进一步的提高。我们采用 GitHub 来对源码进行管理，不同的分之间采用提 peer review 的方式来进行 code review。
开课前的问题回答
对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
我对这一点有疑惑，首先我觉得结对编程很取决于双方的实力和双方的性格。如果双方实力差距悬殊，并且实力强劲的一方性格还刻薄，这样会对编程能力较弱的一方造成编程上的心理压力，反而拖慢整个工作的进度, 甚至影响团队的和谐。
关于这一点，邹老师已经给了我解答，实力强劲的一方对于实力弱的一方来说，是一个机遇，在这个过程中，能够对自己的编程技能有很大的提高。所以应当以学习的心态来进行整个项目的结对编程，同时对于实力强劲同学的来说，也是磨砺自己性格的一个方式。所以只要这么想，双方都是获利方，那么合作起来压力也就不大了。
在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。
首先我很认可传递经验、应对人员流动。但是我认为，当在编程过程中，一个任务往往有不同方式的实现，如果两个人都各执己见，往往很难协商一个共同一致的实现方案，从而导致项目停滞。同时如果有一些创新的想法也很难在交流过程中形成，因为个人感觉独立思考往往能带来更多的创新性。
这个问题其实我现在仍然存在。拿 Judy the Debugger 来说，后端 Debugger 的实现上因为每个模块之间耦合度很高，如果两个人同时来对源码进行修改，就很难进行 merge（会出现大量的冲突）。一种办法是将模块的耦合度变得更松，但这需要更高的架构能力，或者有些项目根本做不到松耦合的架构，那么这种情况下，一个人编程的时候另一个只能等这个人完成编程 merge 进主分支后才能进一步修改，极大得降低了效率。那么这种情况有什么办法呢？
第二步：决定当前的冲刺需要解决的事情
整个产品的实现被划分为几个互相联系的冲刺。产品订单上的人物被进一步细化了，被分解为以小时为单位。
我觉得一个项目被分解到小时为单位非常困难，首先能够做到这样的分解，必须对架构有非常清晰的认识，并且对实现的难易程度也有充分的了解。这一部分我觉得很难在现实中把控好，因为稍有不慎，这个产品的进度被拖慢从而导致后面的产品进度都被拖慢，造成连锁反应，这种情况要怎么解决呢？
解决这样的困难首先必须有很多的编程经验。同时，在软件的设计之初，功能应当已经确定。所以按照功能先对任务进行划分，再对打的功能按照小的实现步骤进行划分，就能较好的把握项目的进度。
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明显，然后保持不变。但要注意，我们是预期变化，不是期望变化 。
在这个过程中，如果我们预期了变化，并对预期的变化做出了相应的调整。但随后发现预期出现了错误，用户的需求是往另一个方向走的，那么在对于正在做调整的软件该如何处理？
这个过程中如果没有重大偏差，我认为应当按照既定的路线坚决的前进。如果再在这个时候进行软件架构上的调整，会挫伤整个项目团队的信息。
要带着感情去讨论问题么？有专家建议开会应该尽量不带感情，但是别的资料又要求大家带着感情去体会用户的通电，还要带着浪漫的幻想去做头脑风暴。
我觉得因为每个人专业的领域可能有细微的差异，很多人对一个想法褒贬不一，同时一方面认为着不可能行，另一方面又认为这是一个很好的点，如果在这样的环境下权衡一个想法的好坏呢？
首先我认为在对待产品功能和预计的用户体验上，应当适当带上一点感情，因为这样能更加契合用户自身的体验。但是同样需要更多的统计数据来进行客观的分析，这样才能从两个方面同时把握用户的需求。在实现过程中，应当带着理性去思考实现的问题，而不是感性。
新的问题
有一个问题，这个问题就在上一个部分的第二个问题，没有被解决。
感想
回过头来看我们的"事后诸葛亮", 实际上都是对每个阶段的总结。正是因为这些总结才能对我们下一阶段的任务有了一个更明确的方向。因此，我认为在提高软件工程项目效率方面，适时的"暂停"是更好的"快进”。
新的提升
提升大部分已经在第一部分中写明，还有些提升也很多，如团队间交流的能力。
建议
因为我以后读博的方向是系统方向，以后参与的项目也很大概率都是多人合作的大规模项目，而不是像 ML 这种一人就可以单干的项目。就像我们这次 Judy 一样，很多技术路线在后续的科研工作中不会特别的清晰，有时甚至到了开始写代码了还没确定好正确的技术路线和实现方式。所以，针对这样技术路线不明朗的情况，我希望能够得到一个更系统的方式，来更高效的完成项目的合作。