<code id="lcjj3"></code><mark id="lcjj3"></mark>

          <output id="lcjj3"></output>
          首页 | 社区 | 博客 | 招聘 | 文章 | 新闻 | 下载 | 读书 | 代码
          亲,您未登录哦! 登录 | 注册
           您所在的位置:编程爱好者网站新闻 - 正文
           
           

          每个程序员都该知道的10大编码原则

          19159 次阅读 | 发布时间:2014-10-22 | 向本站投递新闻
          打印文章

                  1. 偏执

                  这一点与我而言几乎是天生的。我几乎是靠自学才成为了程序员。

                  我从不相信电脑,也不相信我刚?#25307;?#22797;的 bug 真的已经修复好了,总之我不相信任何东西。我甚至连自己都不相信。除非多次检验之后,我才会相信我已经如我所愿地理解?#23435;?#39064;。

                  偏执是我的诤友,而且我认为它也应该成为我们每一个工程师的“左膀右臂”。我?#19988;?#20559;执的是,应该总是想着从另一种方式来证实假设,或者从另一个角度去?#27425;頤且?#28431;了什么。虽然很多时候这显得很鸡肋,但是有时候它能发挥至关重要的作用 。

                  2. 不要欺骗电脑

                  换言之就是“避免抽象漏洞?#20445;?#27880;:抽象泄漏是指任何试图减少或隐藏复?#26377;?#30340;抽象,其实并不能完全屏蔽细节,试图被隐藏的复杂细节总是可能会泄漏出来)。系统该怎?#20174;?#23601;怎?#20174;茫?#19981;要别出心裁自?#20174;?#27861;。不要指望会出现什么奇迹。

                  如果系统使用规模超过当前的三倍,那么就?#27599;?#34385;重新设计。

                  电脑?#20146;?#35802;实的孩子,如果你欺骗了它,它绝对会狠狠地反咬一口。

                  3. 简单就好

                  我们?#19981;洞?#24314;一些新事物、解决一些疑?#35328;?#30151;。这也是为什?#27425;?#20204;干这一行的原因。但是很多时候,我们发现某个问题可以解决,却并不意味着现在就是解决它的好时机。

                  我总是觉得自己是个爱自找麻烦的程序员——我?#19981;?#24178;净简单?#23376;?#29702;解的设计。别以为这很容易,相反这是一个难度不小的挑战——以一种复杂的方式解 决问题谁都能办到,但是只有优秀的程序员才能用一种既简单又?#23376;?#29702;解的方式解决问题。特别是要真正直截了当地思考出问题的关键就更是难上加难了。

                  理解是重点,要知道程序员大部分时间是在维护代码,而不是写代码。

                  4. 优化第一戒律就是不要优化

                  这一点来自于 John Bentley 所著的经典书籍《编程珠玑》。(它旨在帮助我们像一个经验丰富的程序员一样思考。虽然已经发行了好多年,但是上面的很多经验教?#31561;?#28982;适用于当今社会。)

                  优化可以采取多?#20013;问劍?#36895;度、后验?#38382;健?#28508;在规模、可能用途,等等。

                  问题在于,大多数的优化最终是没人用的,而且从定义上看,优化或多或少会使得设?#32856;?#21152;复?#21360;?#25152;以,优化的第一戒律就是不要优化,除非你完全理解整个问题。(他的第二戒律依然是:“不要优化?#20445;?#24847;即即使你理解了,但是除非你真的需要才能去优化。)

                  5. 不要仅仅修复 bug;要修复所有可能发生 bug 的地方

                  ?#26434;?#33258;己犯的错误,没必要耿耿于怀。每个人都讨厌出现 bug,我也是。

                  我讨厌会让我?#22797;?#30340;系统。而且我真的非常非常讨厌去修复同样的 bug,所以为了避免这种情况,每当我修复一个 bug 时,我就会思考以下问题:这种 bug 现在还有可能出现在哪里?以后又比较容易出现在什么地方?是什么原因造成了这种模式的 bug?我能不能一下子一网打尽呢?

                  6. 不断地做问题假设

                  因为我大部分时间都是在搞我自己的创业公司,所以我养成了一个不断询?#39318;?#24049;的习惯“为什么要这么做?这能解决什?#27425;?#39064;?有没有更好的方法?有没有什么更重要的?#34385;?#26159;?#19968;?#27809;做到的?”

                  我们应该一直保持这种态度,不断地询?#39318;?#24049;这些假设情况。什么是真正需要解决的问题?是不是只要求解决效果而不必追究根本原因?解决方案完整吗?#23458;?#22791;吗?值得吗?

                  7. . 从长远角度思考。放慢脚步,才能跑得更快

                  这可能?#20146;?#37325;要的一点了。作为工程师,我们享受于高效的工作效率?#21512;不?#19981;断地创建、创建、创建。但是如果我们不能用长远的角度?#27425;?#39064;,只会作茧自缚,使得最后越来越难构建任何东西。

                  有时候,我们还没理解问题就直接去写代码,最后导致不得不放弃。有时候我们的方案虽然对局部问题很有疗效,可却能让?#34385;?#21464;得更糟或造成更严重的 后果。有时候我们匆匆忙忙没有完成设计,从而导致后期别人需要花更多的时间来修复。有时候我们只是懒得用正确的方式写,直接就复制或者借鉴了别人的内容, 原因可能是因为忙着赶项目进度不想花时间去好好思考。……

                  上面这些情况举不胜举。也有人说,这可比我碰到的情况好多了,呵呵。但是?#19968;?#26159;想重复一下——我们的目标是建设最多最强大的功能,拥有最广泛的用户。所以,目光要看得长远。

                  8. 关心自己的代码

                  我想这一点没必要过多解释了吧。不过遗憾的是,现在有很多人时不时地将其抛之脑后。

                  为自己的工作骄傲!关心你自己写的代码!

                  如果我想?#36947;?#25220;近路,我就会告诉自己种瓜得瓜种豆得豆,现在?#36947;?#23558;来可能会面对很多乱七八糟的代码,最后可怜的还?#20146;?#24049;。

                  当然你也不必极端——在谷歌公司我经常开玩笑说其他的工程师对待代码就像对自己的宠物一样,而我和代码之间的关系我更像是一个牧场主——务实,不感情用事。话虽然这样说,但是碰到代码不听使唤的时候,?#19968;?#26159;忍不住会发脾气。

                  9. 成本、速度、正确率

                  这是软件中的铁三角关系,也是全世界软件工程师孜?#25105;?#27714;的目标。但是这不能成为我们裹足不前自满自得的借口。

                  事实上,所谓程序员的优秀和伟大之间的区别往往在于他们驾驭这个铁三角的能力——伟大的程序员通常会想尽办法尽可能地达到这三个目标。我们都应该努力成为伟大的程序员。

                  不过话说回来,鱼与熊掌不可兼得,当我们不得不摒弃这个铁三角的时候,一定要明白我?#19988;?#22949;协什么,为什么而妥协,是否是当前?#38382;?#19979;最正确的选择。

                  10. 最后,保持好奇心,不断地学习

                  好吧,这可能看上去更像是职业建业。但是如果你没有了好奇心,不愿意学习新鲜事物,不再关心新技术、新语言,那么你还干这一行干嘛呢?

                  上述编码原则可能并不完美,各位如有不同意见,欢迎指正,在下洗耳恭听。

                  英文原文: Coding Principles Every Engineer Should Know

                  译文链接:http://www.codeceo.com/article/10-coding-principles.html

                  翻译作者:码农网 – 小峰

           
           
           
           
          时时彩软件下载
          <code id="lcjj3"></code><mark id="lcjj3"></mark>

                  <output id="lcjj3"></output>
                  <code id="lcjj3"></code><mark id="lcjj3"></mark>

                          <output id="lcjj3"></output>