<p>“无我编程”发生在开发阶段，表现为技术团队经常通过同级评审的方式来发现软件中的缺陷。目的是让所有人（包括作者）都参与寻找缺陷，而不是证明软件产品里没有缺陷。人们会交换各自手上的代码，相互进行评审，并且大家都有这样的共识：代码的原始作者会犯错误，而作为评审者，他们会找出这些错误。最后的结果是，每个人都从自己的错误以及别人的错误里有所长进。这就是“无我编程”的由来。</p>    <p>无我编程的十条戒律，最早出现在由 <a href="/misc/goto?guid=4959749822118257373" rel="nofollow,noindex">Gerald Weinberg</a> 于1971年出版的经典著作《 <a href="https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00Z7D9GYG/ref=sr_1_1?ie=UTF8&qid=1496821842&sr=8-1&keywords=%E7%A8%8B%E5%BA%8F%E5%BC%80%E5%8F%91%E5%BF%83%E7%90%86%E5%AD%A6" rel="nofollow,noindex">程序开发心理学</a> 》里。Stack Overflow网站的联合创始人Jeff Atwood在 <a href="/misc/goto?guid=4959749822298421487" rel="nofollow,noindex">博客</a> 上再次列出了这十条戒律。要知道，在这本著作出版的时候，Jeff才一岁。虽然已经过去了几十年，但这些原则并没有被时间侵蚀，仍然值得每一位程序员拜读。</p>    <ol>     <li> <p>接受自己会犯错的事实。关键是要在错误进入到生产环境之前把它们找出来。所幸的是，除了小部分在喷气推进实验室里开发火箭制导系统的程序员，大部分错误都不会造成致命的后果。所以，我们一定能够而且也应该要学会嫣然一笑，然后继续。</p> </li>     <li> <p>不要使用代码来针对个人。要记住，代码评审的目的是为了找出问题，而且总归会找到问题。如果真的找到了问题，请不要把它作为针对个人的借口。</p> </li>     <li> <p>不管你知道多少“秘籍”，总有人比你知道得更多。如果你开口，他们就会教你更多的东西。在你认为没有必要的时候，学会接受他人的建议。</p> </li>     <li> <p>不要不经讨论地重写代码。“修复代码”与“重写代码”是有明显的区别的。了解这些区别，并在代码评审的框架之内进行程式化的变更，而不是单独作战。</p> </li>     <li> <p>尊重比你懂得少的人，并对他们抱以耐心。与技术人员打交道的非技术人员认为技术人员要么是妄自尊大的讨厌鬼，要么是爱撂挑子的倔驴。所以，我们不要用我们的愤怒和不耐烦去加深他们对我们的这种印象。</p> </li>     <li> <p>这个世界唯一不变的就是变化。敞开胸怀，面带微笑地去拥抱变化。把每一个需求变更、平台变更或工具变更都看成是一个新的挑战，而不是令人厌恶的麻烦。</p> </li>     <li> <p>真正的权威来自于知识，而不是职位。知识造就了权威，而权威会迎来尊重。如果你想要在一个无我的环境里得到尊重，那么充实你的知识吧。</p> </li>     <li> <p>坚定你的立场，优雅地接受挑战。要知道，你的想法有时候会遭到反对。你可以证明自己是对的，但不要试图报复，不要总是叫嚷着“我早就说过”，不要把被否定的想法看成是一个牺牲品或者某种战斗口号。</p> </li>     <li> <p>不要成为“小黑屋里的人”。不要躲在小黑屋里写代码，就算偶尔露个面，也只是为了买一杯可乐。躲在小黑屋里只会让你与其他人失去联系，淡出他们的视野，失去控制。在一个开放的协作环境里，你会找不到自己的位置。</p> </li>     <li> <p>批评代码，而不是人。对人好一点，而不是代码。让你所有的评审为代码带来积极的改进，把你的评审与局部标准、程序规范和更好的性能结合在一起。</p> </li>    </ol>    <p> </p>    <p>来自：http://www.infoq.com/cn/news/2017/06/10-Commandments-without-program</p>    <p> </p>