本文根据作者的房产类项目经验，结合项目中的户型图/房型图模块部分，总结了制定户型图库的三个基础方法。

在房产网站（贝壳、安居客、房多多等）查看房源时，会发现每个小区都有一个户型图/房型图模块展示小区的户型。

在做房源管理系统时，要考虑每个小区都有相似户型的房源，这些房源的户型图可以共用一套，如果建立户型图库，集中管理这些图片，那很多房源的户型图无需重新上传，直接从图库中选用，这样做既解决了户型图重复绘制、效率低下问题，也解决了户型图管理混乱的问题。

系统问题及优化策略

接手项目时，户型图在本地电脑管理，房源用到某户型图时，只能在电脑上翻找，然后上传到房源上（如下图）。

按照常规策略方法进行评估，对户型图库项目做如下分析。

1. 发现问题：

• ①本地电脑管理户型图，不能共享，查找困难，存在丢失的风险。
• ②户型图在房源上上传，以独立数据存在，系统不能校重，导致户型图重复。
• ③不能有效复用户型图。

2. 定义理想态：建立易于管理的标准户型图库，且房源容易调取。

3. 提出解决思路：

• ①建立户型图库模块，集中管理户型图。
• ②新增、修改房源，增加“选择户型图”功能，直接调用户型图库。

4. 资源支持：

• ①已经上传的户型图导入户型图库表中。
• ②户型图缺失的户型、朝向、面积等数据从关联小区上取值，补足数据。
• ③历史重复数据的处理：需要处理房源和户型图库两部分数据，这个需要业务配合处理。

1.0版本的迭代

由于要记录房源上户型图专员的绩效，所以在1.0版本仅增加了户型图库的概念，上传户型图依然在房源上：

1. 房源上保留上传户型图功能，房源上传的户型图进入户型图库，户型图继承当前房源的小区、户型、面积、朝向等信息。
2. 房源上增加“选择户型图”功能，直接调用户型图库。

问题：

1. 户型图库模块没有独立出来，依赖于房源管理，信息输入不灵活。
2. 不能修改、删除户型图。
3. 不能标识户型图是自有、他有类型。

1.1版本的迭代

和业务沟通，户型图专员的绩效不应该放至房源上，可以通过户型图库的新增量去计算他们的绩效，所以在1.1版本解除了户型图库对房源的依赖：

1. 独立户型图库模块，可以新增、修改、删除户型图。
2. 房源上去掉“上传户型图”，仅保留“选择户型图”功能。
3. 新增户型图，反向关联小区，户型、面积、朝向等信息可灵活配置。

总结

1. 模块松耦合

所谓“耦合”，指将两个模块像链子一样连接在一起，存在依赖关系，若其中一个模块要动，势必引起另一个模块要改。在架构模块的时候，尽量做到松耦合架构，以降低整体复杂性和依赖性。

见下图:

1.0版本，上传户型图放至房源管理模块，导致房源管理和户型图库纠缠在一起，调整户型图功能，需要动房源新增、修改模块。

1.1版本房源管理和户型图库相对独立，只是数据层面有交互。

2. 穷尽业务场景，尽可能找到所有异常分支

异常分支越详尽，解决方案会更优，做B端产品，要尽可能分解业务场景，覆盖所有可能的异常分支。

本案例中，列举所有与户型图库有关系的用户，并用5w3h分析，重点关注当前场景是否为高频场景，是否契合目前的需求。其中一种情况，户型图专员在房源上新增户型图，可以记录绩效他的绩效，通过分析，知道这个是历史原因造成的，不利于模块之间的松耦合。

另外，计算绩效，完全可以从户型图库切入，所以我们果断舍弃这种场景，并提供了更便捷的解决方案。

3. 做数据字典，能配置的数据尽量做成字典

数据字典（data dictionary）是对数据对象或者项目描述的集合，数据字典可以集中管理数据，相同的数据维护一份，系统内统一调用。数据字典的特点是配置灵活，调取方便。户型图库也属于数据字典，有了户型图库，相同户型的房源可以统一调用同一张户型图，无需重复上传；另外户型图的信息在户型图库中完成配置，可以同步至全局。

除了这种图片字典外，我们还会遇到字段数据字典，例如户型、朝向、建筑类型、房证年限等等（见下图）。

户型图库作为楼盘字典的一部分，起至关重要的作用。本文从实践出发，运用策略分析的通用方法论拆解项目，并总结了松耦合、穷尽场景、做数据字典3种通用方法，做B端产品这三种方法非常普遍，几乎贯穿整个系统，请谨记！