对于如何去做一个系统的理解

前言：

在现在的公司做了5年，从程序员到管理，见证了个人的成长，到了该选择离开的时候了。昨晚找我们总监请辞，聊的时候他跟我说了这么多年他对我的印象，并做了总结。他肯定我的能力，但他觉得我这么多年最大的问题就是没有想清楚自己想做什么。对于这一点，我觉得有点不太认同，于是我就跟他说：“我未来的目标是自己做一套系统” 我们领导就问我“那你说说，怎么做一套系统”讨论过程省略…

分享我的理解：

1.如果我所做的系统所处的行业是一个我完全陌生的行业，那我首先要做的可能就是做需求挖掘，方法是找用户谈业务流程，找业务中的痛点。

2.寻找行业相关的最佳实践，思考所了解到的最佳实践是否解决了用户所描述的痛，或者是否对这些痛给出了解决方案。

3.分析业务流程，梳理业务实体，之后依据对最佳实践的理解，为用户提供我的解决方案。

4.明确业务边界后，开始进入设计。

4.1 关于技术选型，以我们目前使用的Orm框架Entity Framework举例，在EF中提供了三种设计模式，分别为：“TPT”、"TPC"、"TPH"，那我应该如何选择设计模式进行应用呢？首先在进行设计阶段，我们明确的了解了我们的业务边界、可扩展性及存在的问题。那在设计的时候我们就是要用技术来解决这些问题。

简单介绍一下EF的这三种映射关系：

• TPH(Table Per Hierarchy)：基类和派生类都映射到同一张表中，通过使用鉴别列来识别是否为子类型。这是Code First默认规则使用的表映射方法。
• TPT(Table Per Type)将所有层次的类都放在了一个表里，而TPT在一个单独的表中储存来自基类的属性，在派生类定义的附加属性储存在另一个表里，并使用外键与主表相连接。
• TPC(Table Per Concrete Type)类似TPT，基类与派生类都映射在不同的表中，不同的是派生类中还包括了基类的字段。

通过描述可以想到，对于以上三种继承关系生成的表结构，我们查询的时候应该如何去查询。

再去想业务中我们要查什么，如果查询综合数据比较多则选择TPT，因为其生成的SQL是联查的SQL。

如果查询个性的数据比较多，则应选择TPC的设计模式，因为其可以针对单独的子表进行查询。（效率较高，扩展性也具备）

如果扩展的可能性较小，则应采用默认的TPH，所有数据在一个表中，方便快捷高效。

4.2 在设计的过程中要充分思考业务的延展性，做好下一迭代的预留，对业务实体进行抽象，抽象的原则是业务具备可扩展性，可以清楚的描述出共性与个性，方法是思考扩展，并列举扩展的实例，如果思考不出则需思考该业务对象是否有抽象的必要。

如果采用Agile，那就要求在每个Scrum中明确目标，这一点很重要。方法是将目标细化成点，以功能为单位，每个点存在哪些问题，接下来是画UI，在画UI的过程中要能够充分识别出技术的风险。这样我们就可以较为准确的评估我们开发所需的时间，也可以明确我们要交付给用户的是一个什么样的东西。

5.之后就是开发、稳定、部署三个阶段。（注意事项：开发阶段要将业务中相同的行为进行接口抽象，以抽象为基础进行不同的实现。稳定阶段要与用户确认下一个迭代的工作内容，包括bug调整）

暂时就想到了这么多，如果各位有什么想法欢迎一起讨论，本人也愿意与大家一起学习。