转载

17年编程生涯的三大经验总结：清晰并不总和简洁相关

英文原文： Programming's three life lessons

今年将迎来我编程的第十七个年头。我的编程之旅始于九十年代末，上大学的时候，主要涉足基于表格的网页设计，传统的 ASP，和 Microsoft Access 数据库。原来只是当作业余爱好的编程现在已经成为了我的事业和激情。我一生一半的时间都在学习、蹒跚、成功、失败，并且经常情不自禁地为代码美丽和复杂的天性而折腰。

我在代码上淫浸了足够长的时间，因此看到了很多语言和平台的兴盛和消亡，看到了很多模式被普及，被苛责，然后再次被推广。在某些时候，我常常分不清这是大势所趋还是明日黄花。

编程的流行趋势是短暂的，但我坚守的规则，往往在生活中的其他地方也能发挥作用。事实上，生活就像代码（我已经买了这个域名来证明这一点！）。以下是我总结的 3 个伟大的经验教训，历经一次又一次编程和生活的大浪淘沙。

1. 可商榷的决定往往是一种权衡。

伟大的辩论总是发生在开发社区中。无论它是最近关于 TDD 作为 web 开发的一种可行方法的辩论，还是什么水平的开发人员应该使用 ORM（或 micro-ORMs）。无论是 .NET MVC 应该优于 WebForms 还是以 JavaScript 为中心的 app 应该比基于页面的 app 更受青睐，对我来说，答案都一样：看你权衡之后的取舍？

在任何比较两种流行方法的辩论中，我们总是会从自己的立场出发，两利相权取其重，两害相权取其轻。在我的职业生涯早期，我曾执着于追求所谓的正确答案。感觉过程是线性的：摆脱做事的老办法，转而投向新的并且更好的方法的怀抱。曾经有一段时间我深信，编写自己的 SQL 查询是一种过时的练习，并且 ORMs 是最后赢家。

但是，我了解到，更好的办法应该由内容决定的。例如，今天完全成熟的 ORMs 在隔离映射相关数据网格到对象的冗长管道提供了伟大服务，但隔离也使得某种非标准查询变得困难并且有潜在的效率低下问题。n+1 select problem 就是经典的在少写代码和写更多高效代码之间做权衡。我使用 ORM 的程度完全受我期待应用程序使用的数据量，我所受到的潜在的时间限制，app 长期可扩展性需求这三者的影响。（顺便说一句，我目前是 micro-ORMs，比如说 Dapper 的忠实粉丝，它能让我编写我自己的 SQL 和一些精巧的对象-关系映射）。

我已经将这个经验应用到了我生活的其他方面。我是应该买一套公寓还是长租房子？我是应该启动自己的生意还是工作于已经成立的公司？没有绝对正确的选择。当你权衡利弊了之后，你便可以更好地应对生活中的各种难题。

2. 清晰并不总和简洁相关。

和大多数工程师一样，我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务，那么我为什么要选择要个更多代码的方案呢？通常情况下，更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是，最终的目标不应该是简洁——而应该是可交流。于我而言，下面这段直截了当的代码，在它更长的时候……

 if (HasFarm () && HasBoat ()) {   Broadcast ("You are wealthy!"); } else if (HasFarm () && !HasBoat ()) {   Broadcast ("You are OK!"); } else if (!HasFarm () && HasBoat ()) {   Broadcast ("You are OK!"); } else if (!HasFarm () && !HasBoat ()) {   Broadcast ("You are poor!"); }

……反而比这个简洁版本更明确。

 (HasFarm () && HasBoat ()) ? Broadcast ("You are wealthy!") :  (HasFarm () || HasBoat ()) ? Broadcast ("You are OK!") :  Broadcast ("You are poor!");

虽然这是一个品味问题（有些人可能会觉得后者看上去更加一目了然），但是我在这里要表述的观点是，有时候解释的最伟大方法并不是简化。这个经验也适用于日常生活，我花了大量时间来思考怎么样才能更好地传达消息以便于对方接收——有时更详细的讲解并非没有价值，而是更明确传达信息的必须。

举例来说，我想要更明确和更详细地告诉我爸爸应该如何关闭 iPad（“按住右侧的按钮一段时间……”）。或者，我看似多此一举地键入了一些我已经提交到本地分支的内容给我的同事（“刚刚犯的错误已被修复”），然后当它涉及到部署更新到产品中时，我就能很明确地知道哪些具体的提交被合并和出现（“检查 4812-4822 行，其中包括在6/15 发行版本中的 DoneDone 问题，将在今晚的产品发布中提出来。”）。