今天正在整理目的地旅游产品的上货、维护流程。所谓目的地旅游商品，比如火车通票，城市交通卡，博物馆门票等等。过去几年这部分不是我们的重点（过去主要关注于火车点到点车票），现在随着G2Rail已经把覆盖到了全球大部分铁路交通发达的国家和地区，是时候需要把注意力转到这里了。这样可以做的，比如旅客买了我们布拉格-柏林的火车票，G2Rail可以在旅客到达柏林提前一天，给他推荐在柏林吃、住、行、游、娱、购的商品。比如去参加一个游遍柏林Private Beer Tour，去参观一个著名博物馆等等。
业务方面，我们首先找到了数量众多的旅游产品，仅仅柏林一个城市就会有八百多个各种各样的门票，Tour一类的商品。但是目前有系统中有超过五千多个城市，如何把这几百万个各种产品批量导入到系统中，方便的管理，优雅地在网页和App上展示就是一个很大的挑战。
结果发现，早期的设计（也是目前的）太过于灵活。为了支持可能的众多商品，基本所有商品属性（成人价格、青年价格、舱位、票种等等）都是自定义，为了方便管理商品属性的集合，有抽象出原型。这些抽象都过于技术，导致了不少问题：
- 各种各样的抽象和灵活性，导致系统上货设置挺多，业务人员很难掌握。
- 过高的属性定义自由度，导致产品定义各不相同，十分随意。现在几百个商品都已经很难维护。
这其实是在和Wen一起开发G2Rail过程中，经常会遇到的情景。在我们刚刚接触某个新的业务领域，我们会因为自己的技术人员背景，从技术角度去重构或者抽象出一些设计和架构。可是几年后，在真正开始理解业务之后，发现我们过早的技术抽象，给我们的业务和系统演化埋了很多坑。因为每次调整，就不得不迎合过去的抽象设计，直到下定决心，把这部分设计打掉重练。这也引发我们的思考，这是不是技术人员经常会犯的错误？结果还真发现在2011年Joel Spolsky提到了”宇航员架构师“。我们才这可能也是一种Confirmation Bias，原因用自己过去熟悉的方法论去诠释、看待、抽象所见到的事物。
目前我们还是经常会因为发现某些重复，而引发一些抽象或者重构的想法，但是我们的采用了不同的做法：
- 遏制住自己技术抽象的冲动，先用最简单、蠢的设计，让业务能够转起来，哪怕一开始看着挺Messy。
- 接触、体验业务领域最基本、最Detail、最琐碎的点点滴滴。比如帮客户“金色山口列车”订座，帮客户去退一张比萨到佛罗伦萨的区间车火车票，帮客户去查找为什么伦敦圣潘克思车站的欧洲之星列车晚点。
- 不断重复，不断地出状况，会刺激自己产生想法。
- 交流想法，然后很重要的是把想法搁置一下，晾在一边。
- 直到忍不住了，然后找一个空闲的时间，首先从业务角度思考，然后从技术角度思考抽象
