David Heinemeier Hansson 采访
简介
David Heinemeier Hansson 是 Ruby on Rails 的创始人，Basecamp 的联合创始人兼首席技术官，畅销书作家，勒芒级冠军赛车手，顾家好男人，播客常客，以及励志演说家。
Ruby on Rails 由 David 于 2003 年创建。 自 Evrone 于 2008 年成立起，我们每天都在使用 Rails 开源 Web 框架。 它已经帮助我们为成千上万个项目编写了非常漂亮的代码。 除了创建软件开发领域最有用的工具之一外，David 还完成了许多其他壮举，包括撰写“It Doesn't Have To Be Crazy At Work”、“REWORK”和“REMOTE: Office Not Required”等书籍，以及参加国际汽联世界耐力锦标赛。 2014 年，他在勒芒 24 小时耐力赛的第 82 届比赛中获得了所在级别的第一名，这是世界最负盛名的跑车耐力赛。 同一年，他还获得了世界耐力锦标赛 GTE 业余组冠军。
2020 年，我们邀请了 David 在 RubyRussia（Evrone 的第 11 届莫斯科编程年会）上发言。 在活动之前，我们有机会与 David 谈论了软件开发的世界以及他编写现象级代码的方法。
采访
Evrone: 嗨，David，很高兴能在今天采访你。 那就开始吧。 对于普通开发人员来说，如何决定他们是需要从“低级的 JavaScript”方法开始，并在之后发展他们的应用，还是需要从一开始就使用 Angular、React 或 Vue？ 你会建议采取什么样的决策策略？
David: 如果你构建的内容的外观或风格类似 Vanilla Web 应用（例如 Basecamp、GitHub、Shopify 等），那么我认为最低限度地使用 JS 是最佳选择。 不是没有 JS，只是极少。 如果您要构建高度互动的内容（例如游戏或照片编辑应用），或者涉及单屏多状态的种类，那么研究完整的单页应用是有意义的。
Evrone: 随着代码库和团队规模的扩大，你会建议将典型 Rails 应用的哪些部分转为微服务？ 假设企业需要一个良好的代码开发组织结构，又不想重新编写整个产品。
David: 这是一种妄想，如果你第一次编写的软件不够好，把事情搞得一团糟，那么第二次也不会变得更好。 你必须学习新的习惯，然后把它们应用到生活中。 Sarah Mei 在 RailsConf 2018 上针对这一主题发表了精彩的演讲。 她谈到代码库已经不再是我们构建的东西， 而是我们生活的地方，而我们的目标是让它适合自己和所有生活在那里的人。 当我们编写代码的时候，我们的目标不是把代码写完就完事了，我们的目标是让它可持续发展，让它适合居住在其中的团队的生活。
你可以随便重写，但是如果你不改变造成代码混乱的个别习惯，最终只会获得一个乱成一团的微服务网络，就像在单体应用中乱糟糟的类定义一样。 你的代码实际上就是一个住着人的室内空间。 软件最重要部分是系统。 代码和编写代码的人是一个整体，它们是不可分割的。 我们越能把软件看作是一个代码和人相互连接的系统，我们就越有可能取得突破。 就越接近变革，越接近范式的转变。 而对我们来说最重要的也许是，就越可能构建出我们自己喜爱的代码库。
Evrone: 哇哦，真是让人大开眼界，我们完全同意！ 在选择猴子补丁和其他代码组成模式之间进行选择时，你会推荐哪种方式？ 为了不把自由补丁变成一堆相互冲突的重写，我们应该考虑什么？
David: 自由补丁是用来创建通用的语言方言的。 Active Support 库充满了自由补丁。 它不是用于创建特定于应用的更改。
Evrone: 你肯定见过很多 Ruby 代码。 在你个人看来，什么是好代码，什么是烂代码？ 有什么是你一眼就能看出来的吗？
David: 如果代码写得不好，通常在你检查逻辑之前就能嗅出味道。 缩进不对，风格混杂，根本不上心。 除此之外，学习如何编写出色的代码是一生的追求。 正如我在 2014 年 RailsConf 主题演讲中所说，我们不是软件工程师，我们是软件作者。 对于我们大部分时间所做的工作来说，“写作”是一个比“工程”更合适的比喻。 写作讲究的是清晰明了，把信息以清晰易懂的方式呈现出来，让任何人都能理解。
不存在某个关于原则和做法的清单，可以教给其他人怎么做，然后他们每次就能自动产出清晰的代码。 如果你想成为一名优秀的作家，仅仅背诵字典是不够的。 仅仅知道可以使用的单词，知道开发模式，并不能让你成为一名优秀的开发人员。 你必须培养洞察力。 你必须明确系统最重要的是清晰度。 当你这样决定时，就可以开始培养洞察力了。
按照定义，我将优秀程序员定义为能够清晰地编写软件的人。成为一名优秀程序员的唯一途径是阅读并编写大量软件。
Evrone: 的确如此。 要知道，通常情况下，经营公司的非程序员很难理解“技术债”、“架构”的概念，并会通过多次重写同一个应用来获得更好的代码。 作为程序员和商人，你会建议如何使没有编程背景的商人接受这些想法？
David: 在任何情况下，我都不赞成因为技术原因而重写应用。 Sarah Mei 的主题演讲把原因说得很清楚了。 但是当你想让应用实现不同功能时，我会建议重写。 我在美国软件商务大会的演讲中谈了许多这方面的内容。
我们一直在重写 Basecamp 的代码，不是一次，甚至不是两次，推出 Basecamp 的新版本。 当然，和客户相熟是很好的事情。 这有很多好处，同时，也有很多坏处。 你必须进行某种形式的更新，因为事情停止了发展，在某一时点，你只有一个非常老的客户群，和一个严重萎缩的新客户群，就像“一个水桶”。 客户一旦离开他们的工作，他们就会离开你的软件。
问题是，如果你不倒入新的水，最终水桶里就没有水了。 你必须趁着情况比较好的时候做出改变，而这也是最难改变的时候。
没有人会永远对实行和 15 年前完全相同的想法感兴趣。 那样是行不通的。 但是，如果你持续更新它，持续让你最好的构想以其最纯粹的形式有一个出口，你就可以拥有一片绿地，可以在上面建造漂亮的小房子，一切都会非常美好。 所以请重写你的软件。
Evrone: 接下来是我们标志性的“时空旅行”问题！ 如果你有机会回到过去，回到你在 Basecamp 孕育 Rails 的时候，你会给年轻的自己一个什么技术建议？
David: 那时的我不会希望知道任何事。 无知是福。
我们很高兴请到 David 在 2020 年 RubyRussia 大会上发言。 我们 Evrone 团队也期待 Basecamp 能够不断发展，当然还有 Ruby on Rails。 框架越强大，我们就越能为客户和合作伙伴打造更好的解决方案。 如果您有一个项目构思，并且对使用 Ruby on Rails 感兴趣，那么我们的开发人员很乐意与您讨论各种可能性。 无论您现在处于项目开发的哪个阶段，敬请留下您的联系信息，我们会尽快与你联系，看看我们能够为实现您的目标提供哪些帮助。