为价值服务
我们可以将软件所存在的价值分为 4 层：
-
底层为业务价值，体现为软件的商业目标。
-
在目标之上的是业务模型，是承载软件的模型。
-
还有一些是软件的具体逻辑，为模型的实例化。
-
最上层是软件的交互方式和UI样式，是面向用户的最近一层。
业务价值是软件的灵魂，架构是软件的支撑，逻辑规则和交互体验是对软件的具体实现。工程师需要理解软件背后的业务逻辑和业务价值，找到了一个软件的业务价值就可以快速的理解软件的架构。
从技术角度上可将软件设计目标拆分为提升业务价值与提升架构价值两方面，共同支撑业务发展目标。
其中，提升业务价值是软件设计的核心目标，包括需求的实现，以及可用性保障（性能、稳定性、资金安全），这占据了我们绝大多数的工作内容。
提升架构的价值就是让我们的软件具备更强的变更弹性，因为业务通常是不明确的、飞速发展的，架构的价值在此时便无比重要，可以从两方面理解：
-
当需求变更时，所需的软件变更必须简单方便，力求降低每行代码的变更成本，提高生产效率
-
做好功能的边界划分，变更实施的难度应该和变更的范畴成等比
提升业务的价值
业务的平稳实现
支撑业务需从项目全生命周期思考：如何做好各业务线人员安排、如何管理项目关键节点、如何保障需求实现质量以及如何高效处理业务上线后存在的问题。
项目管理
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。--《人月神话》
项目管理者需牢记一点：一切都将运行良好的假设是错误的，大型的编程工作或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
错误不会消失，我们的构思是有缺陷的，因此总会有bug，我们的乐观主义并不应该是理所应当的，开发人员应持续提升自身对需求的进度预估及管理能力。
质量保障
为更好地实现业务价值，程序应当正确表述业务流程，具体体现在较高的提测质量和稳定可靠的线上运行时。为此，我们应从流程保障、自动化测试、Review机制、线上问题反馈处理机制等多方面提升业务质量。
规范开发、测试流程：
大颗粒度需求需要严格遵循流程规范，Case评审、自测节点与提测演示不应被省略，协作时遵循协作规范SOP，遇到问题与风险应及时抛出。
自动化测试：
自动化测试是软件测试活动中一个重要的分支和组成部分，即利用工具或脚本达到测试目的，没有人工或者极少人工参与的软件测试活动称为自动化测试。
-
建设UI自动化测试，对图形化界面进行流程和功能等方面进行测试。
-
单元自动化测试：自动化完成对代码中的类和方法进行测试，主要关注代码实现细节及业务逻辑。
-
接口自动化测试：测试系统组件间接口的请求和返回，接口测试稳定性高，更适合开展自动化。
从错误中学习：
建设质量周报、研测周会与项目复盘机制。
问题反馈处理机制：
优化线上问题反馈处理流程，建立Oncall机制，明确每周的值班人，保障线上反馈得到及时的处理。
可用性保障
软件设计应注重可用性保障，在实现需求之外要求满足软件的可用性保障，包括性能保障、稳定性保障与资金安全等。
性能优化
性能优化是一个非常宽泛的话题，一个首要需要回答的问题是：什么叫性能好？
延时、QPS承载量、平均响应时间、每秒IO数量（IOPS）、负载，以及FCP、LCP、TTI等等指标都可以划分进入性能的范围内，而过于宽泛的优化目标不具备可执行性。
因而性能优化的起始点在于明确优化目标范围，选中核心指标并确定指标基线。做到这一步时别忘了问自己一个问题：优化的收益和成本对比如何？
性能优化的方法论总结如下：
-
量化性能指标：性能问题要求一定是可观测的、可量化的，做优化前需要收集各阶段耗时，明确优化目标，并进行链路拆解。
-
分析与解决问题：根据已有的性能数据，找出性能瓶颈并解决，设计优化方案时通常需要依据成本与收益制定不同的优先级，分批次推动优化。
-
验证收益：如何确保优化是行之有效的？需要设计实验方案，明确如何利用数据指标分析优化前后的性能表现与业务表现，并得出优化报告。
-
防劣化：避免性能劣化，这要求我们做好实时监控与劣化感知，可通过Lint检查（防止写出造成性能问题的问题代码）、上线前卡点（使用虚拟机、云真机自动化测试，在上线前阻断）以及线上监控告警等方式及时感知劣化。
性能数据应做到持续追踪，需建设看板统一查看各业务、各页面性能表现，对于不符合基线的页面及时抛出来并着手优化。
稳定性保障
稳定性是底盘，保障稳定性是一个团队的底线
风险挖掘 → 风险预防 → 应急快恢
-
事前：对于事中应急相关的MTTR的收敛，所有能力建设工作，均可以放到事前
- 快速响应并回复的达成依赖应急流程，定位，止血能力的建设，由演练支撑SOP以及能力的验证，保障高时效响应处理以及能力的持续高可用
-
事中：基于事前能力的建设，事故发生时的应急协同效率能得到有效的保障，同时，定位与快恢能力，依赖各类专项，各类产品组件等能力建设
-
快速发现的达成依赖发现能力（监控&巡检）建设，包括覆盖，准确，噪音低
-
如事故发生时，分析事故点前的变更相关信息，做基础定位
-
-
事后：面向事故的改进分析与跟进
-
数据分析，支撑稳定性建设情况，推进稳定性的成熟演进
-
反哺事前稳定性建设，如监控补全，容灾能力建设等
-
用户体验
提升架构的价值
什么是架构
提升架构价值就是用最少的修改成本满足构建和维护该系统的需求，支撑软件系统的全生命周期，让系统便于理解、易于修改、方便维护、轻松部署。
软件生命周期里的每个环节，诸如开发阶段、部署阶段、运行阶段、维护阶段均具有不同的追求，并需要以多种手段保障软件架构的灵活和稳定。
编程范式
编程范式是是指软件工程中的一类典型的编程风格，它限制我们的控制流和数据流。
面向对象编程
在互相解耦的组件间实现函数调用的场景下，非面向对象的编程语言采用函数指针的方式进行组件间通信，带来的问题是要求对指针调用的约定很严格，容易产生空指针等内存问题。
面向对象编程限制了函数指针的使用，通过接口-实现、抽象类-继承等多态的方式来替代。上文提及的对控制流的限制就是限制了函数指针的使用，减少代码转而去执行一段其它不可控代码的可能。
编程范式只是一种编程风格，不应将其理解为某种底层安全保障。
函数式编程
函数式编程对数据流进行了限制，用完全不可变的函数式编程可以避免可变变量导致的竞争问题、死锁问题、并发问题等。
在函数式编程中，函数要保持独立，所有功能就是返回一个新的值，没有其他行为，尤其是不得修改外部变量的值。
我们可以通过将需要修改状态的部分和不需要修改的部分分隔成单独的组件，在不需要修改状态的组件中使用函数式编程，提高系统的稳定性和效率。
设计原则
设计原则是架构设计的指导思想，它指导我们如何将数据和函数组织成类，如何将类链接起来成为组件和程序。
架构的主要工作就是将软件拆解为组件，设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。
开闭原则
在众多设计原则中，OCP 开闭原则是我们进行架构设计的主导原则，即设计良好的软件应该易于扩展，同时抗拒修改。开闭原则也是OOP理论中5个原则之一（SOLID，单一职责原则、开闭原则、里氏替换、接口隔离、依赖反转），是前辈们总结出的软件开发工程化的经验。
在老代码上添加新的功能时，最好将原来的代码像三明治一样夹起来，在外层实现新功能，实在做不到再改老代码。这是因为直接魔改老代码的思路，是有很多危害的，例如让原来的函数产生了其他副作用的话，很容易引入BUG。
函数式编程推崇无状态无副作用的纯函数的组合来实现功能，其中一方面的原因在于不可变Immutable和显式Explicit的数据和逻辑更加健壮，即使出现问题也更容易定位。
具体来看，在修改代码时第二种符合开闭原则的思路，在实现时有不同的表现形式：
-
修改参数时：利用函数重载或类似的机制，达到无需修改原代码调用方的目的；
-
增强功能时：利用多态性 或合适的设计模式来设计编写新的代码，达到基本不用改原有代码的目的。
软件维持局部系统的持续稳定的方案，一方面是重构 ，持续重构现有的代码实现和整体架构；另一方面，在实现新的需求时，遵循开闭原则避免老代码的加速腐化。
思想应用
组件按层次拆分可以拆为：业务实体、用例、接口适配器、框架与驱动程序，其中：
-
业务实体是纯粹的业务逻辑，与UI、存储、框架无关
-
用例代表了结合输入输出的业务实体，可理解为结合了UI、用户交互的业务逻辑
-
接口适配器通常代表与外部接口的交互逻辑，例如对API的处理
-
框架与驱动程序更偏向于底层支持，例如程序所用的UI框架、数据库等
例如倒计时组件，单纯的计数逻辑对应的是实体，结合了UI、触发逻辑、重试逻辑的计数规则对应的是用例，我们改变UI并不会影响到基础的计数逻辑。
这四层组件结构代表了依赖关系的指向，由低层次（框架）指向高层次（业务实体），越低层次的组件越插件化，切换UI框架应当对接口适配器完全无感，切换接口也应该对UI渲染不造成影响。
编程范式和设计原则指导我们如何拆分组件、处理组件依赖，应做到尽可能解耦，保留尽可能多的可选项（例如业务代码与UI框架解耦）；但同时需避免过犹不及，组件边界的划分以满足业务长久发展为目标，减少过度设计带来额外的维护成本。
架构目标需要适应业务的发展
时间管理领域最常用的莫过于史蒂芬•科维的"四象限法则"，他用"重要"和"紧急"两个维度把事情分为四类：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急。实现业务价值的需求通常都比较紧急且重要，架构价值的工作内容通常都很重要但基本不是很紧急。
- 支撑核心业务主流程
支持业务核心价值是最为重要的，首要需要保障高质量交付需求、没有Delay以及影响主流程的Bug，程序能够体现产品预期的目标。
例如大型活动需求都有固定的上线日期，若是没能在规定时间内上线则会带来巨大的业务损失，因而我们需要尤为注重活动中的项目管理，建设最佳实践指导SOP，同时从多方面保障业务的可用性。
- 支撑核心流程的扩展与细分
对核心主流程进行完善，技术架构设计是为了长久保障业务变更而存在。开发同学需要在实现业务需求的过程中，把架构工作插入进去，提升代码的灵活性和维护能力。
产品在不同的发展阶段具有不同的核心指标，目的指标又可以被拆解为不同的过程指标。依据目标的不同，对应的产品设计、技术支持也会有所不同。
指标应当是量化的，相应的功能实现要预计能带来指标的量化提升。开发同学也需要尽可能的去思考，指标的制定是否符合产品当前发展阶段，指标定的不合理对产品影响很大，同时避免唯指标做事，从产品发展、用户体验的角度思考业务代码设计。