【我对软件平台架构的理解】第二部分：对软件平台架构的认识（一）

一、平台架构的认识

1、平台架构是用来促进发展的

1）、促进企业发展

很多软件企业在发展过程中，为了更好地规范开发过程、组织团队合作、聚集技术力量、推动攻关突破、加强功能重用、促进项目水平、提升应对能力等，成立了各自的技术组、架构组、系统组、支撑组、平台组，形成了各自的过程规范、技术方案、公用功能，乃至开发构架和产品平台，希望集中技术力量、优化过程管理、整合能力资源，以促进产品项目交付过程的系统化、规范化和可量化。

这既是平台架构产生的原因，也说明大家都想通过产品平台或技术构架，来提高自身的生产力和生产效率，为企业发展提供助力。

2）、解决企业瓶颈诉求

在软件开发过程中，总会遇到一些类似的问题，比如工期评估偏差大、技术方案差别不一、技术问题不好解决、公共功能多种实现、文档资料残缺不全、特定人员依赖较重、代码质量参差不齐、工作交接难度很大、技术资产难以留存等问题，这些问题影响或制约了企业的项目能力、开发效率、过程控制、质量管理等工作，甚至因为人员变动等原因，导致其工作无人能接，技术成果从此无用，架构路线推倒重来，业务功能重新开发等尴尬局面。

而这些痛点或瓶颈问题，可以通过对技术的产品化思维，利用平台架构思想或产品，进行有效地支持、控制和改善，帮助减少无谓的重复工作、技术成本和资源浪费。

3）、把握方向和认知

平台架构有其形成的必要和应用的价值，但也需要对它保持正确的认知和很好地把握，平台架构对认知能力、架构能力、把控能力等的要求都很高，对平台架构的方向控制不好或认知不够透彻，很可能走向错误的方向或退化的误区，难以保证其继续遵循合适、简单、演化的架构三原则【注1】，那么平台架构就很难合理、稳定、健康地发展，逐渐失去其应有的价值，甚至产生负面的作用。

那么什么是平台的正确认知呢？这也是我这几篇文章想表达的内容，简单来说，就是明白平台是用来做什么的，它需要有什么特性，应避免怎样的问题，以及它应该有怎样的发展。

4）、避免失败或束缚

尽信书则不如无书，如果认为平台构架能够解决一切问题，那么就可能会发生更大的问题。对于平台架构，既要避免对其产生过多要求或束缚，制约其发展，也要避免其对开发过程过于限制，对开发造成很大的阻碍。

以平台架构而言，首先应明确对它的期望和它需要承担的责任，并考虑到可能面对的其它问题及对待这些问题的策略，然后在平台架构发展过程中，尽量避免因超出预期的能力要求、不断提出的功能需求和其它外力原因，让平台架构陷入不停扩充、疲于应对、代码堆叠、臃肿复杂、难以进化、重负难承的境地，否则平台架构很难发展起来，甚至终将成为失败品而被放弃。

另一方面，平台架构应该提供充分的可扩展能力和可替换能力，使其在规范开发过程的同时，也允许产品开发人员在平台架构的开放约定下进行扩展，甚至替换平台架构的部分能力，以满足产品项目的实际要求。当平台构架对产品项目产生的阻滞作用，接近或超过其带来的助力时，这个平台架构要么需要马上重构，要么就该放弃使用了。

5）、权衡价值与冲突

平台架构提供的很多特性，其实是相互冲突的，比如规范性与灵活性、可控性与开放性、可靠性与可扩展性、简单化与可配置化、轻量化与丰富功能等等，这些冲突的特性需要被很好的认识到，并合理地权衡他们在不同情况下各自的要求、影响以及效果，选择更优化的决策和更平衡的处理，以实现他们的对立统一。同时，这些权衡结果应尽量不破坏平台架构本身的合理性、健康性和优化性。

对于容易产生理念冲突、难于选择或可能对规范产生影响的位置，要及时发现并给出意见或替代方案，指导开发人员按照相对合理的方法进行开发、扩展或替换，同时对其可能产生的影响，也要做出适当的解释说明。

对于平台架构自身也一样，比如合理性和实用性，都需要建立在大量的时间上，只不过一个是对平台架构内部，一个是对业务项目支撑，当业务急于使用平台架构的能力，但此能力是平台架构需要具备但无法在短期内保证其合理可用时，那么应尽量以较合理的方案或方式提供此能力，并在后续过程中及时对其进行调整改进。而当平台急于发展导致内部不再优化稳定时，一定要适时地停下脚步，对平台进行必要的修正重构，否则当平台架构问题重重、积重难返时，那么它也快走到尽头了。

2、平台架构不是空中楼阁

1）、平台架构不是遥不可及的

平台架构其实是可大可小的，一个大的平台，可以是很多个能力组件、大量的内置功能、全过程的管理支持，开放性的服务体系，以及成熟的规范指导，而一个小的开发架构，可能仅仅是几个开源框架的粘合和一些开发方面的约定。

对于一个小型企业或项目团队，因为规模不大，平台架构并不一定是必须的。当在需要平台架构的时候，可以结合自身实际&