【开发小结】Two Steps from Deadline

进度条可以救我也可以杀死我

# START

2018年4月17日晚我测试了11组四则运算的UI，每个exe程序生成的每一道题都有恐怖的倒计时。PSP表格清晰的记录了开发过程中消耗的时间，但是在结对作业中重构再重构的流程让我发现我不知道怎么填写待在一旁的PSP表格。

# Step 技术栈

part 1. 内存分配

C++中，内存分为5个区：堆、栈、自由存储区、全局/静态存储区和常量存储区。直到在我个人开发的时候，我才明白C++内存分配还分区，并且内存溢出与内存不足完全不是同一个概念。采用C语言风格的hash table遍历文件内的单词时，我的珍贵内存被new node大量消耗。

收集的几个tips：a. 不要混用 new/delete 和 new[]/delete[]   b. new与delete一定要成对出现   c.

part 2. 代码重构

大多数时候我们讨厌重构，主要就是因为重构后的测试十分麻烦甚至会出许多新的bug。没有自动化的测试，手工测试就要花费大量的时间。

我们在结对编程的时候，曾希望把存储分数的空间从数组改为容器vector，但修改完之后却发现出现了很多预料之外的问题，有时候在无关紧要的地方添加一两句代码，可能造成一些非常诡异的结果，我们多次测试修改之后发现无能为力，最后只好放弃了我们的想法。重构代码的恐怖在于：有时候我们发现出了error，但是却解决不了，除非放弃这条重构的思路。

但无论如何，“代码重构永远是程序员们无法回避的话题，当你的软件在编写的那一刻起，重构就不可避免。做一个系统，我们为什么要费劲地不断抽象，竭尽全力让自己的代码能够被重用，说白了就是让我们今日所付出的时间，让未来的我们能够更轻松地工作而已。”

# Step 时间轴

part 1. 规范细化、交流记录

早在阅读《人月神话》时（http://www.cnblogs.com/chenzhikai/p/8529867.html），我们就知道文档化的规格说明、项目手册是巴比伦塔项目失败的重要原因。我认为此次编程项目的需求文档写的比较简略，由于组数多而没有规范化的接口设计，导致UI与Core之间对接困难。再加上两组之间的交流太晚、信息杂乱无章，版本更新速度太快，对接任务繁重。

part 2. 进度增长使专注度下降

随着进度的增长，在相同时间内项目的进展是越来越慢的。“时间"随着进度存在着某种加速度，进度越深入，我和我的同伴就变得越来越不耐烦。真正的效率是源于内心对目标强烈的热枕，有对结果的期待才会让我们的表层意识直至深层意识保持关注度。代码敲的越来越多，改动次数越来越多，再加上其他学习任务繁重，我就开始降低这种关注度，得益于同伴带病喊我码代码的提醒与督促才不得不坚持下来。

part 3. 亲身经历之后

亲身经历一个负面事件带来的情绪反应要比看着别人的血泪史所感受到的强烈的多，虽然认知偏差仍然存在，但这比单凭大脑“镜像神经元”的一番冲动形成的情绪记忆更加持久。项目刚开始时，我们经过一点点简单的思考，情绪系统就会给出倾向或感到迫不及待，但立马转向着手行动的匆忙态度为将来的代码重构埋下了伏笔。看了一些书，写了一些读书笔记，但正如刘未鹏说的：“要掌握一门专业知识，其实每天一点时间，专注、积累和持之以恒也就够了”。

强烈建议：为每个程序员配置程序员心理咨询师、程序员秘书、程序员生活管理员、程序员执笔人：）