断章取义一下，“生活不止眼前的代码， 还有诗和远方”。下面是我的部分读书笔记。
引言
原书作者谈到自己有两次被代码“逼疯”的经历，追根溯源，还是一开始对于编程的理念的误解导致。
理想总是很丰满，现实却那么骨感。
对于程序过高的预期，导致在面对一大堆枯燥晦涩的术语时心理落差太大，从而感觉自己被“逼疯”了。
其实刚看到这本书的时候，我也仿佛看到了当年的自己。读大一那会儿，学校课程有一门叫C语言程序设计的专业课，饶是我花费了大量时间，也学得不怎么样，期间各种上机测试更是让人“脑袋变大”，我也曾怀疑过，我是不是该换个专业了。后来又经历了一些事情，事情竟然发生了不一样的转机，我也得以留守下来··· ···
比喻篇
谨慎使用比喻
比喻和现实之间的界限可能会很模糊。
比喻可能让我们过于重视那些不重要的东西，而对真正重要的掉以轻心。
仔细想想，这段话说的很有道理。我们总是会让思绪跟着自己走，而忽略了我们为什么要这么走。比喻是一种思维上的泛化体现，我们会将一些可能原本不属于后者的概念附加了上来，加上思维定势的影响，也许，比喻根本不该这么被使用。
规划完备，然后开工
作者在这篇中谈到了建筑行业和软件开发的相似之处和不同之处。
相似之处：没有完备的规划，盖不了“摩天大楼”。
不同之处：软件开发有得天独厚的复制优势，时效性更强，更灵活。
“规划，规划，规划“的比喻过分强调要花大量的时间计划让所有的事务都臻于完美，而忽视了可以用好实际写代码的时间。
“象牙塔”架构师的传说
做官越大，编程越少。
纯粹的技术架构师可能构思的是最优的框架，最优的设计模式或是其他的什么最佳实践什么的。但是，只有亲自上手，埋头写代码的时候，他们才能真正了解到底要怎么架构。与此同时，那些无权做高层次构思的程序员也没有机会提出不同的意见。这也导致了目前软件开发的现状：
常常是真正做事先的人，才能最清楚的看到眼前的障碍。
这一点，我觉得微信之父张小龙名副其实，一个不懂技术的架构师，不是一个合格的产品经理。看透了应用下真正的需求，这也是微信为什么能如此成功的一大重要原因。找时间写点代码。
在沿着程序员的职务序列前进时，别忘了。代码才是把这些角色融合在一起的粘合剂。无论在团队中的职务级别如何，都要坚持写点代码，这是最有价值，最有意义的一件事了。
扔掉旧代码
这点我不敢苟同，我觉得旧代码也有旧代码的好处。
存在即合理。
当然作者原意是指抛弃那些让人心烦意乱的代码的影响，全身心投入到干净代码的编写。其实这并不能作为扔掉旧代码的支撑，或许对作者本人来说，旧代码就是一个扰乱他本人心绪的“隐患”而已，如果你也遇到了旧代码的问题，为什么不按照自己的想法？
我自己的理解就是：做自己，不要听风就是雨。盲目的跟随，迟早会掉到坑里。
多元化胜于专业化
这里作者又有点“想当然”了。当然了，这是我个人的理解。在现在的软件开发行业，一专多能是衡量一个程序员能力的标准，看起来很符合作者的原意，但是切莫忘记，这一专才是最重要的。
恰似那个木桶定律，最短的木板决定了你的下限，而最长的木板则是决定了你的上限。如果你的一专很普通，即使你的多能“很长”，最终还是盛不了多少水的。
我们能做啥？那就是尽量提升自己的长板，尽量弥补自己的短板。
动力篇
工作即福利
福利不是长久的动力
免费午餐，桌上足球机，办公健身房。这些固然是动力，但不足以成为你长久坚持下去的动力。有激情的程序员，表现在谈论起经过长时间苦苦思索才为技术问题找到优雅的解决方案时的异常兴奋的状态上。福利可能是毁灭性的
表面化的福利实际上会削弱人们工作的积极性。在我们眼前晃动的胡萝卜可能会让我们更加没有工作的热情。
从喜欢处下手
对我自己而言，我非常的赞同这个观点。就现在而言，没有工作上的强制性要求。我可以随心所欲的写自己的代码。比如今天有了这么一个想法，我立刻就可以着手去实现它。明天又有了一个新的主意，我还是可以快速的实现它。实现的过程即使再艰辛，到最后看到成果的那一刻，都变得不那么重要了。
这就是兴趣。也是我认为的动力的源泉。有句俗话说“兴趣是最好的老师”，所言极是。
很多时候，我也并不是一上来就设计啊什么的，我喜欢采用Down-Top的实现模式，我会把一个个小的部分完成，再去实现上层的功能。
小模块的完成，让我对于实现大任务有了底气，这同样是我的动力源泉。
莫求全
一个伟大的程序员会痴迷到有强迫症，但也一直都能接受不完美。想要写出完美的代码会让你骑虎难下。我们越早接受不完美，就越能保持干劲，坚持到底，最后完成的工作量也越多。
但是在不同的场合，这句话还是要仔细的斟酌一二。粗制滥造的产品永远也不会名留千古，只能成为淘汰品中的分母。
尽自己的最大能力，写出优雅的代码，是我一贯坚持的原则，如果看起来确实不够优雅，那只能说明我功力尚浅罢了。但总有人可以！
休息
当代码开始变得有点拖沓的时候，或者最好是在这一现象出现之前就停下来。小憩一下，给自己的身体补充点水分。
良好的编程习惯是在精力充沛的前提下进行的，而不是一味的待在屏幕前。两个小时的高质量的编程胜过8小时的煎熬。
很多时候，在写代码写累的时候，我们会偷下懒。走个捷径，或是违反了代码标准规范。请记住：那些低效的时间最后都写了些坏代码–我们第二天就可能会后悔的代码。所以，适时出去走走，给自己一个高效的工作环境。
膨胀的时间
有这么一条定律，我也不知道其真假，但是看起来还是有点道理。
工作会不断膨胀，直至占满所有可用的时间之后才会完成。
归根结底，还是没有充分划分好工作和生活的界限。
生产力篇
动力可能是起步时所需要的，而生产力才是衡量成功的具体标准。有时候我们会过于倾向多线程任务处理行为。比如一边吃东西，一边听音乐，一边聊天，一边编程。但是事实上呢？效率反而会变低。
人本身就是一个单线程的动物，当然不排除个例情况。但是绝大部分人在同一时刻只能做好一件事。编程同样如此。
设置一个最后期限
强迫症患者最大的克星就是Deadline， 它就好比是一剂良方，总是能在最后时刻发挥出它的功效。
我们都会有自己的小点子，有自己的兴趣项目。但是说实话，真正能把兴趣项目做好的实在是不多见。一是时间，二是更多的兴趣涌现。
给自己的项目设置一下最后期限，也许会有意想不到的效果。虽然，这对于我本人来说意义并不大。
我属于那种
- 放假后第一件事就是写完作业，然后放肆玩乐的一类人。
- 给自己留有充分提前量的人。
- 有了好点子，就一定要去实现，否则心里好像是堵了一块石头一样的人。
我很满意这个状态，最起码我会比较合理的规划自己的时间，不至于浪费太多。
去掉时间表中的细节
意指去掉时间表中过誉详细的部分。我们都喜欢明确的任务清单，但是过于详细，反而会让人心烦意乱。Elastic是时间表中不可或缺的一部分。最好是以Priority的形式来表达，否则过多的清单会一点点的磨灭你的兴趣，削弱生产力。
个人事项待办清单
我本人电脑桌面上从来都会有这么一个文件待办事项清单。这一点和作者也是想到了一块。对我自己而言，每天都会有很多新奇的点子出现在脑海里，不管实用也好，不实用也罢。我总会记录下来，这会帮助我学到一些之前根本不知道的技术。
还能帮助我很好的控制自己的时间，在正确的时间内做正确的事。
TODO List 形式有很多种，四象限，列表形式等等，但是并不是每种都是和你，找到适合自己风格的那个，你真的会受益匪浅。
内容方面，我个人觉得不要定太过精确的期限。太过精确会让待办事项变得犹如枯燥的工作一样。给一个模糊的时间，做一个比较模糊的事，这就足够了。
因为在真正着手的时候，一切都会豁然开朗。
提高生产力，避谈“我们”
在团队开发的时候，“我们”在不同的场合有着不同的含义。
在“拔河”似的合作中，我们是一股绳；
在“责任”这一概念下，我们是分离的独立个体。
很容易的，我们会把锅，丢给其他人。而忽略了我们本身也要对此付出点责任。
也许对外而言，我们就是“我们”这一样一个个体，而对内，我们就真的是一个个的独立存在，需要为自己的行为付出责任的人。
说的有点拗口，但是大致含义就是：做好自己分内事，与大家团结协作，发挥出团队的最大能力。
后序
还有很多内容，我没整理出来，因为我觉得目前的我还触碰不到。那样的话，就枉谈自己的感悟了。
说到底，什么是卓越的程序员，多看看身边的大牛们共有的特性就知道了。
- 有热情
- 不解决问题，誓不罢休的恒心
- 能静下去心，认真做事
- 时间规划得体，总是能在对的时间做对的事
- 不盲从
··· ···
