应该是大一时跟图书馆借的第一本小说。后来用ebook后再也没去借了，反倒有点怀念。

就从笔记本开头写起：

不多废话，这个笔记本是用来记录和看书有关的东西，尤其是观后感，虽然我也很想拥有像小隐那样规整的读后感笔记，以往我也很多次尝试去写过，但都很少写完，大多是中途跑去做别的然后就这么搁置下来了或者把本子拿来写别的，哎。

看书很多时候，或者说有些时候可以让我在玩游戏和学东西（work）之间冷静下来，并且也让我大脑不一样的地方活动起来。而并不是学完东西打游戏，打完游戏学东西。那样反而会陷入一种固执，而阅读是很好的松弛剂。这段时间里面可以什么都不考虑，也可以考虑一些跟生活无关的，不切实际的东西。

《最后期限》 汤姆-迪马可

#意外的相遇：

碰到它是一个意外，也是缘分，我在找的是和它同名但不同作者的一本书，但委托借到后，我才发现，这是个愉快的错误。

最初我看到封面上标签项目管理书，又是小说，就认定这又是一本业内人士试图表示自己的专业知识，但又想要写得接地气，而写得不像样的小说。

#吸引我的点：

但他很好地抓住了我的胃。有3点

• 可爱的，诱人的朱利安女士，同时又是绑架犯，反差萌。

我承认我对于这本小说最初的喜爱是建立在对女性角色的喜爱上的。

• 它是关于软件工程的，关于程序员合作项目。【我感兴趣】

不得不说现在我的思维也有点程序员化了，而我需要跳出这种思维的机会。

• 我熬过了开头的20分钟。

在刚刚开始时也许时太久没看小说，缺乏代入感，脑子和视线接不上，犯困，但过了二十分钟后，我就 get into the zone 了。

很多时候一本小说只要约束自己打开阅读二十分钟，它可能就会展现自己可爱的一幕。

在那个时候看书才是享受的。

#一些摘抄和归纳：

下面是一些笔记，有的是归纳的，有的是直接摘抄的。

关于一个软件项目开始后随着时间流逝凝聚起来的压力应该如何应对。

• 压力其实一直潜伏在空气之中，可能会在成型时打的人措手不及。

• 项目刚刚开始的一天和临近结束的一天实际上是等价的，但是我们起初悠闲后来急迫。（心态上，最初就太过于放肆了）

• 解决压力的最好办法就是在它成型前就掐灭它，治人于未病，提前做准备。提前完成。但是，不要一直保持压力和紧张，一时的压力看似能解决不少东西，但长期的压力只会扼杀人的思考。

• 保持玩世不恭，学猫，学像猫一样的蒙洛多程序员，不管外界如何要求和压迫，我只先考虑完成最低限度或者，保持自己的意见，而尽量不要学韦伯那样，面对文档中的铺天盖地的要求而头晕目眩。

• 一次只完成一个目标，不要试图一次调试两个bug。

• 珍惜一个项目完结后那种浑身一轻的感觉，并且在这之后，记得整理收获和经验。项目的结束并不代表自身的结束.

  --- 但愿我们能够阻止生活中的贝洛克出现。（无尽的，喋喋不休的甲方）

Ps:

• 胡利安她说“他一定是想我了”的时候真的好可爱。

• 韦伯每天晚上坐在案前写经验和笔记，虽然只是作者向我们科普的一个路径，但是他对记者说这本笔记我不会再翻开，但那101条原则已经烙进我的意识里时真的很帅。我写博客，大概也是同样的心情。

所以我也不禁考虑起自己写这本笔记的初衷，也绝不是为了反复翻阅而去写的，毕竟写过一遍，该记住的已经记住了。

同时我觉得用这样的阅读，写观后的流程也有助于我阅读的连贯性和思考，同时也有助于我养成一个良好的阅读习惯。

wtf，自从用了ebook再也没动过笔了，我也同时怀疑自己是不是再也没有动过脑。

# 设计，让代码有如“神”助

《最后·期限》很掐我的点，程序项目，时间管理，人力资源，以及一个有魅力的绑架犯小姐姐。

这里说说项目提到程序设计相关的东西。

亚里士多德认为编写程序之前的项目模块设计很重要，甚至值得花大部分的时间去做.

正常人所认知以为的这里所说的设计应该是指：

功能-> 结构->实现。一个从结果到底层的一个逆推和细分。在编写项目之前应该就要对每个部分分别做什么，每个部分功能和实现了然于心。

但是只是对功能实现的设计还不够，还不是终点。真正的设计是在程序编写者心中的，当前要实现什么代码模块，它的伪代码应该是什么样的，最终的编程只像是把拼图放在合适的位置。这样几乎能够完全省略掉调试的环节，每次只实现一个小代码块的功能并验证。而我经常一拍脑袋写到哪里想哪里，经常的我陷入到了一个特定的实现带来的bug中，我不会想着换另外一种实现，而是会为了debug把很多东西都改一遍直到正常运行，但这次的修改不仅浪费了大量时间，还可能又让一些部分偏离了原本的设计。

我觉得，亚里士多德真正要想要强调的，只是我们在编写代码的时候同时具有另外一种视角，当我们陷入Bug的时候，我们会知道更换方法而不是死磕。实现的时候，而是像是有一个拼图的背景在指导我们这一块应该是什么，下一块应该是什么。

他所强调的设计，应该是上面说的那种视角，和拼图背景。如果说写代码有如神助，那么这种视角就是那个神。

我目前可以说编程习惯很不好的，都是想到什么写什么。也许我该学学，在心里写伪代码，试着推理下一步和这一步。然后再推衍全貌。

没有一个程序的编写离得开这种设计，不过，大部分人习惯在一边敲代码一边设计，这就有点像下棋了，有的人看得多（全貌），有的人看得少（局部），有的人能一下预测十几步的落子，有的人只能看见一两步就停下来了。

而我是典型的局限又短视者，之前我对自己的编程习惯冠以潇洒的名号，但在碰到较大项目的时候，每次加入功能都可能牵一发而动全身，需要反复修改所有代码而不是只修改局部功能让我感到我需要改变。也许我需要规范，也需要看得更远一些。

设计就是有意识地去预判棋路，不过没必要看出所有的情况才敢下出一步，那样时间肯定不够用。而只需要，看出一条线性的，能达到终点的路即可，至于如何优化，那是到达终点后考虑的事情，一边试图优化一边写还未成型的功能是犯了大忌，最终花的时间究竟是写功能多一些还是调试优化的时间多一些？

有意识地预测一种可以到达结果的目标代码块，如果可以，也可以预测两种，留作备案，当一条走不通先换另一条，而不是立刻进行调试和debug。不少人选择一开始脑袋一拍直接开始编写，实际上，直接开始编写可能造成的错误和最终反复调试，测试的时间，会远远超出预测耗费的时间。另外，没人会喜欢反复运行，反复排查错误的原因。能够一气呵成，何乐而不为。

另外一气呵成也并不是说我所有都写完了再运行然后一次通过，这个是不可能的，总会有偏差和bug。而是每次将预测到的代码块一次编写完成，然后运行，一次通过，并且能够达到自己的预期功能。并且只有在验证完功能后我才会进入下一个预测和编写环节。

#印象最深。

• 在一个项目刚刚开始的时候，危机是存在的，目标是明确的。危机感是薄弱的、堪称惬意，目标感可谓全无，几乎可以称得上漫无目的。

• 目标感是一种积极、兴奋的心态。

• 我们常常有目标，却缺乏目标感，因为我们实际上认知的目标只是“应该做的事情”，而非“特别想做想实现的东西”。