读书笔记_卓越程序员密码

The Pragmatic Programmers
图灵程序设计丛书

卓越程序员密码

The Developer's Code 
What Real Programmers Do

Author: Ka Wai Cheung
翻译: 劳佳

人民邮电出版社

第1章 引言
1.1 谁是21世纪的程序员
我是一个无认证但是超级有逻辑的心理学家、理疗师、机械师、外交官、商人和教师，我所在的行业，迄今任然每时每天都有着新的诠释。
1.2 吸取第一手教训
1.3 这本书写的是我们自己


第2章 比喻
我们必须用比喻作为“元语言”。这不仅让我们能够把编程的独特性讲述给普罗大众，而且还经常是我们解决软件问题时的决策方法。
第1篇 谨慎使用比喻
有时候，比喻和现实之间的界限可能会模糊。比喻可能让我们过于重视那些不重要的东西，而对于真正重要的掉以轻心。
第2篇 规划完备，然后开工
“规划、规划、规划”的比喻过分强调要花大量时间计划让所有东西臻于完美，而忽视了可以用好实际写代码的功夫。
第3篇 发行不过是第1版
发行无非是软件生命中的一个点而已，不是尘埃落定，也不是功德圆满。
第4篇 “象牙塔”架构师的传说
在你沿着程序员的职务序列，从程序员一步步变成架构师，别忘了代码才是这些角色融合在一起的粘合剂。
最后我强调一点，无论你在开发团队中的职务级别如何，都要坚持写代码，这正是你最有价值的地方。
第5篇 扔掉旧代码
不要把代码囤积在注释里，删除代码可以让代码库精简。
第6篇 多元化胜于专业化
归根结底，无论是上层界面，还是底层引擎，软件设计的目标是一致的。我们没有理由不能在多个领域做得出色。
第7篇 比喻渐欲迷人眼
所以，如果你面对一个软件问题不知如何下手时，或者没有足够的信息来做出明智的决定，那么一开始用传统的开发比喻作为基础还是不错的。但如果你已经投入那个比喻一段时间，就需要抬头看看了，看看它在哪些方面促进又在哪些方面影响你的流程。


第3章 动力
仅仅一件事，不足以维持动力。
第8篇 工作即福利
Dan Pink(TED演讲) 他说传统的商业激励因素，比如大笔奖金，可能会成功调动员工的积极性，但只能用于那些简单琐碎的工作。相反，那些需要批判性分析和创造性解决方案的工作，把金钱奖励挂在员工眼前晃悠则没有什么用处。在一些涉及高层次思考的实验中，金钱激励和业绩之间是负相关的：给一组特定研究对象的金钱奖励越多，他们最后做的越糟。
在选择下一份工作的时候，记住那个能够让我们长期保持干劲的东西——不是外部的福利，而是工作本身。
第9篇 从欢喜处入手
所以，如果你可以选择从什么地方开始写软件，一定要利用这份自由，挑一个你觉得最有意思的功能，从那里开始做起。
如果你发现自己就是三分钟热度，那么及时停止，损失也不大。
第10篇 莫求全
一个伟大的程序员会痴迷到有强迫症，但也会一直能接受不完美。想要写出“完美的代码”会让你骑虎难下。我们越早接受不完美，就越能保持干劲、坚持到底，最后完成的工作也会越多。
第11篇 休止一下
当代码开始变得有点拖沓的时候——或者，最好是在这之前——就停下来。良好的编程习惯是在精力充沛时高效地工作，而不是一味地呆在屏幕前。两个小时的高质量编程胜过八个小时的煎熬。所以，请缩短编程时间，出去走走，享受一下生活吧。
第12篇 早起先测试
早起上班第一件事：测试你的软件。这是你最清醒、最有动力写点好东西的时候。
第13篇 别在卧室里工作
正如帕金森定律所说：“工作会不断膨胀，直至占满所有可用的时间后才会完成。”
在家办公是一种奢侈。但如果你有幸享受这一点，千万不要在卧室里办公，最好也不要在起居室。搞出一个封闭的工作区，最好是单独的一个房间，这样就可以在工作时间结束后从那里离开。
第14篇 第一印象也就那么回事
造成很多不好的第一印象的原因有两个：
1 第一印象不好可能是因为不熟悉
2 第一印象不好可能是关注了次要问题
所以，当你从顾客、客户或是同事那里得到负面反馈的时候，要坚持自己的想法，解释你这样做的道理，让他们适应你的作品几天，而不要让最初的即时反馈打消你的积极性。
如果问题任然存在，那么你的软件可能确实有瑕疵，但你会惊讶地发现，很多最初的负面印象通常都会消失。
第15篇 软件发行的情感价值
发行日期本身是一个强大的动力源。
为啥呢？因为我们知道软件不再是在局外等待了，它有生命了，准备好了，这对自信心是一个巨大的提升。
第16篇 找个争论话题
找个争论话题吧。找一个你无比赞成的话题，要是找一个你毫无掩饰地反对的话题就更好了，然后大声讲出来，细致入微地解释为什么你的方法行得通。(Meetup.com)


第4章 生产力
动力可能是起步时所需要的，但生产力才是衡量成功的具体标准。
第17篇 对消闲项目坚决说不
时机就是一切
时间是保持编程动力的最重要的因素。
如果能正确处理下面问题，就可以把它变成真正的项目。
我每周要花几天、每天要花多少时间在这个项目上？
我什么时候能把一个基本成型的产品展现给别人？
哪一天向公众发布？
哪一天发布第一个主要的更新版本？
这些时间限制就像建起了围墙，我们要用工作填满它。它帮助我们确定最重要的功能，为我们投入软件每分每秒提供了目的。
设一个最后期限，即使是随便设的
最后期限创造了一种紧迫感，敦促你冲过终点线。即使没有人在逼迫你，它也能给你所需的鞭策。
第18篇 限制所有的因素
所有软件都需要花钱来做，所以还可以为成本设一个上限，成本上限赋予我们创造力，它可以帮助我们更有效地利用资源。
如果没有限制，无论是时间限制、成本限制，还是功能集限制，我们就会忽略现实，做出有问题的决定，因为没有东西敦促我们做出明智的选择。生产力也就不会放在真正重要的东西上。
如果想开发伟大的软件，请千万要设定并遵守限制。让你走的每一步都朝着创造更成功的软件的方向，因为没有多余的资源去做其他的事情。
第19篇 去掉时间表中的细节
开始做计划的时候，要少计划细节。
为完整的屏幕设计设定一个交付日期是一个不错的里程碑，但为所有的中间部件（单为HTML或单为CSS）都设定期限可不太好，因为这让开发人员失去了自由，无法选择自己的最高工作方式。
在各交付物之间留出合理的时间，以便我们施展身手。
第20篇 每天改进产品的两个方面
在编程最热火朝天的日子，我们只能从那些很小的成功中获得持久的生产力。写代码本身带来的简单满足感或者是成名的幻想已经没办法一直激励我们了。每天都得有那么一丁点灵感——平常的动力源枯竭的时候，这算是一个底线。
决定每天改进产品的两个方面是一个很好的想法，这可以保证大型项目向前推进。
第21篇 为良好的工作环境投资
生产力依赖于我们工作环境中的每件小事。我们的工作环境应该尽可能减少这种令人分心的事。
速度快、功能多的机器会物有所值
这就是购买好的硬件至关重要的原因。
加大“地产”投资——三个显示器最好了
第22篇 列一张个人待办事项清单(37signals)
好的个人待办事项清单的内容
它是一张清单，且只有一张清单。
它有四个栏目，即今天、明天、后天和未来
它没有嵌套的依赖关系
容易修改
有若干个段任务构成
在线
把功能拆分成待办事项
每天重新评估重要事项
第23篇 和团队一起安排免打扰时间
你只有在时间高效工作时，才能有效率。
免打扰时间，欢迎你
不用回邮件
不会参见会议
不接电话
同事不会给你发即时消息
同事不会和你说话
别人能帮你
打扰别人是最后选择
第24篇 采用自治小团队的工作形式
程序员最好的工作环境是人员流动率很低的自治小团队。
第25篇 提高生产力，避谈“我们”
“我们”一下子毫无必要地把责任扔到了每一个人身上，它不去区分真正需要操心的人和需要专注其他工作的人。更重要的是，它掩盖了需要提供反馈时，你真正需要联系的人。
“我们”带来噪声
旁观者效应
出了紧急状况的人，与向一大群旁观者求组相比，向单个旁观者求组很可能会更有效。


第5章 复杂性
除非我们愿意删除软件中的功能，否则根本没有办法避免。如果我们不能摆脱复杂性，那么下一步就只能抑制它的增长。
第26篇 “嗅”出坏的复杂性
所谓坏的复杂性，就是根本毫无必要的复杂性。
“制帽师的故事”
第27篇 关于“简单”的悖论
让复杂性成为一个奇怪现象的原因：每个人都喜欢简单。
一个简单的解决方案不应该被认为是“缺了什么”，有时候，它恰到好处。
第28篇 复杂性就像挑棍游戏
作为开发人员，我们通过养成下面这些好习惯来尽快避免这个问题：封装代码、将变量定义到合适的作用域，把大块逻辑拆成小块，或者引入模式。我们努力让所有的小棍都并排摆放、互不接触，但在不断加入小棍的同时，要坚持把代码重构到“正确”的位置是在有点棘手。这个防线很容易就跨掉了。
每次加入新特性的时候，我们都很可能会干扰其他一些最初看起来并不直接相关的特性。加入的特性越多，干扰之处也会迅速增加。
第29篇 把复杂性藏起来
TurboTex证明了，即使手头的任务极度复杂混乱，软件也大可不必如此。你可以把所有的复杂性都隐藏起来，把这团乱麻转化为可以让人了解、让人使用的功能，从而创造出真正有意义且非常简洁的软件。
第30篇 “难编”可能意味着难用
如果细节变得异常难编，这可能意味着系统的实际功能难以让人理解。你可能在编好了无比复杂的东西之后松了一口气，但别人在用过之后可能对你恨得咬牙切齿。
第31篇 知道何时重构
写代码时要是想得太长远，也会导致复杂性的问题。
过早重构的危险
在开发周期中过早地过度架构，就会留下一个没有填满的坑，而架构不足，就会让我们丧失继续改进软件的选择和动力。
有所预见，但要谨慎预见。无论是小的改动，还是大的模式变化，每次决定重构的时候，都要知道你会得到什么、失去什么。
第32篇 确定编程的节奏
归根到底，软件的复杂性是必要的，这是为添加更多的功能所付出的代价。关键是要知道什么时候复杂是好的，什么时候是不好的。让自己的第六感告诉你，这一次，复杂性让所有人受害，我们的工作更像是艺术而不是科学。


第6章 教学
对我我们来说，从发现问题到解决问题的过程可能相当复杂，很难描述我们究竟是如何找到最后的解决办法的。但描述清楚这个过程至关重要，因为这是我们培养新一代激情洋溢的程序员的最好方式。
第33篇 教学不同于编程
第34篇 当心“知识魔咒”
第35篇 用浅显的例子
展示例子的时候，要让它浅显易懂。
第36篇 为简化不妨说谎
所以，要是最初的理解不是百分百正确会怎么样呢？坚实的基础会给人动力，而这个动力会让学生更快地达到高级阶段。
第37篇 鼓励自主思维


第7章 客户
在我们这一行，客户是我们的生命线。没有客户，我们做的东西到最后也可无非是自娱自乐罢了。
要和客户好好合作，首先要站在他们的立场看问题，然后再告诉他们，我们这边是怎么运转的。
第38篇 刁钻的客户无处不在
我们很容易抱怨客户太难缠，但要请记住，这种问题并不是只要我们才会遇到。
第39篇 软件黑魔法揭秘
那我们如何让客户欣赏我们的劳动呢？
有时候，要告诉客户我们是如何完成我们的工作的，尤其要告诉那些从未自己开发过软件的客户。即使在我们看来是完全显而易见的事情，对于其他人来说也并不是常识。
第40篇 设定软件的目标
在刚刚接触客户的时候，就把软件的目标设定好，和客户一起确定最终产品要达到什么效果，然后把它记下来。这样就会让“酷”和“尖端”之类的子弹哑火。设定好目标会让你说“不”时更有信心。
第41篇 激发热情，相信自己
第42篇 宽宏大度，和蔼可亲
要宽容。
此外，要养成和他们谈话的习惯。听听他们真实的声音，也让他们听听你的声音。拿起电话打给他们，不要只发邮件。你会惊讶地发现，一个体贴的声音能给你带来很大的转机。
第43篇 价值不只是工时
第44篇 尊重你的项目经理


第8章 代码
第45篇 写代码是不得已而为之
如果面对每个任务都直接进入“写代码”模式的话，我们就失去了一个认真思考为什么要写它的机会。反过来，如果我们能够批判性地思考为什么要写代码，就可以把大部分的编程时间花在真正重要的事情上。
第46篇 拿来主义的文化
如今，有了海量的高效平台，我们可能很快就会丧失对于底层如何工作的欣赏、兴趣和理解。
第47篇 代码是最好的初级程序员
代码的迷人特质
代码不会偷懒
代码不会嫌烦
代码不会遗忘
代码很廉价
代码很快
第48篇 把机器和人的工作区分开
找出可重复的编码任务
第49篇 从核心开始生成代码
定义输入源
选择合适的编程语言
在输入源中提取有用的信息
在给你的输入源提供者配上模板
组件驱动式设计
自动化时要小心
避免手动调整生成的代码
生成的代码要和真正的代码一样整洁
知道不要生成什么
第50篇 自主开发的情形
非要自己开发框架、平台或插件的三大原因：
深刻理解问题空间
发现问题并加以改进
程序员的傲骨


第9章 自豪感
9.1 形象是个问题
世界上其他人都把程序员看成一帮带着耳机的隐居型怪人，可我们实际上是富有激情的手艺人和思想者。
9.2 烹饪行业的一课
事实上，有时候我们是集医生、建筑师和统治者于一身。我们用代码创造奇迹，让梦想驰骋，苦心建造，然后指点江山。


参考文献

——fxleyu