从知识视角理解软件开发
软件构造中的核心知识：业务知识与架构知识
在软件构造过程中，最关键的两类知识是业务知识和架构知识。业务知识回答“什么是正确的软件”，而架构知识解决“如何正确地构造软件”。从这两个方面深入理解软件构造，可以帮助我们在设计和开发过程中做出更明智的决策。
1. 业务知识：定义正确的软件
业务知识是关于如何解决现实问题的知识，包括业务的目标、规则、限制、和已有的解决方案。它定义了“正确的软件”是什么，即软件应实现哪些功能来满足业务需求。
-
业务知识的来源与特点：
- 问题驱动：业务知识源于对现实世界问题的理解，是为了在软件中解决这些问题。
- 不等同于功能点：业务知识并非直接对应软件的功能点，而是表现为待解决的问题、规则和限制条件。在软件实现中，业务知识才映射为功能点。例如，同样的审批流程，现实中可能用邮件、微信群完成，而在软件中可能通过OA系统的特定工作流实现。
- 组织与流程的影响：业务知识不仅存在于软件系统中，还嵌入在组织的流程与人员中。当软件接手部分业务知识或改变其范围时，往往伴随组织流程的变更，如从邮件办公模式切换到微信办公模式，组织的流程会相应调整。
-
业务知识在软件研发中的作用：
- 传递与学习过程：软件研发是业务知识的传递与学习过程，研发流程因此具备迭代特性。每次迭代包括：探测（构建软件）、感知（反馈验证）、响应（改进方案）。在产品生命周期内，这一过程类似于精益创业中的“构建-度量-学习”循环，持续验证软件是否满足业务需求。
- 转化为软件需求：在研发之前，需要将业务知识转化为目标解决方案（如业务架构愿景）。根据这一解决方案，将业务知识分解为具体的软件需求，定义不同业务模块的功能。
-
复杂认知模式：业务知识的转化过程充满不确定性，体现为复杂的认知模式：
- 感知：对业务问题的初步理解。
- 分析：根据业务架构或解决方案进行问题处理。
- 响应：生成软件需求，分配给不同的业务模块。
2. 架构知识：正确构造软件的方法
架构知识是关于如何有效构造软件的知识，涵盖技术决策和设计模式，解决软件的性能、可靠性、可扩展性等非功能性需求，保证软件能够正确实现业务需求。
-
架构知识的来源与特点：
- 技术视角的解决方案：架构知识从技术视角定义系统结构和组件交互方式，解决性能、扩展性、安全性等非功能性问题，是软件系统的技术蓝图。
- 影响非功能性质量：架构知识直接影响系统的整体质量，如性能优化、可靠性保障和可扩展性设计。这些非功能性质量虽然用户不直接感知，但对用户体验至关重要。
- 任务分解的指导：架构知识在任务分解过程中发挥指导作用，确保软件需求正确映射到架构组件，避免架构腐化（即任务划分错误导致的架构失效）。
-
架构知识在软件构造中的作用：
- 设计与决策依据：架构知识用于制定设计决策，如选择合适的技术栈、确定系统分层、定义服务接口等。这些决策影响软件的开发效率和质量。
- 指导功能与非功能性质量平衡：架构知识帮助团队在构造过程中平衡功能性与非功能性质量，确保软件不仅满足业务功能，还具备良好的性能、安全性和可用性。
- 任务分解与架构腐化：通过架构指导任务分解，将需求按架构规则分配到合适的组件。架构腐化往往源于分解过程中架构未能有效指导，导致持续的错误划分。
-
庞杂认知模式：架构知识的应用也遵循庞杂模式：
- 感知：对软件问题的初步理解。
- 分析：根据架构处理问题，进行技术分析和设计。
- 响应：分解任务到架构组件，确保系统整体协调。
3. 功能性与非功能性质量的平衡
在软件构造过程中，功能性质量和非功能性质量相辅相成，软件既要实现其核心任务，又需在性能、安全性、可用性等方面表现出色。为了实现这一平衡，需采用综合的质量保证措施：
-
代码审查：建立在反馈基础上的复杂模式措施，主要包括探测（成员实现功能）、感知（团队反馈评估）、响应（改进方向）。
-
测试策略：基于分析的庞杂模式措施，包括感知（理解需求边界）、分析（分解为不同种类测试）、响应（完成测试）。
总结
业务知识与架构知识在软件构造中的作用分别回答了“什么是正确的软件”和“如何正确构造软件”这两个核心问题。通过理解这两类知识及其应用场景，可以有效指导软件研发的每一个环节，确保软件既符合业务需求，又能在技术上稳定、高效地运行。