码迷,mamicode.com
首页 > 其他好文 > 详细

遵循高效编程之原则

时间:2015-04-06 17:22:14      阅读:153      评论:0      收藏:0      [点我收藏+]

标签:高效   编程   原则   

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

永远都是你的错误

   在怨天尤人之前,我们应该做好自我反省,努力先把自身的问题解决了。
      这个原则永远都必须去遵守,很多时候,包括我,在遇到一个编程问题的时候,总是“情不自禁”的埋怨到:“这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,好好的优化一下吧。
       作者提到一个观点是“善待匿名用户和注册用户”,我觉得这个观点足够的好,无论是匿名用户还是留有其名的用户,我们必须要能够为他们都创造很好的体验效果。我的客户总是有一个我无法忍受的观点,总是让我把旧的代码、性能差的交易平台代码给一些他认为烂的交易所用,我这个时候,总是会有一股无名业火,我觉得这种做法,太过狭隘。
       性能好,才能抓住客户的心理,进而带动更大的潜在用户,而不是用劣质的代码敷衍那些我们看不起的客户。

遵循高效编程之原则

标签:高效   编程   原则   

原文地址:http://blog.csdn.net/qing_gee/article/details/44902415

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!