我经历的那些系统迁移
迁移，应该是为了更能适应环境，走地更远，或者飞地更高。
第一次迁移，从trs迁移到solr。
迁移时长：1.5-3月
投入人员：2-3人
前期是系统调研，框架搭建以及相关测试。相关工作是1个人用2周的时间完成的。
通过测试中的相关指标，如qps，关键词命中结果数，单次查询所花费的时间，热门关键词搜索结果比对等，确定了迁移的必要性：
1 用开源的solr替代收费的trs
2 保证迁移后的系统在检索质量和查询性能上，不亚于trs
3 新系统具备可扩展性。原来的trs是单台，性能以及出现问题，扩展成集群的话，费用太高。
做任何事情，都要有针对性。就像这次迁移，我们主要是要解决性能问题，同时为公司节约成本。通过对基于solr的系统的测试，发现可以实现这个目的，所以才决定去做。而不是一拍脑袋，说觉得solr很cool，所以我们要从trs迁移到solr。
我们应该做很cool的事情，但是这个做事要有前后顺序，因为我们做了什么事情，所以这件事情变地很cool。
技术，改变生活。应该让生活更容易，make life easier！
这让我想起的了unix编程艺术中的那句--过早优化是万恶之源。
贴近生活一些就是：没事不惹事，来事不怕事。
好久不写东西了，废话扯地有点多。
在确定可以做之后，又投入了2个人，在一个月之后，就已经完成了主体模块的迁移，并上线。剩下的1个半月，主要从与迁移剩下的不到10%的旧功能，和新功能的开发与接入，还有就是系统的优化以及文档的整理。
第二次迁移，将一个评论系统从.net迁到php。
这次迁移用了不到两个月的时间，参与的人员也不到2人（1.5人）
迁移的目的也很明确。
评论系统年久失修，没有专人维护。所以我们只能将其迁移到我们能hold住的php，以便满足业务需求。
迁移的过程大概这样：
1 确定了一个要使用的php框架，当时zend是一个不错的选择。
2 整理要迁移的功能，这个对照了旧的系统
3 迁移前台页面，实现后端功能。
因为我不是全程参与，所以详情不多说，主要说说相关体会：
任何迁移，都是有风险的。就算准备再周到，期间肯定有无法预知的事情。如果遇到了，想办法解决它。万一搞不定，按计划开始后面的事情。这时一般会出现两种状况：
1 突然有天早上，you fix it。
2 系统迁移完成了，还是有解决不了的问题。没关系，跟产品或者运营说说具体情况，他们修改下需求，一切迎刃而解。当然，他们也会大发雷霆，并捅到了大老板那里，或许挨了批。nothing，大不了收拾东西回家，不行去搬砖，现在卖水果好像也不错。
当然，这只是体会而已，整个迁移还是很成功的。
第三次迁移
这次是从一个用php+python写的框架中迁移到一个叫yii的php框架。
因为部门重组，领导的风格有所变化。迁移到yii之后，会更容易hold这个系统，而对于进来的新人而言，学习成本也小，所以进行了迁移。
这次迁移很轻松，3人花了不到一个月的时间。主要原因有二：
1 迁移地不够彻底，仅仅是换了框架。如果有个牛人的话，写个转换程序，1个人不到2周就能搞定。
2 之前的框架，并没有传说中那么烂，如果你用熟悉了，或许相当好用。当然，不排除这个成本会很高。
对于框架，我没有深入的学习和研究，一直停留在使用的层次。所以只是介绍已知的那个用php+python写的php框架。
它包括了代码发布，一个基于vim的ide，单元测试，内置的服务管理工具。一般是将model封装成一个svc，供controller或者api调用。
有天晚上做了个梦。梦见liu同学辗转几个公司后，写了个框架a，在一个初创公司广泛使用。在那段时间，liu同学会一直给a框架补充一些功能，大家都用地很顺手，用a框架完成了公司的很多产品。过了两年，随着公司的不断壮大，liu同学的主要精力用在了自己负责的那几个项目上面，渐渐地不在为a框架补充新的特性。
负责另外一些项目的tang同学，组织了另外几个人，fork了a框架，对相关功能做了精简和更新，弄了个c框架。渐渐地，这个c框架在公司的其他部门使用了起来。
但这两个框架都没有什么使用文档。主要的开发者也一步步走向了管理岗位。还在使用这些框架的工程师们，对于a框架和c框架的了解，也在渐渐缺失。
后来有一天，来了个hu同学，他负责起了公司一个很重要的项目。
这是一个不经意间成长起来的项目，期间倒手了好几回。当然也是用c框架开发的，所以项目的光鲜外表下面，隐藏着一排排的雷。这让hu同学苦不堪言。
直到有一天，他痛下决心。召集能兵强将，使用用目前很流行的s框架，对项目进行了一次大迁移。
迁移期间，经历了不少的艰难险阻，但最终完成了。
科技，的确在改变生活，也想让人们活地更容易些。但是，在这个改变的过程中，总是有一些当时的科技也无能为力的地方。这个时候，就需要在其他方面做出一些改变，以满足或者适应我们的改变。
我们每天都在解决问题或者即将要解决问题，通过运用技术这个工具，有时可以帮忙我们更容易地解决问题。但是解决问题，并总是要解决技术。
最重要的是一种心态。那种想要解决问题的渴望和相信问题可以被解决的信念。
第一次迁移，从trs迁移到solr。
迁移时长：1.5-3月
投入人员：2-3人
前期是系统调研，框架搭建以及相关测试。相关工作是1个人用2周的时间完成的。
通过测试中的相关指标，如qps，关键词命中结果数，单次查询所花费的时间，热门关键词搜索结果比对等，确定了迁移的必要性：
1 用开源的solr替代收费的trs
2 保证迁移后的系统在检索质量和查询性能上，不亚于trs
3 新系统具备可扩展性。原来的trs是单台，性能以及出现问题，扩展成集群的话，费用太高。
做任何事情，都要有针对性。就像这次迁移，我们主要是要解决性能问题，同时为公司节约成本。通过对基于solr的系统的测试，发现可以实现这个目的，所以才决定去做。而不是一拍脑袋，说觉得solr很cool，所以我们要从trs迁移到solr。
我们应该做很cool的事情，但是这个做事要有前后顺序，因为我们做了什么事情，所以这件事情变地很cool。
技术，改变生活。应该让生活更容易，make life easier！
这让我想起的了unix编程艺术中的那句--过早优化是万恶之源。
贴近生活一些就是：没事不惹事，来事不怕事。
好久不写东西了，废话扯地有点多。
在确定可以做之后，又投入了2个人，在一个月之后，就已经完成了主体模块的迁移，并上线。剩下的1个半月，主要从与迁移剩下的不到10%的旧功能，和新功能的开发与接入，还有就是系统的优化以及文档的整理。
第二次迁移，将一个评论系统从.net迁到php。
这次迁移用了不到两个月的时间，参与的人员也不到2人（1.5人）
迁移的目的也很明确。
评论系统年久失修，没有专人维护。所以我们只能将其迁移到我们能hold住的php，以便满足业务需求。
迁移的过程大概这样：
1 确定了一个要使用的php框架，当时zend是一个不错的选择。
2 整理要迁移的功能，这个对照了旧的系统
3 迁移前台页面，实现后端功能。
因为我不是全程参与，所以详情不多说，主要说说相关体会：
任何迁移，都是有风险的。就算准备再周到，期间肯定有无法预知的事情。如果遇到了，想办法解决它。万一搞不定，按计划开始后面的事情。这时一般会出现两种状况：
1 突然有天早上，you fix it。
2 系统迁移完成了，还是有解决不了的问题。没关系，跟产品或者运营说说具体情况，他们修改下需求，一切迎刃而解。当然，他们也会大发雷霆，并捅到了大老板那里，或许挨了批。nothing，大不了收拾东西回家，不行去搬砖，现在卖水果好像也不错。
当然，这只是体会而已，整个迁移还是很成功的。
第三次迁移
这次是从一个用php+python写的框架中迁移到一个叫yii的php框架。
因为部门重组，领导的风格有所变化。迁移到yii之后，会更容易hold这个系统，而对于进来的新人而言，学习成本也小，所以进行了迁移。
这次迁移很轻松，3人花了不到一个月的时间。主要原因有二：
1 迁移地不够彻底，仅仅是换了框架。如果有个牛人的话，写个转换程序，1个人不到2周就能搞定。
2 之前的框架，并没有传说中那么烂，如果你用熟悉了，或许相当好用。当然，不排除这个成本会很高。
对于框架，我没有深入的学习和研究，一直停留在使用的层次。所以只是介绍已知的那个用php+python写的php框架。
它包括了代码发布，一个基于vim的ide，单元测试，内置的服务管理工具。一般是将model封装成一个svc，供controller或者api调用。
有天晚上做了个梦。梦见liu同学辗转几个公司后，写了个框架a，在一个初创公司广泛使用。在那段时间，liu同学会一直给a框架补充一些功能，大家都用地很顺手，用a框架完成了公司的很多产品。过了两年，随着公司的不断壮大，liu同学的主要精力用在了自己负责的那几个项目上面，渐渐地不在为a框架补充新的特性。
负责另外一些项目的tang同学，组织了另外几个人，fork了a框架，对相关功能做了精简和更新，弄了个c框架。渐渐地，这个c框架在公司的其他部门使用了起来。
但这两个框架都没有什么使用文档。主要的开发者也一步步走向了管理岗位。还在使用这些框架的工程师们，对于a框架和c框架的了解，也在渐渐缺失。
后来有一天，来了个hu同学，他负责起了公司一个很重要的项目。
这是一个不经意间成长起来的项目，期间倒手了好几回。当然也是用c框架开发的，所以项目的光鲜外表下面，隐藏着一排排的雷。这让hu同学苦不堪言。
直到有一天，他痛下决心。召集能兵强将，使用用目前很流行的s框架，对项目进行了一次大迁移。
迁移期间，经历了不少的艰难险阻，但最终完成了。
科技，的确在改变生活，也想让人们活地更容易些。但是，在这个改变的过程中，总是有一些当时的科技也无能为力的地方。这个时候，就需要在其他方面做出一些改变，以满足或者适应我们的改变。
我们每天都在解决问题或者即将要解决问题，通过运用技术这个工具，有时可以帮忙我们更容易地解决问题。但是解决问题，并总是要解决技术。
最重要的是一种心态。那种想要解决问题的渴望和相信问题可以被解决的信念。
还没人转发这篇日记
