<blockquote><p>原文：From trivial to complex – 4 software quadrants | Swizec Teller</p><p>原标题：An intro to TSConfig for JavaScript Developers</p><p>作者：Jo Franchetti</p></blockquote><p>多年来我一直试图捕捉复杂软件和繁杂软件之间的区别，我想我终于明白了。我们可以将项目分为 4 个象限！</p><div class="image-package"><img src="https://upload-images.jianshu.io/upload_images/18598558-b15d7b5bbf00e2a9.jpeg" img-data="{"format":"jpeg","size":54186,"width":890,"height":805,"space":"srgb","channels":3,"depth":"uchar","density":72,"chromaSubsampling":"4:2:0","isProgressive":false,"hasProfile":false,"hasAlpha":false}" contenteditable="false" class="uploaded-img" style="min-height:200px;min-width:200px;" width="auto" height="auto"/>
</div><p>在一个轴上，你有难与易建造。在另一个轴上，是解决方案已知与未知。</p><p><strong>琐碎（Trivial）</strong> 的项目易于构建，而且你知道你在构建什么。这些是完美的自由职业项目。想想餐厅的小册子网站，一个独立的数据可视化小部件。任何范围明确、有明确开始和结束的项目，没有未知数。</p><p><strong>挑战性（Challenging）</strong> 的项目易于构建，但你不知道最终结果是什么样的。这些项目最适合内部团队。增长工程是一个很好的例子——你正在推动一个OKR（转化、保留）并尝试不同的事情来优化。每个单独的功能都很容易构建，但你无法提前知道哪些功能会起作用。</p><p><strong>复杂（Complicated）</strong> 的项目很难构建，但你知道最终结果是什么样的。这些都是优秀的机构或内部精干专家团队的项目。默认情况下，他们属于某种平台团队。想想将一个老旧的代码库重构为现代标准，将一个古老的框架升级到新版本，或者在一个没有未知的领域构建一个范围严格的功能。</p><p><strong>繁杂（Complex）</strong> 的项目很难构建，而且你不知道最终结果是什么样的。这些需要一个参与其中的内部团队。在我看来，这是好事。想想整个 SaaS 产品、未知环境中的新功能、使旧代码适应新需求……你需要迭代开发和衡量进度的方法。这些项目的一切都很困难。</p><p>计划可以帮助你将项目从Complicated转移到Complex或Challenging。你可以估计并理解足够小的一部分。这通常是一个“Story”。</p><p>尽量避免同时具有未知数和难以构建的Story。如果你正在深入研究代码库的新领域或集成新的提供者，你应该更倾向于易于构建的功能。如果你正在构建像新算法这样复杂的东西，则更倾向于提前澄清所有未知因素。</p><p>你不能通过前期计划使复杂项目变得琐碎。到了准备好的时候，你可能就已经完成了工作。</p><p>干杯，
~Swizec</p><p>发布于2024年4月16日在软件工程，复杂性</p><p><strong>继续阅读从琐碎到复杂 – 4 个软件象限</strong></p><p>由GPT-4挑选的相关的文章：</p><ol><li><p>Complex vs. complicated</p></li><li><p>You can't fix the wrong abstraction</p></li><li><p>Two types of complexity and their impact</p></li><li><p>Why great engineers hack The Process</p></li><li><p>Forget complicated code, focus on the system</p></li></ol>