成功程序员的基本实用主义 - 第二部分

这是文章的第 2 部分。如果您还没有阅读 第 1 部分，请先阅读。

编写代码

写出优美的代码！

优美的代码是简短、简单、易于理解、模块化、可扩展、可靠和可维护的。

优美的代码很少需要注释，读起来像散文。

开发者喜欢阅读和使用优美的代码。它让他们感觉良好。

编写优美的代码是一门艺术，需要激情、深度投入和多年的实践。

引用

伟大的软件需要对美学的狂热奉献。如果你深入研究好的软件，你会发现那些没有人应该看到的部分也是优美的。

引用

当前开发速度是过去开发质量的函数。

引用

程序应该首先是供人阅读的，其次才是供机器执行的。

引用

因为维护如此重要且昂贵，所以编写程序时，最重要的沟通不是与执行它们的计算机，而是与将来阅读和维护源代码的人类（包括你自己）。

引用

整洁的代码总是看起来像是某个关心的人写的。

引用

我深信宇宙的法则将是优美而简单的。

尽可能使用现有软件！

不要重复造轮子！

在编写新代码之前，请确保您需要的功能尚不存在。

查看现有库和框架（可能用不同语言编写）、工具、其他应用程序和云服务，以找到您需要的内容，或获取灵感并开阔视野。

例如，Unix 提供了许多强大、可靠且灵活的开箱即用工具（在 Windows 上也可用）用于文本处理。如果它们适用，请在您的应用程序中使用它们。

引用

……库代码可能比你自己编写的代码更好，并且可能会随着时间而改进。……库代码比大多数开发人员能够投入到相同功能上的注意力要多得多。

引用

你应研究你的库，并努力不无故重造它们，这样你的代码才能简短易读，你的日子才能愉快而富有成效。

引用

最好的代码是根本没有代码。

引用

如果我比别人看得更远，那是因为我站在巨人的肩膀上。

快速且大声地失败！

尽早发现并修复问题！

这有助于最大限度地减少开发时间和成本，并降低生产模式下故障和损坏的风险。

应自动检测到最大数量的错误。这可以通过智能 IDE、编译器、静态代码分析器、模糊测试器等实现。自动检测到的错误发现成本非常低廉，它们无法进入生产环境并导致故障。

编写良好的单元测试。

在应用程序运行之前未检测到的错误，以及所有类型的运行时问题（例如，文件未找到、无效输入数据等）都应在运行时尽早检测到。

因此，检查所有输入是否为有效值（函数参数、用户输入、资源输入等）。检查所有返回值是否有错误条件。

如果运行时问题无法优雅处理，则应用程序应一致地应用快速失败原则，以适当的方式报告问题（即，提供最大程度的信息以帮助解决问题），然后立即中止。这很重要，因为

• 在开发模式下，它有助于调试，因为一旦出现问题，应用程序就会大声崩溃

• 在生产模式下，它会导致应用程序崩溃，这通常比默默地继续并导致更糟糕的结果（例如错误数据、错误决策等）要好

这是一个由于未应用快速失败原则而导致错误 HTML 代码可能发生的情况示例

Instead of displaying the following life-saving warning …​

Instead of displaying the following life-saving warning …​

关于上述结果的解释（以及更多关于如何快速失败的建议），请阅读软件开发中“快速失败！”原则介绍（提示：只是 HTML 代码中缺少一个>字符）。

最终，快速失败原则有助于在更短的时间内编写更可靠、更安全的代码。

因此，优先选择支持快速失败原则的编程语言、库、框架和工具。

引用

修复你能修复的——但当你必须失败时，要大声且尽快地失败。

引用

如果一个函数被声明在遇到困难时返回错误代码，你就应该检查那个代码，是的，即使这些检查使你的代码大小增加了三倍，并让你的打字手指酸痛，因为如果你认为“这不会发生在我身上”，众神一定会惩罚你的傲慢。

引用

你会在编写新代码之前修复错误吗？

每个软件组件都应该小巧且职责单一。

小巧、职责单一的组件对组件的作者和使用者都有好处。

• 对作者的好处：它们更容易编写、测试和维护。它们出错的可能性更小，并减少了依赖性（耦合）。

• 对用户的好处：它们更容易理解和使用。它们可以以更灵活的方式与其他组件组合。如果需要，更容易用其他实现替换或扩展它们。

整体的力量是许多简单组件无缝协作的结果。

引用

编写由清晰接口连接的简单部件。

让每个程序都做好一件事。

引用

我养成了编写非常小函数的习惯。

不要过度设计！

抵制添加未来可能会使用的功能的诱惑。

每个功能都会增加复杂性以及发生故障的风险。每个功能都需要时间来创建、测试和维护。

此外，通常很难预见将来实际需要的功能，尤其是在需求频繁变化的项目中。添加永远不会使用的功能是毫无意义的。

请记住：保持小巧和简单！

在考虑“我们还能添加什么？”之前，先问自己“我们能删除什么吗？”

引用

当有疑问时，就把它去掉。如果存在 API 设计的基本定理，那就是这个。它同样适用于功能、类、方法和参数。API 的每个方面都应该尽可能小，但不能更小。你总是可以在以后添加东西，但你不能删除它们。

引用

完美不是在没有什么可添加时达到的，而是在没有什么可去除时达到的。

引用

求知，每日有所增；求智，每日有所损。

引用

YAGNI：你不需要它。

只在必要时才优化！

与其编写“运行更快的聪明代码”，不如编写运行足够快的简单、正确和可维护的代码。

方法应该是

• 编写能完成任务的简单代码

• 如果（并且只有如果）存在性能问题，那么

  • 测量性能以可靠地找到瓶颈（不要猜测！）

  • 优化需要更快运行的代码

别忘了：糟糕的性能往往只是糟糕的数据结构、糟糕的代码和/或糟糕的架构的后果。

引用

过早优化是万恶之源。

引用

先让它跑起来，然后让它正确，最后让它变快。

引用

在瓶颈不明的情况下仓促优化，可能是唯一比功能蔓延更能毁坏设计的错误。从扭曲的代码到难以理解的数据布局，痴迷于速度、内存或磁盘使用而牺牲透明度和简单性的结果随处可见。它们滋生了无数错误，耗费了数百万工时——通常，只是为了在某些资源的使用上获得微不足道的收益，而这些资源的成本远低于调试时间。

自动化重复性任务！

一遍又一遍地做同样的事情容易出错、事倍功半、枯燥乏味，并增加了不做重要事情的风险，例如单元/集成测试、备份等。

为频繁任务（如编写/编辑代码、处理文件等）使用你能获得的最佳工具。

力求一键执行，甚至更好的是，自动运行的计划任务。

自动化任务通常很简单。创建小型脚本（用您喜欢的语言编写或使用操作系统脚本），使用自动化工具，如 Autoit、Selenium，或使用任何其他最合适的工具来快速自动化您或您的用户的重复性任务。

引用

使用工具而不是非熟练的帮助来减轻编程任务，即使你不得不绕道构建工具，并且期望在使用完一些工具后将其丢弃。

引用

经济法则：程序员时间昂贵；优先节省程序员时间而非机器时间。

引用

你能一步完成构建吗？

享受心流状态！

维基百科中对心流（心理学）的描述如下

引用

心流……是一种心理操作状态，在此状态下，从事某项活动的人完全沉浸在精力充沛的专注感、全身心投入和对活动过程的享受之中。本质上，心流的特点是完全沉浸于所做的事情中，从而丧失了空间和时间感。

处于心流状态（也称为处于状态中或黑客模式中）可以导致一种幸福感，这种感觉需要亲身体验才能理解。心流可能是一位程序员曾经在论坛中写下“我想编程，编程，编程——直到我死”的原因。

对于程序员来说，心流最好在以下条件下实现：

• 没有任何干扰，例如来电、电子邮件、任何其他类型的通知、噪音等。

• 手头的编程任务是有价值且具有挑战性，但不要太困难。

• 在开始编码之前，你必须看清楚。

“看清楚”是什么意思？闭上眼睛。你能看到整体图景、数据结构及其关系，以及函数及其交互吗？疑虑必须首先消除——通过使用纸笔、上网搜索、寻求帮助、编写小段测试代码，或者做任何其他适当的事情来消除疑虑。

现在你看清楚了吗？那就开始编码并尽情享受吧！

摘要

以下是成功程序员的实用主义总结

通用指南

• 一切都应该尽可能简单，但不能更简单！——阿尔伯特·爱因斯坦

• 如果注定要失败，那就“快速失败！”

• 追求“够好”，而非“完美”。然后发布！

• 倾听用户的声音！

数据设计

• 在编写代码之前，仔细设计您的数据！

• 除非有充分的理由，否则使所有数据结构都不可变！

• 将允许的值集限制为最小可能的值！

• 大多数情况下，默认值应该是允许值集中最严格的。

• 避免数据冗余！

• 考虑使用通用、标准化格式将数据存储在纯文本文件中！

编写代码

• 写出优美的代码！

• 尽可能使用现有软件！

• 快速且大声地失败！

• 每个软件组件都应该小巧且职责单一。

• 不要过度设计！

• 只在必要时才优化！

• 自动化重复性任务！

• 享受心流状态！

历史

• 2018 年 3 月 13 日：初始版本