YAGNI在应用程序开发中：它是什么、原则的实质和实际益处

什么是YAGNI？

YAGNI（You Aren't Gonna Need It）——极限编程（XP）的原则，意思是"你不需要它"。规则是：永远不要实现当前用户故事不需要的功能。如果某个功能今天不需要——就不要实现它，即使是"以防万一"。

这个术语由Ron Jeffries引入，他是XP方法论的共同作者之一（与Kent Beck一起）。Jeffries曾说："实现最简单可行的方法，在需要之前不要添加任何东西。"YAGNI——不是禁止规划，而是禁止过早实现。

根据Standish Group CHAOS Report（2023）的数据，平均软件产品中64%的功能很少或从未被使用。如果换算到移动应用程序——超过一半编写的代码没有给用户带来价值。YAGNI阻止了这种资源浪费。

将YAGNI作为严格的过滤器应用：每个功能必须回答"它当前解决了哪个具体用户的问题？"如果没有答案——该功能就不需要。

YAGNI与懒惰和走捷径的区别

YAGNI——不是拒绝高质量的架构。YAGNI禁止编写多余的代码，但不禁止编写正确的代码。如果当前功能需要一个清晰的抽象层——就创建它。如果不需要这一层——就不要创建。关键区别：YAGNI关注的是功能，而不是质量。

开发人员经常将YAGNI与故意积累技术债务混淆（技术债务总是妥协，YAGNI是效率原则）。区别在于，技术债务是已知且有文档记录的，而违反YAGNI只是额外的工作。

问问自己："如果我现在不做这个抽象，当需要时重构需要多长时间？"如果重构时间少于现在编写的时间——就推迟。

为什么YAGNI对移动项目至关重要？

移动开发对违反YAGNI特别敏感，原因有三：APK/IPA大小直接影响安装转化率，移动项目的编译时间随代码量线性增长，每个额外功能都会增加故障点。YAGNI——不是关于懒惰，而是关于专注。

Google Play Console Data（2023）的研究表明：APK大小每增加10MB，安装概率降低1.2%。未使用的代码不仅仅是仓库中的垃圾，它是直接的经济损失。多余的库（用于"可能以后会添加"的功能）是APK膨胀的最常见来源。

根据Gradle Build Performance Report（2024），Android项目中每增加一个模块，完整构建时间增加3-7秒。如果添加5个"面向未来"的模块——每次构建的编译时间增加15-35秒。一年下来，一个5人开发团队要花费多达200人时等待编译。

在CI中监控二进制文件大小：设置警告阈值（例如，每次提交+500KB）。如果大小在没有新功能的情况下增长——这是违反YAGNI，需要在code review中讨论。

YAGNI与过度设计的对比：实际案例

过度设计：过早的动画

过度设计——为了"改进"产品而添加超出需求的额外功能。典型例子：开发人员添加复杂的屏幕过渡动画，尽管设计只指定了简单的淡入淡出。动画花费2天时间，用户没有注意到，而不同设备上的错误困扰项目多年。

根据UX Collective Annual Report（2023），78%的用户根据速度和稳定性评估应用程序，而不是动画。YAGNI说：如果动画没有在需求中指定——就不要实现。设计师会在真正需要解决UX问题时添加动画。

只实现线框图中的内容。如果设计师没有画出动画——就意味着不应该有动画。任何偏离线框图的行为都是违反YAGNI。

过早地本地化为20种语言

创业公司的常见错误：立即计划支持20多种语言"以备未来进入国际市场"。YAGNI建议：只本地化当前市场的语言。每增加一种新语言都需要翻译人员的时间、字符串截断测试和RTL布局调试。

Deloitte Digital Globalization Survey（2022）的研究表明：60%的移动应用程序从未超出第一个市场。如果这是你的情况——多语言资源就被浪费了。YAGNI方法：英语（基础）+目标市场语言。其余的——根据实际进入该地区的情况而定。

使用YAGNI进行优先级排序：如果某个功能不在未来两个季度的路线图中——就不要开始。路线图必须由产品经理以文档形式批准。

如何在Android和iOS中应用YAGNI？

Android中的YAGNI：不要添加多余的库

Android项目饱受库膨胀之苦。开发人员在编写第一行业务逻辑之前就添加了Retrofit、OkHttp、Gson、Room、Dagger Hilt、Navigation Component、DataStore。YAGNI建议：根据实际需要添加库，而不是预防性地添加。

// 违反YAGNI：预防性添加库
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// 应用程序目前只显示“Hello World”

库是具有自身复杂性的依赖项。每个库都需要版本更新、在破坏性变更时进行迁移，并且会增加APK大小。添加库时要等到有该库解决的具体任务出现。从OkHttp（最小化HTTP客户端）开始，在需要REST客户端时添加Retrofit，以此类推。

iOS中的YAGNI：不要强制使用SwiftUI

SwiftUI——一个强大的框架，但其引入应该由实际需求驱动。如果项目从iOS 14+开始，并且对自定义UI组件的需求最小——SwiftUI是不错的选择。如果项目需要支持iOS 13或需要复杂的自定义手势——UIKit仍然是正确的解决方案。YAGNI反对"因为时髦"而迁移到SwiftUI。

// YAGNI：在没有真正从SwiftUI获益之前使用UIKit
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "个人资料"
    }
}

// 如果需要SwiftUI——通过UIHostingController实现
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free的"SwiftUI vs UIKit决策指南"（2024）分析建议：在没有明确业务原因（例如，设计师需要Live Preview）的情况下，不要将现有的UIKit屏幕迁移到SwiftUI。重写可工作的代码直接违反YAGNI。SwiftUI——用于新屏幕，UIKit——用于现有屏幕。

遵循YAGNI时的典型错误

将YAGNI作为糟糕架构的借口

最危险的错误是将YAGNI作为糟糕架构的借口。"我们不会创建仓库层，因为YAGNI——直接在ViewModel中写请求。"这不是YAGNI，这是积累技术债务。YAGNI禁止多余的功能，而不是架构完整性。

架构是对可维护性的投资。如果你写超过3个屏幕——基本架构层（MVVM、仓库）已经合理。如果只有1个屏幕——你可以采用更简单的方法。关键：确定当前功能所需的最小架构，不要添加更多。

将决策分为"架构性"和"功能性"。架构性决策（层、导航、DI）不受YAGNI约束——它们对可维护性是必要的。功能性决策（功能、屏幕截图、动画）——受约束。

在处理API时盲目遵循YAGNI

另一个极端——忽略未来的API约定。开发人员从后端收到包含5个字段的JSON，只解析其中3个，因为"其他的根据YAGNI不需要"。问题：当后端添加字段时，如果响应发生变化，可能会破坏解析。解决方案——映射所有响应字段，即使不是所有字段目前都在使用。

根据Meta API设计指南（2023），客户端应该解析服务器返回的所有字段，忽略未使用的字段，但不能丢弃整个结构。YAGNI在这里是关于别的事情：不要添加规范中尚不存在的字段的处理，"以防后端返回它们"。

解析整个响应结构（服务器当前返回的所有字段）。不要添加当前API规范中不存在的字段的处理。这是在YAGNI和应对变化的能力之间的平衡。