1. 简介
在本文中，我们将探讨 ad-hoc 这一术语在不同语境下的含义，并重点理解什么是 ad-hoc 编程（Ad-hoc Programming）。
2. 什么是 Ad-hoc
通常来说，ad-hoc 指的是即兴决策、临时应对，只关注当前特定问题的解决方式。 与之相对的是系统化思维（Systematic Thinking），即全面分析问题后，以结构化的方式进行设计和实现。
举几个例子来说明：
在网络通信中，一个 ad-hoc 网络 是一种临时构建的网络结构，没有预先规划，根据当前需求即时创建：
在企业治理中，为了解决某些特殊问题，我们会临时成立 ad-hoc 委员会。
在军事领域，面对突发状况时，也会临时组建 ad-hoc 作战单位 来快速应对。
3. Ad-hoc 编程
Ad-hoc 编程指的是在没有详细设计和规划的情况下，为解决特定问题而快速编码的行为。 它强调的是快速交付和问题解决，而非通用性或可维护性。
3.1. Ad-hoc 数据库查询
一个典型的 ad-hoc 查询是指一次性、硬编码参数的 SQL 查询语句，不带参数，也不属于任何存储过程。
例如，我们有一个 employee 表：
| id | first_name | last_name | department_id |
|---|---|---|---|
| 101 | bob | stylus | 10 |
| 102 | rita | ora | 10 |
一个 ad-hoc 查询如下：
SELECT * FROM employee WHERE id = 101;
而非 ad-hoc 的做法是编写一个可复用的存储过程：
SELECT * FROM employee WHERE id = @id;
✅ 优势：快速写完就能执行
❌ 缺点：无法复用，缺乏参数化处理能力
3.2. Ad-hoc 编码
Ad-hoc 编码指的是开发人员跳过需求分析和设计阶段，直接进入编码。 这种方式虽然能快速出结果，但往往效率低下，且无法覆盖所有可能的输入情况。
举个例子：判断两个单词是否为变位词（Anagram）
比如 word1 = "break"，word2 = "baker"，它们是变位词。
一个 ad-hoc 的实现方式是：
algorithm CheckAnagramsAdhoc(word1, word2, n):
// INPUT
// word1, word2 = the words to process
// n = the length of word1 and word2
// OUTPUT
// true if the words are anagrams, false otherwise
if each character of word1 is in word2:
if each character of word2 is in word1:
return true
else:
return false
⚠️ 时间复杂度为 O(n²)，效率较低。
如果我们先分析问题，可以采用排序后比较的方式：
algorithm CheckAnagramsAlgorithmic(word1, word2, n):
// INPUT
// word1, word2 = the words to process
// n = the length of word1 and word2
// OUTPUT
// true if the words are anagrams, false otherwise
sort word1
sort word2
if word1 = word2:
return true
else:
return false
✅ 时间复杂度优化为 O(n log n)，代码更简洁高效
3.3. Ad-hoc 测试
Ad-hoc 测试是一种非正式、无结构的测试方式，测试人员随机选择系统模块进行测试，不遵循测试用例设计流程。
⚠️ 通常用于时间紧迫、无法进行完整测试的场景。但容易遗漏边界条件和复杂逻辑。
4. 何时使用 Ad-hoc 编程
适合用于需求变化频繁、规模较小、需要快速交付的场景。 我们可以跳过分析和设计阶段，直接开始编码，从而缩短上线时间。
例如，我们在评估将搜索微服务从同步模式切换为异步模式的几种方案时，比如使用线程池、消息队列或者发布-订阅模型，可以采用 ad-hoc 编程方式为每种方案快速实现一个原型，进行初步测试后选择最优方案。
✅ 优势：
- 快速验证思路
- 节省设计时间
❌ 缺点：
- 代码难以复用
- 可维护性差
- 性能可能不优
5. 总结
Ad-hoc 编程是一种即兴、快速解决问题的方式，适用于需求变化快、时间紧的场景。虽然它能快速出结果，但通常效率不高，也不具备通用性和可扩展性。
✅ 适用场景：
- 快速原型验证
- 小规模问题解决
- 需求不明确或变化频繁的项目
❌ 不推荐用于：
- 核心系统开发
- 需长期维护的模块
- 对性能或可扩展性有要求的项目
总之，ad-hoc 是一种“救急”手段，不是工程化开发的首选。