标签：注释 高效 原则 一个 代码 编程 问题 源代码 创意

前言：清明时节雨纷纷，路上行人欲断魂。借问酒家何处有？牧童遥指杏花村。对于清明节，想必杜牧这首诗肯定会让你呼之既出。今天是清明放假的最后一天，打扫完家里的卫生，我就必须要抓紧美好的时光来记录下《高效能程序员的修炼》一书第三章“高效编程之原则”的读书札记。

永远都是你的错误

   在怨天尤人之前，我们应该做好自我反省，努力先把自身的问题解决了。       这个原则永远都必须去遵守，很多时候，包括我，在遇到一个编程问题的时候，总是“情不自禁”的埋怨到：“这TM都谁写的代码啊？”、“这肯定是你的问题，你好好看看”、“jar包是旧的，先换个jar包再说”、“明明代码没有错，怎么回事”。这些想法容易让我们失去理智，忽略自身的问题，而将错误归咎于他人，而这些都将影响到我们解决问题的效率。        在报告的错误中，有95%是由程序员造成的，2%是有操作系统造成的，2%是其他软件造成的，1%是由硬件造成的。       OK，在出现问题的时候不要再逃避责任了，不管代码是不是由你编写，只要是你需要负责的，你就必须把责任扛下来。从自己写的代码找起，直到你找到确凿的错误。我相信，你肯定会有这样的感觉： 当你找出一个他人的问题时，你会无比满足，因为你在这方面超越了他；当你找出一个自身的问题时，你会非常窃喜，因为终于免得被别人嗤笑。

大道至简

if(s==String.empty) if(s=="")

看完上面的代码，你想用哪一种？对于这两种代码，不必争吵，我个人认为我会使用第二行代码，因为它更加简洁和直白，我喜欢纯粹和简约。      代码不是什么好东西。代码会随着时间的推移而渐渐腐烂，代码需要周期性的维护。      显然，我认为代码是好东西，但是代码的确会随着时间推移而腐烂，这其中的原因不是代码不好，而是随着时间，你的能力得到了提高，这个时候，回首往日依稀岁月，你会发现你原来的代码的确很烂，那么就修剪他们吧，让他们更加的纯粹。所谓更好，也就是更简，仔细看看我家的洗衣机，我真心觉得它太过复杂，面板上那么多功能都是废弃的，我甚至都懒得去用他们，真正的产品，不能为了显示自己的功能有多强大，而是让我们消费者作为真正的受用群体。

避免写注释

     你应该专注于编写代码，而忘了注释这种东西。      显然，避免写注释是个好想法，因为高手的代码本身就孕育着注释，他们不会写无聊的注释来解释这段代码的功效。然而只有代码没有注释是一种渐变的过程，就如同我们看过的古装武侠小说，小喽啰都是在寻找各种各样的秘籍，高手会只钻研一门技艺，如九阴白骨爪，而最强的高手，往往都是扫地大爷，随着年龄和觉悟的增长，我们会最终实践这条原则。       很不幸，我所处的阶段还不允许我任何注释都不写，我也还没有达到重构我的代码直到它不需要任何注释。对于这个方面，我们不需要太过纠结，毕竟能力所限，主要我们的注释和代码交相辉映就perfect了。因为注释可以帮助我们记忆，并且理清复杂的思绪。

学会读源代码

      不关文档上怎么说，源代码才是最终的实现，是你所能找到的最新的、最准确的、最好的文档。       在读源代码这方面，我的能力和意识还非常欠缺，也是亟待加强的。从意识形态上，我还处于一个阶段就是：“源代码太过复杂，读读文档就能解决问题了”。这个想法在很多时候，让我陷入困局，我花费了大量的时间去找度娘，在茫茫大海中寻找着我想要的答案，而最终的都让我失望而归。       而在我冷静下来，尝试去翻阅源码的时候，结合自身的开发逻辑，很快就能定位到问题的真正所在。下面是书中我认为非常好的论断，我觉得我需要照搬过来：        有些时候，文档是不完整的，甚至是错误的，而源代码从来不会说谎。对于有经验的程序员来说，看源码远比看文档要快些。     我鼓励开发人员在源码中畅游，起初，他们很害怕。“那个项目太大啦，我永远无法把问题找出来！”、“我没那么聪明，看不懂那些代码”，现在，他们都感谢我强迫他们在别人的代码里潜水。     如果一个软件在我的机器上运行，那么它就是我的软件，我必须负责到底。      那么不管怎样，强迫自己钻进源码中吧！

向橡皮鸭求助

      当你看到这个标题的时候，你肯定会好奇或者惊诧，向橡皮鸭求助个毛线啊。作者对于这个标题有一个故事，我就不需要赘述了，你当然可以买书自己看看，这本书太棒了。       在向别人求助的时候，首先把问题抛给自己，看看自己是否有解决之道。向别人提问题的时候，书写的方式要尽可能站在解决问题者的角度，也许等你把问题写完的时候，你就豁然开朗了。向橡皮鸭求助，是一种态度，那就是完全投入地向一个没有生命体的物体问一个详尽的问题。

• 用足够多的细节来描述发生的状况。
• 告诉我们你为什么需要知道答案。
• 说一说你为了这个问题都做过什么研究，你不能什么都不做就跑出来要答案。
• 想要从别人那里获得答案，就必须要舍得付出，什么都不是无偿的，别人如果要回答你的问题就要花费一定的时间。

     我突然有一个想法就是，诸如京东的购物评价，如果真的做的好的话，就不应该允许出现毫无价值的评价“很不错。。。。。。。”、“还好了。。。。。。。。。。。”这种只是为了获取20个京豆的评论都必须要去除，评论是为了帮助下一个消费者的。

1. 我碰到一个问题
2. 我决定把这个问题提到CSDN
3. 我很笨拙的写下我的问题
4. 我意识到这个问题根本说不通
5. 我重新思考我该如何提出问题
6. 我意识到我正在一个完全错误的方向上解决这个问题
7. 我从头再来，发现很快解决了问题

OK，如果你也曾发生作者所说的这种情形，我想，就这样去做吧，也许你自己就解决了自己的问题。

创新以人为本

         “哎，我这个想法不错，我觉得真是一个别人都想不到的创意，你觉得怎么样，是不是很想赞美我啊？” 我无不自豪的向同伴炫耀道，同伴不假思索的回答道，或许是带有一丝嘲笑： “哎呀，不错啊，不过好像一文不值啊”。         了解苹果历史的人都知道，图形化界面并不是苹果率先提出的，而是一家叫做“施乐”的公司提出的，而乔布斯“偷窃”了这个创意，使其成为苹果电脑的代表作，而后来，微软显然同样剽窃了这个创意。为什么苹果和微软会成功，施乐会失败。真正的原因不在谁剽窃了谁的创意，而是谁更愿意把想法付诸于实践，只有付诸于实践的创意才具有价值。         如果你把一个好的创意给一个普通的团队，他们会把它搞砸，如果你把一个普通的创意给一个号的团队，他们会加以改善。        所以说，不要太在意你的创意有没有被剽窃，而是关注于执行，如果你的想法自己无法去执行，那么就会失去其价值。所以我要告诫自己，如果我有一个好的想法，我必须要和我的团队一起，把他实现，否则毫无价值。

你的团队通过了电梯测试吗

       电梯测试，就是所谓的在电梯的升降过程中，你如何向同处于一个电梯之内的客户推销你的产品，你能在短时间内获得成功，还是一无所获。        很多时候，我问同伴，你在干嘛，回答最多的是，在写代码啊。和程序员沟通就是会很累，他不会告诉你他在实现一个让服务器时间和客户端时间同步的功能，除非你打破砂锅问到底。        这个原则无非就是告诉我们程序员，我们不仅仅是在敲代码，我们要明确我们在创造一个什么样的价值体系。很多时候，爸妈问我，“ 编程都做些什么啊？”我回答：“ 反正说了你也不懂。”现在我意识到，我的回答也许就会改一改：“编程做的有：我们可以让手机接通电话，能通过我们编写的代码让你听到我在说话，同时让你听到我在说话”。

性能致胜

         网站载入和显示的速度越慢，使用它的人就越少。         看看CSDN的评论机制吧，你好不容易写了一大串的文字来作为对别人文章的评论，然而等你迫不及待的点了确认后，god来了，按钮会 灰掉持续很长一段时间，并且久久看不到你是否已经评论有效，我经常都是重新打开一个网页，在上面刷新看看我的评论是否有效，然后再关闭前一个提交中的网页。求求CSDN，好好的优化一下吧。        作者提到一个观点是“善待匿名用户和注册用户”，我觉得这个观点足够的好，无论是匿名用户还是留有其名的用户，我们必须要能够为他们都创造很好的体验效果。我的客户总是有一个我无法忍受的观点，总是让我把旧的代码、性能差的交易平台代码给一些他认为烂的交易所用，我这个时候，总是会有一股无名业火，我觉得这种做法，太过狭隘。        性能好，才能抓住客户的心理，进而带动更大的潜在用户，而不是用劣质的代码敷衍那些我们看不起的客户。

标签：注释,高效,原则,一个,代码,编程,问题,源代码,创意
来源： https://blog.51cto.com/u_2324584/2934917

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。