译注：开发人员如何从无休止的需求、项目进度中摆脱烦躁的心态，这是每个人都值得思考的话题。无意间看见了 这篇文章 ，恐于太长遂将其精简翻译，错误之处难免欢迎指正。

同时如果你有有关程序员修身养性的观点和心得，欢迎说说你的看法。

-- Split --

其实每个程序员或多或少都会有个毛病，就是具有某种有强烈的「优越感」。而这种「优越感」 有可能成为激励自身不断发展的动力，同时也有可能成为其职场中的绊脚石。

程序员的这种心态，源自自身掌握的技术、以及多年积累的经验。正如上面所言，这种心态 能使其一切都力求完美、同时准确按照自己的思路行事，能使其技术不断的提升。而另一方 面，如果将这种态度套用给身边其他的人（包括陌生人、同事、朋友甚至家庭），则会发现 他的生活将会如履薄冰 -- 他们只会看见完美的一面而忽略了更多更需要关注的事物。

总而言之，越早发现并解决这一问题，越对自身有利。套用 GeraldWeinberg 在 《计算机编程心理学》 中的一段话

这种想法是程序员必须解决的，他们对待自己的代码犹如对待自己身体的
一部分，因此他们拒绝所有的负面评价。相反，它们（指代这种心态）应
该及时的引导到正途，使其发挥真正的效用。人非圣贤，这不仅仅是心态
更是精神上的境界，并非所有人都能达到，但仍旧值得去尝试。

症状

那么，你如何得知这种「优越感」正在伤害到自己？除了应付那些没完没了的催促项目进度的 电话，以及给同事擦屁股的优化工程，其它的现象并非显而易见。

其实就我个人而言，时常也会自我责备，这就能窥出事态的严重。例如一方面你对项目疲于 奔命，而同时却忽略身边的人对你表达的看法（该死，这个时候我应该放下手头的工作听他 们说完的）。或者你「假装」静下心来听取他们的意见，但不就繁杂的工作却让你左耳进右耳 出。

其他的些症状

• 如上面所说的，不会妥善处理批评
• 不放心同伴的代码，经常性地对他们进行代码审查（Review）
• 报复性的编写大量充斥着错误的代码
• 个人的消极心态，对自身和团队造成不利的影响
• 必须要求进行测试，但出发点却是炫耀
• 对事物的看法仅仅局限于个人或者本职位的角度

这不仅仅是你个人的事情，编程以及项目开发实际上是团队活动。了解到这些，你将会意识到 你的心态将会直接影响到你的同事。

事实就是这样，当我对您的代码提出写意见甚至批评时，你应该听、并且认
真的听，这样你才能理解我的看法。

有可能最糟糕的情况就是，即便早已经收到其他同事的提醒，当事人已经陷入此泥潭无法自拔。

准则

让我们回到文章的题目本身，正如上面的例子中看到，「谦逊编程」不是编程技术本身，而是 种态度，但它的确会比你掌握的某种技术要有用的得多。

行为准则的确能改变人的心态，下面是些不成文的建议，或许你可以尝试下

• 不要草率的宣布你的决定，在大多数情况下，你应该和你们的同事们讨论
• 不要使用这些论调，这非常让人感到不适：「这是见过的最糟糕的代码了」，换之你可以这样说，「我有个更好的解决方案，要不看看？」
• 不要轻易认为他们没有考虑到你想的方式，即便很不幸是这样，应该善意的提醒。例如「你觉得我这个看法怎么样...」
• 不要无理由的批评你认为很弱智的现象，例如「我觉得 DBA 脑门子被夹了，这个字段竟然使用 INT 型」

更多的，可以参考 Tech Republic 中的 「谦逊编程」十条诫律 ：

• 理解和接受你将犯下的「错误」。

重点是及早的发现你已经犯下的错误，当代码投入使用以后，改动起来就会非常的困难。

• 你的代码不能代表你的人。

记住始终要 Review 你的代码，即便你已经认为无懈可击，经验证明总能发现些错误。

• 不管怎么样，有些「奇技淫巧」总能派上用场，而可能这些技巧别人知道的比你更多。

如果你坚持不耻下问，你的同伴总能分享你更多。

• 不要在完全没有沟通的情况下，自作多情的进行代码重构。

当你确定要更改别人的代码时，必须加上良好的修改记录，这也是出于对他人的种尊重。

• 对待那些新手要保持充分的尊重、细心以及耐心。

记住当他们成长起来后，能帮你解决的问题会比你想象中的还要多。

• 唯一不变的是变化。

怀着开放的心态对待变化，对于各种需求、平台甚至开发工具的变更，应该是迅速适应而不是牢骚满腹 -- 这样解决不了问题。

• 真正的权威来自学识，而不是立场。

权威源自学识、尊重源自权威。

• 优雅的接受失败。

最终你的一些观点将会被推翻，即便你有能力证明你的观点是正确的，请不要重复的争辩。帮助其他人意识到这点的最好工具，就是你的理解以及时间。

• 不要成为「办公室男」。

不要在昏暗的办公室里独自喝着可乐敲着代码。当与外界隔绝，离开同伴的视线，也就说明你离开了一个开放、合作的环境。

• 批判代码而不是编写它的人。

要知道你的意见可以影响到代码也可以影响到其人，如果你想尝试下如何打击别人的自信并造成冲突，那么尝试下吧。

观察了好久，终于下决心出手了，本来想买款单反相机，但发现其实长焦相机更适合我。

冒着杭州将近 40 多度的高温，到文三路将 其 取了回来，卖家很抠不送 UV 镜头和三脚架，所以这些就另外配了，总价 2500 上下，这也符合我的预算。

相机的属性还不是很熟悉，放几张样片让大家评论下吧

不管怎么样，现在至少外出有个偷拍利器了，啥时候可以约上 ppeng 等人去西湖扫街了。

PHP5.3 的 goto 语句

PHP5.3 的正式发布 ，又重新关注起其语言本身。细心的朋友可能发现，PHP5.3 增加了 goto 语句，这在结构化语言今天似乎是有点不可思议的事情。

按照官方的说法 ，其实这和我们传统理解的 goto 还是有所差别。PHP 5.3 中的 goto 语句只能在脚本文件以及上下文中跳转，因此它无法从某函数或方法跳到其他的函数或者方法 -- 这不得不让我怀疑是否是「妥协」的结果。

看来 PHP 语言的设计者对 goto 语句应用是方便从从多重循环体中跳出（在其文档中的例子也说明了这点）。但其实这功能的本身也引发了不少的争议，个人也隐约的闻到了潘多拉身上的香水味。

其实「好事者」 早在 2007 年就开始「期待」这项「新功能」 ，相信他现在会很开心。不过有趣的是这篇文章的留言给原作者泼了盆冷水。的确，goto 语句所能完成的功能，其实善用 switch 也能做到，而且更有可读性。

不过不管怎么样，语言本身仅仅是工具而已。从程序的本身角度考虑（不仅仅是 PHP），如果有过多的循环等的语块嵌套，那就说明这段代码必须需要优化了。到底应不应该使用 goto 语句，其实本人和其他的 PHP 人员也有过讨论。

最终，大家较为统一的观点就是，避免使用。

「PHP 的 10 宗罪」

老外较起真来真的非常让人受不了， 这不又有好事者总结了 PHP 语言本身语法的 「10 宗罪」 。其实，我个人这与其称为「Mistake」，还说是 PHP 提供的「美丽的陷阱」。

例如，文中提到的有关单引号和双引号的变量转义问题。其实这一争论的声音从学 PHP 起就在耳畔充斥。甚至记得当年还有道经典的面试题，就是考单引号和双引号的的速度孰快 -- 回过头来看，这论点就犹如此道面试题一样，是没有任何的意义的。

但这不代表文中的些「Mistake」都可以当作笑谈，有些是的确需要注意的。例如

$i = 0;
while($i < 20); {
    //some code here
    $i++;
}

这样的写法。对应的其实还有 for 语句，我们可能「手残」多写了个分号（不要不承认），那么就只能祈祷 set_time_limit 的数字小些了 :^)

文中指出的其他些问题，也是我们需要纳入思考的范围中，例如数据库存取的缓存问题。为何 PHP 为何至今没有数据池这样的概念，其实这需要从 PHP 这门语言本身的设计哲学出发了。从此问题其实可以引申争为何 PHP 没有走向 Java 的套路，好吧这问题又可以争论一番了。

文中还有其他类似的条目，都非常的具有争议（也许搞不好这就是作者的初衷），但无论怎么说，其提出的几个问题都是值得我们去思考的。

深夜杂谈随想，乱语之处众位见笑了，欢迎发表您的看法。