标签：高效 编程 原则
前言：清明时节雨纷纷，路上行人欲断魂。借问酒家何处有？牧童遥指杏花村。对于清明节，想必杜牧这首诗肯定会让你呼之既出。今天是清明放假的最后一天，打扫完家里的卫生，我就必须要抓紧美好的时光来记录下《高效能程序员的修炼》一书第三章“高效编程之原则”的读书札记。
永远都是你的错误
在怨天尤人之前，我们应该做好自我反省，努力先把自身的问题解决了。
这个原则永远都必须去遵守，很多时候，包括我，在遇到一个编程问题的时候，总是“情不自禁”的埋怨到：“这TM都谁写的代码啊？”、“这肯定是你的问题，你好好看看”、“jar包是旧的，先换个jar包再说”、“明明代码没有错，怎么回事”。这些想法容易让我们失去理智，忽略自身的问题，而将错误归咎于他人，而这些都将影响到我们解决问题的效率。
在报告的错误中，有95%是由程序员造成的，2%是有操作系统造成的，2%是其他软件造成的，1%是由硬件造成的。
OK，在出现问题的时候不要再逃避责任了，不管代码是不是由你编写，只要是你需要负责的，你就必须把责任扛下来。从自己写的代码找起，直到你找到确凿的错误。我相信，你肯定会有这样的感觉：当你找出一个他人的问题时，你会无比满足，因为你在这方面超越了他；当你找出一个自身的问题时，你会非常窃喜，因为终于免得被别人嗤笑。
大道至简
|
if(s==String.empty)
if(s=="")
|
看完上面的代码，你想用哪一种？对于这两种代码，不必争吵，我个人认为我会使用第二行代码，因为它更加简洁和直白，我喜欢纯粹和简约。
代码不是什么好东西。代码会随着时间的推移而渐渐腐烂，代码需要周期性的维护。
显然，我认为代码是好东西，但是代码的确会随着时间推移而腐烂，这其中的原因不是代码不好，而是随着时间，你的能力得到了提高，这个时候，回首往日依稀岁月，你会发现你原来的代码的确很烂，那么就修剪他们吧，让他们更加的纯粹。所谓更好，也就是更简，仔细看看我家的洗衣机，我真心觉得它太过复杂，面板上那么多功能都是废弃的，我甚至都懒得去用他们，真正的产品，不能为了显示自己的功能有多强大，而是让我们消费者作为真正的受用群体。
避免写注释
你应该专注于编写代码，而忘了注释这种东西。
显然，避免写注释是个好想法，因为高手的代码本身就孕育着注释，他们不会写无聊的注释来解释这段代码的功效。然而只有代码没有注释是一种渐变的过程，就如同我们看过的古装武侠小说，小喽啰都是在寻找各种各样的秘籍，高手会只钻研一门技艺，如九阴白骨爪，而最强的高手，往往都是扫地大爷，随着年龄和觉悟的增长，我们会最终实践这条原则。
很不幸，我所处的阶段还不允许我任何注释都不写，我也还没有达到重构我的代码直到它不需要任何注释。对于这个方面，我们不需要太过纠结，毕竟能力所限，主要我们的注释和代码交相辉映就perfect了。因为注释可以帮助我们记忆，并且理清复杂的思绪。
学会读源代码
不关文档上怎么说，源代码才是最终的实现，是你所能找到的最新的、最准确的、最好的文档。
在读源代码这方面，我的能力和意识还非常欠缺，也是亟待加强的。从意识形态上，我还处于一个阶段就是：“源代码太过复杂，读读文档就能解决问题了”。这个想法在很多时候，让我陷入困局，我花费了大量的时间去找度娘，在茫茫大海中寻找着我想要的答案，而最终的都让我失望而归。
而在我冷静下来，尝试去翻阅源码的时候，结合自身的开发逻辑，很快就能定位到问题的真正所在。下面是书中我认为非常好的论断，我觉得我需要照搬过来：
有些时候，文档是不完整的，甚至是错误的，而源代码从来不会说谎。对于有经验的程序员来说，看源码远比看文档要快些。
我鼓励开发人员在源码中畅游，起初，他们很害怕。“那个项目太大啦，我永远无法把问题找出来！”、“我没那么聪明，看不懂那些代码”，现在，他们都感谢我强迫他们在别人的代码里潜水。
如果一个软件在我的机器上运行，那么它就是我的软件，我必须负责到底。
那么不管怎样，强迫自己钻进源码中吧！
向橡皮鸭求助
当你看到这个标题的时候，你肯定会好奇或者惊诧，向橡皮鸭求助个毛线啊。作者对于这个标题有一个故事，我就不需要赘述了，你当然可以买书自己看看，这本书太棒了。
在向别人求助的时候，首先把问题抛给自己，看看自己是否有解决之道。向别人提问题的时候，书写的方式要尽可能站在解决问题者的角度，也许等你把问题写完的时候，你就豁然开朗了。向橡皮鸭求助，是一种态度，那就是完全投入地向一个没有生命体的物体问一个详尽的问题。
- 用足够多的细节来描述发生的状况。
- 告诉我们你为什么需要知道答案。
- 说一说你为了这个问题都做过什么研究，你不能什么都不做就跑出来要答案。
- 想要从别人那里获得答案，就必须要舍得付出，什么都不是无偿的，别人如果要回答你的问题就要花费一定的时间。
我突然有一个想法就是，诸如京东的购物评价，如果真的做的好的话，就不应该允许出现毫无价值的评价“很不错。。。。。。。”、“还好了。。。。。。。。。。。”这种只是为了获取20个京豆的评论都必须要去除，评论是为了帮助下一个消费者的。
- 我碰到一个问题
- 我决定把这个问题提到CSDN
- 我很笨拙的写下我的问题
- 我意识到这个问题根本说不通
- 我重新思考我该如何提出问题
- 我意识到我正在一个完全错误的方向上解决这个问题
- 我从头再来，发现很快解决了问题
OK，如果你也曾发生作者所说的这种情形，我想，就这样去做吧，也许你自己就解决了自己的问题。
创新以人为本
“哎，我这个想法不错，我觉得真是一个别人都想不到的创意，你觉得怎么样，是不是很想赞美我啊？”我无不自豪的向同伴炫耀道，同伴不假思索的回答道，或许是带有一丝嘲笑：“哎呀，不错啊，不过好像一文不值啊”。
了解苹果历史的人都知道，图形化界面并不是苹果率先提出的，而是一家叫做“施乐”的公司提出的，而乔布斯“偷窃”了这个创意，使其成为苹果电脑的代表作，而后来，微软显然同样剽窃了这个创意。为什么苹果和微软会成功，施乐会失败。真正的原因不在谁剽窃了谁的创意，而是谁更愿意把想法付诸于实践，只有付诸于实践的创意才具有价值。
如果你把一个好的创意给一个普通的团队，他们会把它搞砸，如果你把一个普通的创意给一个号的团队，他们会加以改善。
所以说，不要太在意你的创意有没有被剽窃，而是关注于执行，如果你的想法自己无法去执行，那么就会失去其价值。所以我要告诫自己，如果我有一个好的想法，我必须要和我的团队一起，把他实现，否则毫无价值。
你的团队通过了电梯测试吗
电梯测试，就是所谓的在电梯的升降过程中，你如何向同处于一个电梯之内的客户推销你的产品，你能在短时间内获得成功，还是一无所获。
很多时候，我问同伴，你在干嘛，回答最多的是，在写代码啊。和程序员沟通就是会很累，他不会告诉你他在实现一个让服务器时间和客户端时间同步的功能，除非你打破砂锅问到底。
这个原则无非就是告诉我们程序员，我们不仅仅是在敲代码，我们要明确我们在创造一个什么样的价值体系。很多时候，爸妈问我，“编程都做些什么啊？”我回答：“反正说了你也不懂。”现在我意识到，我的回答也许就会改一改：“编程做的有：我们可以让手机接通电话，能通过我们编写的代码让你听到我在说话，同时让你听到我在说话”。
性能致胜
网站载入和显示的速度越慢，使用它的人就越少。
看看CSDN的评论机制吧，你好不容易写了一大串的文字来作为对别人文章的评论，然而等你迫不及待的点了确认后，god来了，按钮会灰掉持续很长一段时间，并且久久看不到你是否已经评论有效，我经常都是重新打开一个网页，在上面刷新看看我的评论是否有效，然后再关闭前一个提交中的网页。求求CSDN，好好的优化一下吧。
作者提到一个观点是“善待匿名用户和注册用户”，我觉得这个观点足够的好，无论是匿名用户还是留有其名的用户，我们必须要能够为他们都创造很好的体验效果。我的客户总是有一个我无法忍受的观点，总是让我把旧的代码、性能差的交易平台代码给一些他认为烂的交易所用，我这个时候，总是会有一股无名业火，我觉得这种做法，太过狭隘。
性能好，才能抓住客户的心理，进而带动更大的潜在用户，而不是用劣质的代码敷衍那些我们看不起的客户。
遵循高效编程之原则
标签：高效 编程 原则
原文地址：http://blog.csdn.net/qing_gee/article/details/44902415
