如何针对软件开发的变化进行优化

luly靓

想象一下，您在Magic Money Corp工作，该公司仅使用三行JavaScript：
现在想象一下doStuff出了点问题，您需要将其取下来进行维护。如果您暂时将第二行注释掉，会发生什么？


为了解决这个问题，您现在必须通读doStuff的整个源代码以了解它的作用，并替换关键代码以发挥作用。听起来需要做很多工作……也许我们应该离开并编写解决方法？
现在，让我们想象一下，如果您不是在不可变数据结构上构建了Magic Money Corp（或使用了功能语言）
自从两年Dan Abramov撰写有关优化的概念以来，我就一直为之着迷。它清楚地阐明了React的核心设计原理（其余内容在这里和此处）。对我而言，这是将使React失效原因之一，而我现在尝试将其应用于其他任何地方。
但是，它没有回答的主要问题是您如何精确地进行更改？
如何优化变更
计划共同变更
使用简单值
最小化编辑距离
尽早发现错误
为什么要为更新而优化
首先，对这个想法进行必要的解释：
难以删除的代码会随时间驱逐出易于删除的代码
因此，我们必须尝试从最早的设计中进行更改以进行优化
这个想法的灵感来自“易于替换的系统趋于被难以替换的系统取代”（Malte Ubl）和“编写易于删除而不易于扩展的代码”（tef）。
并不是说我们不知道何时很难更换系统。最方便的应对方法通常是采取解决方法，然后继续前进。
我们必须允许更改的原因是需求波动性是软件工程的核心问题。
我们的开发人员常常幻想如果产品规格预先完全指定，我们的生活会容易得多。
实际上，唯一不变的是变化。考虑到这一事实，我们应该仔细设计我们的抽象和API。


如何计划共同的变化
一旦您意识到需要进行优化以进行更改，就很容易过度投入并被分析瘫痪所克服。当一切都可能改变时，您如何设计东西？
例如，您可以通过在每个接口上放置抽象外观或使每个函数异步来实现此目的。显然，将代码库的大小加倍以换取功能集上的任何差异也是不希望的。
划清界线的一种合理方法是针对小的，常见的调整进行设计，而不用担心大的，不频繁的迁移。 Hillel Wayne称这些需求为摄动-小型，典型的功能需求不应使您的整个设计毫无疑问。
对于概率上的倾斜，我们能做得最好的事情就是确保我们的设计能够很好地适应1-3个“标准偏差”的变化。更大的变化是罕见的（根据定义），并且在发生变化时证明进行更具侵入性的重写是合理的。
这样，我们还避免针对可能永远不会发生的变更进行优化，因为变更可能是导致软件复杂的重要原因。
常见的变化可以通过经验积累的例子是Zawinski定律，但是无论是通过先发制人的多元化还是业务战略，完全完全是常规且可以预见的极端变化要少得多。
使用简单值
一旦我们限制了想直接投入有关API设计的思考。最终目标很明确。为了使代码易于更改：
首先必须容易删除
这样就可以更轻松地剪切和粘贴
这使得创建和分解抽象变得更加容易


直到您涵盖所有常规维护任务，包括日志记录，调试，测试和性能优化。
Rich Hickey以传扬“价值观的价值”和“朴素”而闻名。值得深入了解此方法对API设计的影响。
您可以在其中传递类实例或对象的地方进行动态引用，您可以改为传递简单的，不变的值。这样就消除了一整类潜在的错误（并解锁了日志记录，序列化和其他功能）。
从简单的简单值得这些要求中，您可以从基本原理中得出令人惊讶的“最佳”实践数量-不可变的编程，使用功能性核心约束状态，命令，无法解析的解析以及管理功能。
追求简单是从结构共享到静态分析的各种技术都可以提供帮助。
更好的方法是记住所有这些都是同一条通用规则的实例，而不是记住一个好/坏例子：复杂性是由耦合引起的。
最小化编辑距离
每当我想到复杂性时，我都会从脑海中想象一下“简单制造”中的例子。
执行顺序—如果我删除第2行中的内容，开发人员如何轻松判断第3行中的内容是否会爆炸？我需要进行多少更改才能修复它？
解决顺序-如果并发流程无法正常解决，我如何容易地纠正或保证出现竞争状况？
文件系统顺序-如果我将某些代码从一个地方移到另一个地方，还需要编辑多少个其他文件来体现这一点？


参数顺序—如果我交换某些参数的位置，无论是在函数调用中，在类构造函数中还是在YAML配置文件中，程序是否会内爆？
这是一个临时列表；我可能在这里找不到一些大的东西，请让我知道。
您甚至可以使用“编辑距离”的概念来量化这种复杂性：
如果使用多函数功能，那么在不更新所有调用站点或添加我实际上不想要的默认参数的情况下，我无法轻松添加或删除或重新排列参数。具有命名参数的单个arity函数/语言仅需要基本更新，而无需更多更新。 （当然，这并非没有取舍，这里有更多讨论。）
使用React（pre-Hooks）将无状态组件设为有状态，这需要对7行代码进行编辑/添加。使用React Hooks只需1行代码。
异步和数据依赖倾向于在代码库中传播。如果一个需求发生了变化，并且底层需要进行异步处理（例如，它需要进行一次数据提取），那么我曾经不得不在至少3个文件和文件夹之间进行切换，并使用Redux添加reducer，action和选择器来协调这一工作。更好地分解关系-React Suspense，Relay Compiler和GraphQL的数据加载器中突出的设计目标。
您甚至可以想象出类似于CSS特异性公式的复杂性度量– C（1,0,0,0）的复杂度比C（0,2,3,4）难以更改。因此，针对变化进行优化将意味着减少常见操作的“编辑距离”复杂度。
我还没有完全弄清楚公式的含义，但是当代码库难以更改时，我们可以感觉到它。结果，发展进度变慢。
但这只是可见的效果-因为在代码库中进行实验并不有趣，所以从未找到新颖的想法。错过创新所付出的无形代价与尝试尝试或改变主意的难易程度直接相关。


为了使代码易于更改，使“编”代码成为不可能。
尽早发现错误
尽管我们可以尝试通过API设计和代码样式来遏制意外的代码复杂性，但是除了最琐碎的程序之外，我们永远无法完全消除它。
对于剩下的基本复杂性，我们必须使反馈循环尽可能短。
发现发现错误的时间越早，修复错误的成本就越高，因此创造了“向左移动”一词。
如果将软件开发生命周期从左（设计）安排到右（生产），则想法是，如果将错误“向左”转移，则可以通过更早地捕获错误来节省实际成本。
由语言服务器或编辑器插件提供的“实时”值或重播记录
因果关系可以是双向的。如果您更轻松地进行更改，则可以更频繁地进行更改。
但是它也可以以其他方式起作用-因为您希望进行频繁的更改，所以您更有动力使事情易于更改。
一个极端的例子不仅涉及代码，还涉及社区。 库（或语言）在第一个版本上保留的时间越长，切换到第二个版本的难度就越大。而定期发布破坏性版本（以换取明显的改进）的生态系统似乎避免了暴露漏洞的可能。

jimmy肖明

看来楼下的有话说!

123456823

不错，顶一个！

飘渺九月

在撸一遍。。。

贰十岁装成熟装s

明明白白我的心，楼主赏我个沙发！