高效能程序员的修炼-总结篇

在此，无关技术，只是从效能上探讨下，如何提升工作效率，结合了大量研究，分析，实践证明。

同一时间最好只做一个任务

温伯格提出一个经验法则，用以计算由于切换项目而引起的浪费。

即使你只做一个项目，这种情况也可能会发生，你会被邮件、聊天所打扰。

这里的奥秘是：在你管理程序员的时候，你会发现切换任务会花费很长时间，那是因为编程这类任务需要你在大脑记住很多东西。你同时记住的东西越多，编程效率就越高，一个程序员在全力编程的时候，脑袋里面同时记着数不胜数的东西（程序里的一切），包括变量名称、数据结构、重要的编程接口、他们自己写的常用工具函数的名字，甚至是他们存放源代码的子目录的名称。如果你送那个程序员休假三周，他会把这些东西忘得一干二净，人类的大脑似乎把这些东西移除了短期的随机存储器（RAM），然后把他们备份到了磁盘上；但再想通过磁盘恢复那些记忆，也许要花上一辈子的时间。

可是我们在工作的过程中很难做到只做一个项目，在开发的过程中被别人的问题打扰，以前的代码出了bug，别人过来找你，等等，在办公室想安心写代码，不存在的。下面我介绍下我的处理方式：

• 工作中我一般都会带着耳机，但未必会放歌曲，以此来避免外界打扰
• 当有测试、前端来找我问问题的时候，我一般都是能马上回答的我回回答一下，如果不能，我会回复说等几分钟，我写完这段东西去找你
• 对于钉钉发送的消息，除非有人钉我，在桌面弹出，否则我都会过一段时间才会看一次，把钉钉消息的声音提示关掉很重要

性能的重要性

根据谷歌的真实测试，请求时间消耗每增加100ms，损失的性能都是巨大的，所有在压测环境使用链路请求时间监控工具，并极力优化性能，是非常重要的。
如果自己写的代码想要优化性能，就需要知道，数组、链表、栈、队列、散列表、二叉树、堆、跳跃表、图、树的操作原理和算法：递归、排序、二分查找、搜索、哈希、贪心算法、分治算法、回朔算法、动态规划、字符串匹配算法，以及“算法复杂度大O”的基本原理。
关于算法复杂度的文章，博主找到一篇说明的比较清晰的：算法时间复杂度、空间复杂度

领导团队适得其法

Dennis Forbes曾经发表过一篇文章，名为“有效地融入软件开发团队”。我觉得他很出色地概括了关于有效领导方面的策略。他用一封假想的电子邮件开头，描述了被人当做强制执行着的弊端：

我最近被拉取帮助一个软件开发团队完成一款产品的开发，具体的要求是协助一些web程序的编码，我尽了自己最大的努力去融入这个团队，热心地帮助他们以赢得一些信誉和尊敬。
我时长转发“Joel on Software”上的各种小文章给大家，还建议公司里摆上一堆像《代码大全》类的书籍。任何事情，只要我觉得可以做的更好，我都会尽力给大家指出来，我经常浏览源代码库，以找出可以让其他成员工作的更好的方法。
当其他开发者来向我寻求帮助的时候，我不仅帮他们解决实际的问题，还举一反三——指出他们在开发上的问题，教他们怎样改进打字形式，告诉他们该使用哪种命名规范，提倡一种更好的代码编辑工具。
然而这些努力似乎都没起到作用，我还是会常常受到他们的抵制，而且我觉得整个团队不是很喜欢我。我的很多建议都没有被采纳，并且我觉得有些人给我的回应是毫不掩饰的讽刺。
我到底哪里错了？

相信我们都曾和这样的人一起工作过。也许我们自己就是这样的人。即使你有最好的意图，并且已经熟读我给大家推荐的优秀书籍，你最终还是会落得跟枪炮士官哈特曼一样的下场：被你自己的团队“枪杀”了。
在文章最后 Dennis对如何避免被自己的团队“枪杀”，做了一个很有想法的总结：

保持谦虚：总是先假定你是错的。虽然开发者的确是会犯错误的，并且作为一个新人，你理所当然应该帮助其他人发现和修正错误，但是在你骄傲地宣布你的发现之前，你应该努力确保你的观察结果是正确的。如果你总是喊着“狼来了”，你的信誉将受到巨大的打击。
提出建设性的批评时要小心：开发者更容易接受非正式的建议和具有巧妙引导性的问题，而不是把同样的内容以电子邮件的形式发送给整个开发组。扩大受众面可能会引起开发者的防御和逆反。团队总是会去猜测你的动机。如果你贬低他们的工作是为了提升你自己，你会因此被投诉而流芳的。
要想赢得信誉和尊敬，最好的方法就是努力工作并且取得实实在在的成绩：廉价而肤浅的替代品——例如群发关于最佳实践的邮件，或者转发别人鼓吹某种关于“银弹”的评论——它们不会产生同样的效果，到头来你可能也只是枉费心机。
百说不如一干：实施一种新的代码控制机制，或者实现一种新技术——这些事情说起来都很容易。所有人都知道，你只是在声明这些主意是你想出来的，而实现他们所需付出的艰苦努力却最终会落在别人的头上——他们会因此而讨厌你。如果你想建议些什么，你应该为此付出实际的行动、做好充分的准备。例如，解决技术接入的难点。这并不能保证团队你的倡议会一呼百应，而且你还可能徒劳无功，但团队会意识到：你付出了努力，你再积极的推动它，而不是在试图捡便宜。
真的关心那些你所领导的人：有的架构师领导为了让程序员快速开发，当看到员工在学习一些开发过程中有疑问的知识的时候，他会阻止你，当你加班在公司学习的时候，他们换个说法让你回家，因为有些人虽身为领导，但他看到你提高便心生妒意，而且这种领导还会美其名曰“为你好”，其实人都不是傻子，如果你真的为别人好，别人感受得到。我想说遇到这种领导就离职把，没有提升空间，没有创新空间，更没有发展空间。
最有效的一种技术领导就是以身作则

程序员的高效工作场所

符合人体工程学的设施

如果有时候会在家里办公的话，花比较高的金额购买一把在家用的舒适椅子是很重要的。

加强代码测试

测试先行的优点

1. 单元测试可以证明你的代码是能真正解决问题的
2. 你可以获得一个底层模块的回归测试工具
3. 你可以在不破坏现有功能的基础上持续改进设计
4. 一边写单元测试，一边写实现代码，这种工作方式更有乐趣
5. 它们可以被用来真实地展示开发进度
6. 单元测试可以被用作示例代码
7. 它逼着你在写代码之前做好计划
8. 它可以降低bug修复的成本
9. 单元测试甚至比代码审查的效果还要好
10. 它实际上为程序员消除了工作上的障碍
11. 单元测试可以催生更好的设计
12. 它比不写单元测试而直接写代码的效率更高

程序员，你幸福吗？

《哈佛幸福课》的作者概括了幸福的真谛

1. 经历胜过物质：我的理解是，一个人更应该在意自己做过什么，而不是得到了什么
2. 助人为乐：帮助别人的时候也是在帮助自己，任何可以帮助别人的事情都可以加深你和别人的关系，但是有条准则，这个人，这件事值不值得你出手，以为无底限地去帮助别人反而让自己跟傻子没有区别
3. 让幸福细水长流：人是最能适应变化的，因此，最有效的花钱方式是经常买来一些小变化，而不是花大钱一下买来一个大惊喜，然后坐等新鲜劲很快过去。就拿幸福来说吧，频率比强度更重要。大家需要改变一下观念，记住很多次小的，愉快地购买能比一次巨额的购买带更能有效的给你幸福感
4. 少买保险：关于为什么有这条，我也不太明白
5. 为将来买单：即刻的喜悦可能会让你冲动买下承受不起的东西。它无情地扼杀了你期待的感觉，而期待恰恰是幸福的源泉。
6. 三思而后行
7. 小心比较购物的陷阱：比如，花2元钱买到一块巧克力（不错的买卖），跟这块巧克力好不好吃其实没什么关系。
8. 随大流：不要高估你的能力，别以为你能预测你会有多喜欢某样东西。从科学的角度讲，我们在这方面及其不擅长！但如果某些东西可靠地给其他很多人带来了幸福，那它很可能也会给你带来幸福。在你做出购买决定之前，请认真考量一下别人的看法和用户评论。

赚钱不容易。幸福更不容易，请记住上面8点。

最后，是我想说的，也是所有程序员都要思考的，你选择做程序员是为了什么？喜欢么，热爱么？还是为了这个行业还不错的报酬？
我从事这个行业已经有些年头，但是我称不上喜欢或者热爱，期初只是让自己有资本在世界上活下去，其实如果我大学不是被调剂到了相关专业，我是一定不会去做计算机相关工作的，对我来说，这只是我的一份工作，我要靠此养家糊口，仅此而已，但是这就像是一个江湖，进入之后就再也无法退出，因为没人会想让自己多年付出的努力，做出的积累付诸东流，我的路只有砥砺前行。
但是我再过一年就30了，随着年龄的增长，身体会越来越差，脑子反应会越来越慢，这是一个需要体力去加班的行业，没有人能逃脱的了岁月的摧残，终究我们会被时代所淘汰，未来还是属于那些年轻人的，我们将何去何从，是选择通过惊人的自律来延长职业生涯，还是等到年纪不行的时候，放弃在第一线的工作而另谋出路，是每一个程序员都必经的选择。
同时这个行业有无止尽的工作与加班，你会丧失与妻子相聚，陪伴孩子，养育父母的时间，这些时间都是一去不复返，失去这些去换一份还不错的工作究竟值不值得，你从事程序员的目的是什么，你想通过你的职业得到什么，你所得到的与你所失去的是否值得，也是每一个程序员需要去权衡的问题。你做此行业的目的是什么？