我对refactoring的思考

        今天有点小时间，想随便写个工作总结。希望能对各位同仁有所帮助。

         最近完成了两件工作，而且都是refactoring的概念。

         像关于什么是refactoring，有许多的Refactoring的定义，但是基本上讲的就是同一件事情。Refactoring是使用各种手段重新整理一个对象设计的过程，目的是为了让设计更加灵活并且/或者更可重用。也就是使软件更易适合将来需求的变化，更易维护性。Refactor是一种软件重构行为，像增加软件的功能，改变原来软件的结构等可以定义为refactoring。对应refactoring可以说仁者见仁，智者见智。我认为作为软件工程师，我们不要较真什么是refactoring，什么是XP。我们的主要工作是，用我们的智慧和前人总结的经验去解决问题。

       到今天为止，我一共进行过三中类型的refactoring，这只是我个人的分类。

       第一类型，重构者既熟悉业务，也熟悉源代码，可以就是源代码的作者进行软件重构。这一类型是最快，最有效率，更易维护的。如果条件允许的话，我推荐这一种类型的软件重构，特节约成本。但是由于IT员工流动大，所以这种类型越来越少。因为这类重构避免了许多问题，所以难忘的经验很少。经验的片面理解也就是，在某个问题跌倒或吃过苦头，这时总结的经验才是经验。

       第二类型，重构者不熟悉业务，不熟悉源代码，资料不全。这是最糟糕的重构工作，如果一位软件工程师没有做过这类的软件重构，你对refactoring的理解就不会透彻。

       下面我要总结的ipws的审批流程移植到itep2.0架构上的重构可以说就属于这一类型。

       参加重构人员三人，张元元，胡胡和张涛涛。

       我们对审批流程的概念是那一种业务不熟悉，代码也不熟悉的移植。虽然这项工作最终完成了，可是它给我们的教训也是深刻。由此引发对项目配置管理的讨论。

       审批流程的移植工作也可以说是一个痛苦的浪漫的旅程。它从深层次放映了我们的对文件的管理经验的欠缺。

       看看我们的重构历程：

       1． ITEP2.0 beta在我们的应用中测试前进，缝缝补补

       2． 数据库是从ipws_oa复制的

       3． Class一部分是oa

       4． 审批流程的源代码：张元元从尹刚林处得到的

       5． JSP是从oa_ipws得到的蓝本

       6． 调试过程中，我发现短信和手机短信与oa紧密联系，想拿过来直接用都不easy。没办法我忍痛割爱，kill 这个function。

       7． 调试过程中，发现JSP与源代码不是一致的，又从韩智那拿到源代码。

       8． 解决了一个问题，又发现一个问题。恼人的源代码，令人眼花缭乱的JSP。

       9． 可爱的datum package，有时候也不温柔了。

       10．              。。。。

       11．              整合（统一服务器，统一数据库，统一界面）�D�D美妙的苦酒。

 

       像蚂蚁一样sting to climb with desire，真的有点受不了了。

 

       这项工作虽然使人发晕，但是学习到的经验却是我以前及以后不能比的。我相信我以后是不绝不可能去做像这次那么浪漫的工作了。

       在refactoring切记：

1. 在refactoring之前，项目组成员必须要熟悉业务流程。如果这一步都不了解，就不要开始去动源代码。如果报着无所谓的态度，那到时候你将会面临一个悲惨世界。像审批流程我们可以请韩智做业务流程和业务逻辑的培训。Itep部分请黄云云做培训。在开始之前，如果我们做了这两项工作，我们将不会那么的痛苦。
2. 接下来我们要得到我们开始工作的所需资料和源代码。我们痛苦的地方是，我们三个人用了不同版本的审批流程和数据库。给后期带来了，整合和N多Bug的痛苦。
3. 第三步，要对项目组成员的工作进行分工。这次分工不是具体的分工，而是对每个成员的工作范围有一个大概的概念。然后每个成员都会有目标，有侧重点的工作。在后期都熟悉业务和功能后在进行具体详细的分工。不可以，每个成员什么都做，结果就是什么都做不好，导致项目延期。
4. 在一个项目中必须加强沟通，多开会，应该坚持两天一个碰头会议，最好每天项目成员都要进行十分钟的经验分享。这样我们每个成员都可以少走弯路。
5. 在refactoring过程中，每个成员要求每天记录在refactoring过程中的详细工作，这样做可以经验share。
6. 特别是资源很紧张的情况下，refactoring的前期工作更需要detail，detail。 

       第三种类型的重构就是重构者熟悉业务，不熟悉源代码。这种类型的重构相对比第二种类型轻松点，但是于第一种类型相比还不是如鱼得水的事情。特别是源代码已经被N多人修改的情况。

这次是为东深项目而重构小ipws的计划进度部分。在原来计划进度的一个单位的情况下，增加双单位的处理。属于增加新功能。

        由于是一个人完成，所以就减少了沟通等成本。

        有了审批流程的移植的重构的经验后，我在处理这次重构工作时节约很多时间。

        首先我要求张亮亮把东深项目的双单位需求发给我，然后我们对其中的疑问进行一遍一遍的资询和确认，我提倡不耻下问，会为重构过程解压N多痛苦。

        接下来张亮亮和我又把数据结构确定下来，这个环节也很重要。说是说重要，可是在实际工作种有些项目经理总是说，小问题无所谓以后在定。就是那以后在定，那后来吃尽苦头的可是我们这些设计和编码同志。

        第三步张亮亮和我又确定了双单位计划进度的界面，那么现在可以编码了吗？不行，最好对我们的需求，设计，界面，每个模块都联系起来在考虑一下，看一下有没有遗漏的地方。因为我们在软件开发种总是有这种情况出现，到后期编码时，那个早先的需求和架构设计已经意义不大了，对我们意义最大的是我们的详细设计。我不知道别人是怎么认为的，我认为后期的详细的设计在几个设计环节中最重要，它可以发现架构设计和需求的不合理部分，可以减少软件测试的成本。实际上，在我们的好多项目中所谓的架构设计到项目编码阶段与废纸差不多。