您现在的位置：首页
--> 外刊IT评论
“好奇号”火星车上的软件究竟是个什么样的构造？我们已经知道，好奇号上的软件大部分都是用C语言写成的，这些代码加起来大概有250万行。
我最近开发了我的第一个网页游戏：一个HTML5的视频智力游戏。开发的过程很有趣，我喜欢编程，但当实现了游戏逻辑后，我有了一个有趣的想法：为什么不想个办法把代码隐藏起来？
趣图三幅：负载均衡算法需要改进
一个我曾经共事过的很有经验的项目经理曾宣称说，他会拿程序员估计出的时间乘以π值，然后再提高一个数量级，这样得出的才是正确的开发所需要的时间。1天时间经过变换后是3.14周。他经过惨痛的教训才认识到程序员预估的时间都是不靠谱的。为了能更精确的对程序员估计的时间进行换算，我创建了一个时间换算表，重点说明究竟是什么地方出了问题。
难道是盗版用户变成正版用户感到内疚吗？他们不好意思使用“我是个盗版者”的优惠码吗？我不确定，但我很高兴挣到钱了。
我们已经有好几个程序员都把Go语言描述为是一种所见即所得(WYSIWYG)的编程语言。这是说，代码要做的事和它在字面上表达的意思是完全一致的。
如果你是个Linux用户，你可能听说过不需要去对你的linux文件系统进行磁盘碎片整理。也许你注意到了，在Liunx安装发布包里没有磁盘碎片整理的工具。为什么会这样？ 为了理解为什么Linux文件系统不需要磁盘碎片整——而Windows却需要——你需要理解磁盘碎片产生的原理，以及Linux和Windows文件系统它们之间工作原理的不同之处。 什么是磁盘碎片 很多Windows用户，甚至是没有经验的用户，都深信经常对文件系统进行碎片整理会提高计算机的速度。但并不是很多人知道这其中的原委。 简单的说，磁盘驱动器上有很多扇区，每个扇区都能存放一小段数据。文件，特别是大文件的存储需要占用很多不同的扇区。假设现在你有很多个文件存在的文件系统里，每个文件都会被存储在一系列连续的扇区里。后来你更新了其中的一个文件，它的体积变大了。文件系统会尝试把文件新增的部分存放到紧邻原始文件的扇区里。
声明：这篇文章绝不是一篇讨论 NodeJS 和 Ruby on Rails 孰优孰略的檄文。它描述的只是我们做决策过程中的一些思考、决策背后的原因。两种框架都非常优秀，都出色的完成了它们的设计初衷，这也是为什么我们部分的模块仍然运行在NodeJS上的原因。 我是NodeJs的大粉丝，认为这是一项让人非常兴奋的技术，相信它会变的越来越流行。我对这项技术非常的欣赏——尽管我们最近把Targeter App从NodeJS迁移到了Ruby on Rails。 我们当时使用NodeJS开发它的原因很简单。我有一个程序包，能很快的将我们的应用弄上线(我们花了54小时做这个事情)，相比起Ruby，我更常使用的是JavaScript。因为我们的技术架构牵涉到NongoDB，我的这些特长只有在NodeJS环境里才会有意义。然而，随着应用规模的增长，我认识到，选择NodeJS来实现这个应用是个错误的选择。
好的技术人员向往具有很强的企业技术文化氛围的工作场所。但如何你能从外部看清一个企业的技术文化状态？这里要讲的是我使用的两个简单而好用的参考指标。 首先我要讲讲“企业技术文化”这个词指的是什么。它是指技术人员在一个企业内受重视的程度和重要性。它能从一些事情上体现出来： 公司里的决策是如何制定出来的？在一个具有很好的技术文化的公司里，技术人员参与要做什么、何时做、由谁来做等决策制定。并不是说有最终拍板权，而是有真正的发言权。
• 销售员和程序员
一个销售和一个程序员一起去猎捕狗熊。 他们来到森林边的小屋，从车上开始卸东西，搬进小屋，准备接下来这一周在这野外捕熊需要的物品。销售很快就厌烦了这些工作，说： “咱们这么着，你继续卸物品，一切收拾妥当，我去找一只熊来。” 程序员一边叹气一边点头(他习惯了销售的这种行为)，继续收拾东西，而销售很快消失在森林里了。 一个小时后，程序员差不多把四分之三的东西收拾妥当(小屋现在至少干净整洁了)，正当他来到屋外时，突然听到一声咆哮。20米开外，灌木丛开始晃动。销售从里面冲了出来。紧跟在他后面的是一只巨大、咆哮着、流着口水、张牙舞爪的狗熊。它比一般的狗熊打两倍，而其非常非常的愤怒。 销售直奔小屋而来，熊就跟在他屁股后面，程序员迅速躲到了凳子后面，就在他要跑进门时，他突然往旁边一闪。狗熊与他擦肩而过，一头扎进了小屋，销售转身熟练的把门关上，把熊锁到了里面。
我已经在很多演讲里说过，改进你的系统的最好的方法是先避免做“蠢事”。我并不是说你或你开发的东西“蠢”，只是有些决定很容易被人们忽略掉其暗含的牵连，认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。作为一个顾问，像这样的事情我到处都能见到，我还从来没有见过做出这样的决定的人有过好的结果的。 图片，文件，二进制数据 既然数据库支持BLOB类型的数据，把文件塞进BLOB字段里一定没有错了！？错，不是这样的！别的先不提，在很多数据库语言里，处理大字段都不是很容易。 把文件存放在数据库里有很多问题： 对数据库的读/写的速度永远都赶不上文件系统处理的速度 数据库备份变的巨大，越来越耗时间 对文件的访问需要穿越你的应用层和数据库层 这后两个是真正的杀手。把图片缩略图存到数据库里？很好，那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。
有时候，会有程序员跑到我这里说他们不喜欢某个东西的设计，“我们需要给它来个全面的重构”，来纠正里面的错误。哦，哦。这听起来可不是个好主意。而且这听起来也不是重构… 重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义，它是 一种修改，使软件的内部结构更容易理解，在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节制的整理代码、使bug产生几率最小化的方法。 重构的结果是引用了快捷方法、去除了重复代码和死代码，使设计和逻辑更加清晰。是在更好的、更聪明的使用编程语言。是在优势利用你现在知道、但当时的开发程序员并不知道——或并没有加以利用的信息。不断的简化代码，让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。
“这个网站相当简单，所有你需要做的就是完成X，Y，Z。你看起来应该是技术很好，所以，我相信，你不需要花费太多时间就能把它搭建起来。” 我时不时的就会收到这样的Email。写这些邮件的人几乎都是跟技术不沾边的人，或正在研究他们的第一个产品。起初，当听到人们这样的话，我总是十分的恼怒。他们在跟谁辩论软件开发所需要的时间？但后来我意识到，即使我自己对自己的项目预测要花去多少开发时间,我也是一筹莫展。如果连我自己都做不好，我何必对那些人恼怒呢？ 真正让我郁闷的不是他们预估的错误。问题在于他们竟然认为自己可以做出正确的估计。作为开发人员，我们经常会发现，在软件开发的问题上，一个外行人会很自然的把复杂的事情估计的很简单。 这并不是为我们的愤怒找借口。但这引起了另外一个有趣的问题：为什么我们天生的预测复杂性的能力在遇到编程问题时会失灵？ 为了回答这个问题，让我们来认识一下我们的大脑如何估计事情的。
Java的闭包(Closure)特征最近成为了一个热门话题。一些精英正在起草一份议案，要在Java将来的版本中加入闭包特征。然而，提议中的闭包语法以及语言上的这种扩充受到了众多Java程序员的猛烈抨击。 不久前，出版过数十本编程书籍的大作家Elliotte Rusty Harold发表了对Java中闭包的价值的质疑。尤其是他问道“ for 循环为何可恨？”： 我不知道，有些人这么着急的要把 for 循环消灭掉，他们反对的究竟是什么？这已经不是第一次或第二次计算机学界的理论家们起来反对 for 循环(或类似的东西)了。 如果只说Elliotte质疑不起眼的闭包的价值，这是不公平的。
有人问：你做过的最有效的提高你的编程水平的一件事情是什么? 回首作为一个程序员这些年来的生活和职业道路，我使用了很多种不同的方法来提高我的编程技能 —— 阅读代码，编写程序，阅读书籍，听讲座，看视频，等等。 我的问题是：你做过的最有效的提高你的编程水平的一件事情是什么?对于那些想提高水平的程序员，你的建议是什么？ 我希望你们提供的答案是各种各样的，并且不是那种“放之四海而皆准”的答案 —— 我希望得到适用于不同人的不同的答案。 有很多人给出了自己的答案，在这里，我将其中最受认可的前三种答案选出来翻译给大家。 最受欢迎的回答：学无止境 没有特别的先后次序… 和比自己更聪明的人一起工作 永远乐意听取他人的意见，不管对方是低级水平，一般水平，资深，还是大师。职称头衔并不代表一切。
尽管我们也许永远无法知晓为什么在某次面试中没被选中，但最近的一项研究给我们在理解招聘者的决策行为规律上带来了一些启示。根据TheLadders的研究发现，招聘者在初步决定候选人‘是否合适’之前所花费的平均时间是6秒钟。 研究中对30位专业招聘人员使用了一种叫做“眼球追踪(eye tracking)”的技术，监视他们在10周时间眼球的运动轨迹，以此“记录和分析他们在理解消化一段信息或完成一个任务时，他们视线的焦点和持续的时间。” 研究显示，在快速浏览你的简历的短暂时间里，招聘者会看你的姓名，当前的职称和所在公司，当前职位的开始日期和结束日期，之前的职称和公司，之前的职位的开始日期和结束日期，以及学历。
最近的几个月，我一直在学习一种叫Haskell的编程语言。由于里面有太多的从未遇到的编程概念，整个过程就像是完全重新学习如何编程。在i.TV网站上，我写了很多JavaScript(node.js和前端代码)。虽然有不少的函数式/haskell式的编程模式不能引用进来，但仍有大量的技术思想让我在使用javascript编程语言时受益不少。 你会发现Haskell库里有能够处理各种事情的各种各样的函数。起初我以为这些只是一种技术上的积累，但随后我认识到，这些函数相比起其它语言里的函数，它们能应用到形式更广泛的问题中。这使得它们更有价值，因为我们都不太喜欢对一些常见的问题还不得不自己去写解决方案。 这些函数是可以相互组合1的：它们能针对性的解决某些问题，而不对你的代码做任何依赖，所以，你可以拼装它们，组合成一个能够解决你的大问题的东西。
马克·吐温曾经说过，所谓经典小说，就是指很多人希望读过，但很少人真正花时间去读的小说。这种说法同样适用于“经典”的计算机书籍。 在Stack Overflow(以及其它很多软件论坛)上，诸如”程序员最应该读的计算机书籍有哪些?“这样的问题会周期性的出现。这样的问题不断的被提出、被回答，只是形式不同罢了。相同的几本书总是会出现在清单的前几名内，所以，如果想知道人们谈论的都是些什么，你有必要去读一读这些书的。
• 内疚的程序员
我发现，当程序员开发了一个项目，然后要把它移交给其他程序员时，他们会对开发这个项目时做出的一些决策感到内疚。我问他们当时为什么选择这样做，他们会羞愧的说，“唉，我知道这不是最好的实现方法，如果现在再去做，肯定不会采用那样的方式。”有些人可能会辩护，或强调一下外部因素，比如工期压力。但我的观点是，程序员不需要为老的项目感到太多的内疚。 经验 我承认，我曾经有一次重新发球的经验。那是一个作为内部工具使用的Ruby on Rails项目。我之前对这种技术架构了解不多。基本上就是把东西按照需求拼凑起来，它运行很正常。没有多少测试，设计上必然是没有体现出最好的设计原则。但它能用。
技术债务，是指匆忙的实现一个功能，却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计)，这对于一些项目经理/客户来说就像是天书奇谈。也许他们是明白的，只是不愿意承认罢了，我估计是这样的。不管怎样，我想起来一个小故事，当下次遇到这种情况，需要向他们解释增加某些新功能的代价时，也可用讲这个故事给他们听。 一个农夫有3只母鸡。每只母鸡每天下一个蛋。农夫跟当地的一个食品店老板做生意。食品店老板每天从农夫那里买2给鸡蛋放在店里出售。
近3天十大热文
-
[16] Go Reflect 性能 -
[15] 浏览器的工作原理：新式网络浏览器幕后揭秘
-
[14] iTerm2 (Mac Terminal)
-
[13] 界面设计速成
-
[13] iOS可视化编程 Tips 之“无需代码设置
-
[13] iOS下自己动手造无限循环图片轮播
-
[12] Spark性能优化——和shuffle搏斗
-
[12] iOS并发编程（Concurrency Pr
-
[11] 浅谈Web安全验证码
-
[11] 内网穿透神器frp
赞助商广告
