程序员的自我修养
国庆期间， 读了这本《程序员的自我修养》，学到了很多东西， 下面分享给大家。
享受职业素养
我在招聘时常问的一个问题是：在你过去的工作中，遭遇过哪些印象深刻的困难，最后是怎么解决的？依我的经验，简历写得再漂亮的人，如果这个问题答不好，大都可以直接忽略。为什么会有这种结论？因为我们需要招聘的不是“经历丰富”的人，而是“有职业素养的人”。你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式、步骤以及反思的深度。拿恢复误删数据来说，这可能算非常简单的任务。我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。在我看来，相比问题本身的难度，解决问题的方式和步骤以及反思的深度，都体现出一个人的职业素养。
该书中， 作者有一句原话：
所以，请你把这本书看成我的错误大全，它记录了我干过的所有蠢事；也请你把这本书当成一份指引，让它带你绕开我曾经走过的弯路。
先看一个小故事：
1986 年 1 月 28 日，美国东部时间上午 11 : 39 , “挑战者”号航天飞机在发射仅 73 . 124 秒后，因右侧固体火箭推进器的故障，在 4 . 8 万英尺的高空化成碎片。七名航天勇士魂断苍穹，其中包括高中教师克丽斯塔 · 麦考利芙。麦考利芙的母亲亲眼目睹女儿在九英里高空中不幸遇难，彼时彼刻她脸上的表情，至今印刻在我的心头无法拂去。
挑战者号之所以解体，是由于高热气体从出现故障的固体火箭推进器的外壳接缝处泄露出来，喷到外部燃料舱体上。主液氢燃料舱底部发生爆炸，液氢被点燃，并将液氢燃料推人上方的液氧燃料舱中。与此同时，固体火箭推进器从下支架脱落，开始绕上支架滚动。推进器的机头捅破了液氧舱。整个飞行器因异常受力，逆向气流旋转，但同时仍然以 1 . 5 马赫的速度飞行。在巨大的过载下，挑战者号迅速被撕成碎片。
设计了推进器的莫顿 · 赛奥科公司的工程师事前已经知道密封圈有问题，并早在 7 年前就已经将这些问题报告给莫顿 · 赛奥科公司和美国宇航局的管理人员。事实上，在以前的发射中，密封圈就曾发生过类似的损坏，只是没有引发灾难而已。发射气温越低，后果就越严重。工程师们已经针对该问题设计了一个修复方案，但修复方案却迟迟未得以实施。
正是这个原因导致了悲剧的发生。
作为一个优秀的程序员应该有发现问题， 解决问题的能力。
专业主义
1. 清楚你要什么
“专业主义”有很深的含义，它不但象征着荣誉与骄傲，而且明确意味着责任与义务。这两者密切相关，因为从你无法负责的事情上不可能获得荣誉与骄傲。做个非专业人士可轻松多了。非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。如果非专业人士把事情搞砸了，收拾摊子的往往是雇主；而专业人士如果犯了错，只好自己收拾残局。
如果你不小心放过了某个模块里的一个 bug ，以致公司损失了 l 万美元，结果将会怎样呢？非专业人士会耸耸肩说：“状况总是难免的嘛。”然后像没事儿人一样继续写下一个模块。而专业人士会自己为公司的那 1 万美元买单
！哇，自脚腰包？那可真让人心疼唉！但专业人士就必须这么做。实际上，专业主义的精髓就在于将公司利益视同个人利益。看到了吧，“专业主义”就意味着担当责任。
2. 担当责任
作为程序员， 最常见的就是bug了， 故障排查非常困难，每次测试就要好几个小时。第一次修复失败了。第二次也没能成功。有时候试了好几次，等发现问题所在时，好几天已过去了。这期间， 如果每隔几小时就打电话问问题什么时候能解决，并一再告诉我让那些客户重新启用旧软件令他多么尴尬。最后，终于找出了缺陷所在，重新交付修复了问题的新程序，一切恢复正常。 老板也平静下来，不再提这段插曲，毕竟，他不是我的上司。事后，老板过来说：“你最好别再犯同样的错误。”我只能默默地点点头。经过反省，我意识到未对“例程”进行测试就交付软件是不负责任的。为了如期交付产品，忽略了测试环节，整个过程中只考虑要如何保全自己的颜面，却没顾及客户和雇主的声誉。本该早点儿担起责任，测试还未完成、自己不能按时交付产品。那么做绝非易事， 老板一定会不高兴，但客户不会丢失数据，客服经理也不会打电话来轰炸。
3. 了解你的领域
比如作为一门前端工程师，就需要特别掌握自己需要的东西， 别想着样样精通， 这个世界是没有人都能样样精通的， 只能专注发展自己的领域， 这样才能收获自己想要的，所以就拿前端工程师来说：
了解互联网产品开发相关流程和工作模式；
扎实的前端基础知识：HTML，CSS，JavaScript和jQuery；
了解和掌握HTTP协议，能从实际角度出发提升Web性能；
了解熟悉常见的前端框架、库、工具，例如：jQuery、AngularJS、vue.js、React、Grunt、Gulp 等
了解和使用过Node.js进行前端项目构建，熟悉Git
了解完这些后， 在这些基础上再进行深入学习，这样才会使你的技术进一步的更新
再比如说你要优化你的项目， 想想该怎样优化：
尽量减少HTTP请求 (Make Fewer HTTP Requests)
减少DNS 查找 (Reduce DNS Lookups)
避免重定向 (Avoid Redirects)
使得 Ajax 可缓存 (Make Ajax Cacheable)
延迟载入组件 (Post-load Components)
预载入组件 (Preload Components)
减少DOM元素数量 (Reduce the Number of DOM Elements)
切分组件到多个域 (Split Components Across Domains)
最小化iframe的数量 (Minimize the Number of iframes)
杜绝 http404错误 (No 404s)
4. 坚持学习
软件行业的飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍。不写代码的架构师必然遭殃，他们很快会发现自己跟不上时代了；不学习新语言的程序员同样会遭殃，他们只能眼睁睁看着软件业径直向前，把自己抛在后面；学不会新原则和技术的开发人员必将沦落，他们身边的人都日益卓越。你会找那些已经不看医学期刊的医生看病吗？你会聘请那些不了解最新税法和判例的税务律师吗？雇主们干嘛要聘用那些不能与时俱进的开发人员呢？
读书，看相关文章，关注博客和微博，参加技术大会，访问用户群，多参与读书与学习小组。如果你是． NET 程序员，就去学学 Java ; 如果你是 Java 程序员，就去学学 Ruby ；如果你是 C 语言程序员，就去学学 LisP ; 如果你真想练练脑子，就去学学 Prolog 和 Forth 吧！
5. 练习
业精于勤。真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼。只完成日常工作是不足以称为练习的，那只能算是种执行性质的操作，而不是练习。练习，指的是在日常工作之中练习技能．以期自我提升。对软件开发人员来说，有什么可以用以操练的呢？乍一听，这概念显得荒唐。但是再仔细想一会儿，想想音乐家是如何掌握演练技能的。他们靠的不是表演，而是背后刻苦的练习
6. 合作
学习的第二个最佳方法是与他人合作。专业软件开发人员往往会更加努力地尝试与他们一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到很多东西，而且能在更短的时间内更高质量地完成更多工作。并不是让你花全部时间一直和别人共事。独处的时间也很重要。虽然我很喜欢和别人一起编程，但是如果不能经常独处，我也一样会发疯。
7. 辅导
俗话说：教学相长。想迅速牢固地掌握某些事实和观念，最好的方法就是与由你负责的人交流这些内容。这样，传道授业的同时．导师也会从中受益。
同样，让新人融入团队的最好专业众士会视辅导新人为己任．办法是和他们坐到一起，向他们传授工作要诀。他们不会放任未经辅导的新手乱打乱撞。
8. 了解业务领域
每位专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。如果编写财务系统，你就应该对财务领域有所了解；如果编写旅游应用程序，那么你需要了解旅游业。你未必需要成为该领域的专家，但你仍需要勤勉，付出相当的努力来认识业务领域。
开始一个新领域的项目时，应当读一两本该领域相关的书，要就该领域的基础架构与基本知识对客户和用户访谈，还应当花时间和业内专家交流，了解他们的原则与价值观念。
最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨别、质疑规格说明书中的错误。
9. 谦逊
编程是一种创造性活动。写代码是无中生有的创造过程，我们大胆地从混沌之中创建秩序。我们自信地发布准确无误的指令，稍有差错，机器的错误行为就可能造成无法估量的损失。因此，编程也是极其自负的行为。专业人士知道自己自负，不会故作谦逊。他们熟知自己的工作，并引以为荣；
他们对自己的能力充满自信，并因此勇于承担有把握的风险。专业人士不是胆小鬼。然而，专业人士也知道自己会摔跟头，自己的风险评估也有出错的时候，自己也有力不从心的时候。
这时候，如果他们揽镜自照，会看到那个自负的傻瓜正对着自己笑。因此，在发现自己成为笑柄时，专业人士会第一个发笑。他从不会嘲讽别人，自作自受时他会接受别人的嘲讽。反之，他则会一笑了之。他不会因别人犯错就对之横加贬损，因为他知道，自己有可能就是下一个犯错的人。
专业人士都清楚自己的自负．也知道上天会注意到这种自负，并加以惩戒。如若果真遭遇挫折，上策就是一笑了之吧！
说“不”
引用尤达的一句名言：
能就是能， 不能就是不能， 别说“试试看” ———-尤达
每位经理都承担着工作职责，绝大部分经理也知道该如何尽职尽责。其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。同样，程序员也自有其工作职责所在，绝大多数程序员也知道该如何写的尽职尽责。如果他们是专业程序员的话，他们也会竭尽所能地去追求和捍卫自舟的目标。
你的经理要求你在明天之前完成登录页面，这就是他在追求和捍卫的一个目标，那是尽他的工作职责。如果你明知第二天之前不可能完成登录页面，嘴上却说“好的，我会试试的”，那么便是你失职了。这时候．唯一的尽职方式便是说“不，这不可能”。可是难道你不该照经理说的话去做吗？当然不该，你的经理指望的是，你能像他那样竭尽所能地捍卫自己的目标。
这样你们俩才能得到可能的最好结果。可能的最好结果，是你和你的经理共同追求的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。协商过程有时可以相当愉快。
但是到了第二天， 你的任务没有完成， 你的这句“我试试”就成了你的最大的败笔， 这也从侧面显示出你的不称职。 另外， 你觉得经理会怎样看待你， 会嫌你技术菜吗？当然， 万事皆有可能。
说”是“
很少有人会认真对待自己说的话，并且说到做到。有些人在说话时是认真的，但他从来都不会说到做到。而更多的人在做出承诺后，几乎从不会认真去履行诺言。是否听过有人经常说“天哪，我真该减减肥了”？但你知道其实他还会是老样子，什么改变都不会发生。这样的事确实屡见不鲜。为什么我们总会有种奇怪的感觉，觉得人们大多数时候并没有全力去兑现承诺呢？
更糟的是，我们常常会因为直觉摔跟头。有时我们轻信他人会说话算话说到做到，但事实上他并没有像承诺的那么去做。我们可能会相信某位开发人员所说的，他们能在一星期内完成原本两星期才能完成的任务，但其实他们是迫不得已才这么说的。我们不能轻易相信此类承诺。我们可以通过一些语言上的小花招，而非依靠直觉本能，来判断对方到底能不能“说话算话、说到做到”。同时，改变我们自己的说话方式和内容。当我承诺某事时，必须认真对待承诺。
识别“缺乏承诺”的征兆
在承诺做某事时，应当留意自己的用词，因为这些用词透露了我们对待承诺的认真程度。实际情况当然不只是注意在我们所说的话中是否含有某几个词这么简单。但如果在其中找不到这几个神奇的词，很可能我们自己根本就没把承诺太当真，或者，这表明我们可能不相信这些词具备的功效。
以下示例中包含的几个用词和短语，会透露“缺乏承诺”的蛛丝马迹，要注意搜寻。
需要 l 应当。“我们要把这活做完。”“我需要减肥。”“有人应当负责去推动这件事。”
希望 l 但愿。“希望明天我能完成这个任务。”“希望改天我们能再见面。” ‘ ’但愿我有时间做这件事。”“但愿电脑能快点。
”让我们（而不是“让我”）。“让我们回头再见。”“让我们把这事做完。
只要去搜寻你就会发现，在自己身边，此类词语比比皆是，甚至在你对别人说的话里也时常出现。
你会发现，我们有极力逃避承担责任的倾向。
如果你或者其他人工作的一部分依赖于那些承诺，那么大事不妙了。不过你已经迈开了第一步，开始能够在你周边的人（包括你自己）的话里捕获可能存在“缺乏承诺”的征兆了。
时间管理
1. 注意力
编程是需要持续投入精力和注意力的智力活动。注意力是稀缺的资源，它类似魔力点数．。如果你用光了自己的注意力点数，必须花一个小时或更多的时间做不需要注意力的事情，来补充它。
我不知道该怎么描述注意力点数，但是我感觉它是有形（或许无形）的，能影响注意力的集中和分散。无论如何，你肯定可以觉察到注意力点数的存在，也同样可以感知它是否耗尽。职业开发人员会学习安排时间，妥善使用自己的注意力点数。我们选择注愈力点数充裕的时候编程，在注意力点数缺乏时做其他事情。
注意力点数也会随时间流逝而减少。如果不及时使用，它就会消失。会议之所以具有巨大的破坏力，原因之一就在于此。如果你所有的注意力点数都用在了会议上，编程时就大脑空空了。
2. 咖啡因
毋庸置疑，对有些人来说，适量的咖啡因可以帮他们更有效地使用注意力点数。但是请小心，咖啡因也会给你的注意力添乱。太多咖啡因会把你的注意力偏转到奇怪的方向。太浓的咖啡会搞得你一整天都沉溺于不重要的事情。咖啡因的用量和接受程度因人而异。我个人的做法是，早上一杯浓咖啡，中午一杯无糖可乐。有时候会加倍．但通常这就是上限了。
3. 睡眠
睡眠的重要性怎么强调都不为过。美美一觉醒来，我的注意力点数是最充裕的。好好睡上 7 个小时，我就有足够的注意力点数去做好 8 小时的工作。专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力点数去上班。
协作
我们并非是因为喜欢和人们在一起工作才选择做程序员的。人际关系一团糟，而且不可预见。编程用的机器则整洁，行为也可预见。如果可以一个人呆在房间里数个小时沉浸在一些真正有趣的问题里，那将会是最开心的时光。
好吧，我这么说可能有点儿以偏概全了，确实也有不少例外。有许多程序员很善于和别人共事合作，享受其中的挑战。但是整个群体的平均状况还是朝我所描述的方向发展的。我们，程序员们，还是最享受面无表情的沉思，把自己像蚕茧一样裹起来，沉浸于问题思考中。
专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们、业务分析师们、测试工程师们和其他团队成员很好地协作，深刻理解业务目标。这并不是说你必须要成为业务方面的老学究，而是说你需要理解手上正在编写的代码的业务价值是什么，了解雇你的企业将如何从你的工作中获得回报。
专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛臀崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。
因此，专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。简而言之，他们会将注意力放在如何与业务同舟共济上。
也许我们不是因为通过编程可以和人互相协作才选择从事这项工作的。但真不走运，编程就意味着与人协作。我们需要和业务人员一起工作，我们之间也需要互相合作。我知道，我知道。如果把我们关在一个有六个大屏幕显示器的房间里，里面有高速宽带网络，有一组超快的处理器并行队列，有用不尽的内存和磁盘，源源不断的健怡可乐和香脆的玉米薯条，”肠岂不是棒极了’唉，伙计，不是这样的。如果我们真想终生能以编程度日，那么，一定要学会交流 ― 和人们交流。