提高代码改造过程的小想法
最近几天一直在思考一个这样的问题，怎么样才能让制造工作快速高效的完成，并尽可能减少bug的存在。初始想法是源于自己的这次失败，并不简单的是失误。一大片的进度延迟是谁也不想看到的，但也不是任何人都能在规定的时间能完成，这和个人的经验以及熟悉程度相关。其中必然有某种关联，我能想到的有下面几个方面：
1、进度上
进度上的超前安排是必须的，毕竟一个项目有其规定的纳期，只有为各种难于预测的障碍提供足够的时间缓冲才能保证时间上的可行性。同样，在纳期内的合理调度也是我目前难以把握的，因此这一方面我无法提出合理的建议。
不过我倒是有一个大胆的提议，那就是由APP的实施者自己提供最迟的完成时间，综合各方面的可能性提出的自我完成时间，想必是比较合理的，因为只有自己最清楚自己可能在哪里花费更多的时间。当给出一个压缩过的时间之后再由实施者自己提供的时间必然也是压缩过的，但这是必要的，因为他会感觉到压力的存在，并在可接受的压力范围内作出调整。
来自外界的压缩过的时间，特别是感觉到难以实现时，会让人不自觉的产生一种来自心理上的抵触。可能表现的并不明显，但不可否认这是存在的。而自己给出的时间尽管也是压缩过的，但因为是自己的预估，这种压力更多的体现在尽力完成上。
上面的想法好像过于放松，毕竟这是理想状态下的，难以顾全到大局，可行性也不曾得到验证，只能作为一种参考。可行性分析还要靠各位把握、分析的结果请告知，以便我了解自己的想法和事实的差距。
2、管理上
我们提倡轻松愉快的工作环境，这个环境的造就和维护就靠各位管理人员。诚然，自由的工作环境更能培养出具有创造性的思维，这是项目中不可多得的机会。融洽的相处和定期的一对一交流更能把握好这个节奏。
一对一的交流会让人有一种不曾被忽视的感觉，这对于员工的存在感有很大帮助。当一个人有强烈的存在感时会有更强烈的自信的表现，尽管可能我对此并不熟悉，甚至错误百出，但这丝毫不影响其热情。
而项目的进展和个人的发展显然是最好的聊天话题。不要认为小兵就不关心项目，每个人都对自己的工作存在一种特殊的情感，这种情感在被得知对整个大局具有一定的完善和推动作用时表现的尤为突出，这将形成一个自信心的良性循环。而个人的发展更是每个人都关心的重要方向（不排除有人不关心），目标管理也是一个很好的载体，但毕竟没有面对面交流来的真切。帮助员工分析其期望的发展以及可以提供的机会更容易拉近彼此的距离，产生师生活朋友般的交流效果。越是有经验的leader越能把握好这个度，不然很可能经过一席谈话，“送”走一位您想挽留的人。
公司的发展方向决定了部门的发展趋势，部门的发展趋势决定了部门内部员工的发展，当二者出现重大冲突的时候谎言显然是出不可取的，因为这降低的将不仅仅是对公司的认可，更可能是对管理者的抵触。个人的发展是多方面的，也是多途径的，或与与其最终的结果不同，但方向可能并无太大偏差。而如果丝毫没有相同之处的话也需要给予充分的指点，我想这是作为一个领导者的职责。
而管理上的具体的实施，恐怕也只能是我的一种猜想，毕竟我不是管理者，虽然我期望早日成为。和进度上的安排的认识一样，不论这样的认知是否可行，还请给予指正，毕竟这也是管理者的职责之一：关注每一个员工的思想动态。
3、自己
员工个人的做法才能真正决定项目的进度，毕竟通常情况下管理者是负责协调，而不是实施。员工的个人行为可能决定了项目组的环境，当然这一切还是可控制的。
终于说到自己更为熟悉的部分了。我先说一下我自己的做法，再说自己的拙见。
（1）、拿到式样书时
最初拿到式样书的是我我习惯性的会通篇看一下，以判断工作量的大小。个人感觉工作量的大小并不取决于代码行的多少，更多的是依赖于业务的复杂性，上百行的赋值和比较并不比十数行的check复杂。个人感觉上是：通常情况下的单纯的删除操作时最为简单的、其次是单纯的功能增加或完善（例如添加CSV输出或者在其中增加几行界面上以存在数据）、业务的修改和完善则相比会更复杂一些（即便只是增加不多的功能也需要尽可能的完整了解此业务）、新规的部分则由业务的复杂度、明确程度、使用范围来决定其工作量大小
（2）、式样理解
也就是业务轴review，很容易被忽略的一个环节，同时也很难把握，能把过程说的很清楚明白的并不多，除非是在完成此本APP之后。不同经验的SL把握的情况也不尽相同，时间和经验的限制致使我们无法充分进行此部分的review。个人感觉大的方面可以把握为：逻辑上的变化、画面上的变化、数据的变化。
逻辑上的变化一般来说是比较少的，如果有的话想必就是一本比较大且复杂的了。如果是逻辑上的变化，那么此本APP还是建议全部理解为妙，不然仓促下手会造成极大的返工，理解的细致程度还由个人把握，建议的标准时能画出数据流图。
画面上的变化一般是显示内容的增删改，增和删只要小心一些一般不会造成太大失误，而修改的话可能会带来界面布局和部分空间属性的变化，稍加注意也不会有太大问题。
数据的变化主要关注一下修正部分的数据以及PL/SQL文是否变更即可。
（3）、是否存在技术上的难点
上面的式样理解是抛开了技术问题的。毕竟这是强制性的变化，式样理解和实现是有一定的差距的，技术上的难点也是相对于陌生的操作和可能出现的逻辑性代码。此时不见得能或需要解决，只是做到心中有数，以决定后续需要花费多少时间来解决。
（4）、代码制造
删除项目是比较简单的，在确保没有其他变更的情况下注释掉实现此功能的代码，并解决由此产生的错误。我们可以直接注释是因为强大的开发工具会进行自检，需要注意的是：是否有其他操作（数据库访问、文件输出）使用到删除的数据，并确保已经按照式样书处理。
增加功能则不太好描述了，视增加的内容不同而不同。简单的增加数据项和check处理则相对简单一些，只需要按照式样书的要求进行，一般不会出现过于严重的bug。业务上的添加可能就相对复杂，不过上面已经画过数据流图了，了解数据的走向之后应该会变得轻松一些。
关于这一部分是很难把握的。因为技术上的难点和理解上的误区在此变得无处遁形，他可能是你原地踏步或者兜圈子。技术上的难点在明白需要知道真正该问的是什么之后倒也不是太难解决，如果是理解上的误区可能会花费更多的时间，虽然我们提倡不会就要问，但是很多时间也会出现不知道该问什么的情况。
制造期间的任何不曾被注意到的问题都可能成为一个巨大的问题，因为他阻碍了程序的正常运行。于是这一阶段会比预期看上去漫长和进展缓慢的多。我很赞成为每一个曾经出现的出人意料的问题建立一个资料库，以便其他人遇到同类问题时能迅速解决，不过问题的种类是那样的繁多，完善的问题库可能像MSDN一样庞大，而且需要花费的时间也非我们能够承受。我们只好慢慢成为“见过类似问题、做过类似问题”的经验者。
这一阶段就是成为经验者的必经之路，小心谨慎、遭遇问题、试图解决、寻求帮助。看起来很简单，做起来真头疼。
（5）、自己review
这一部分的重要性也是不言自明的。合理的安排是：自己测试同制造有相同的时间，不过这点事很难做到的。我们总是盲目相信自己的成果物，以至于绝大部分的问题都是别人发现的，不容易产生遗漏的做法是：复制出来一本式样书，一点一点的对应下去，并改变对应过的背景颜色，就像测试一样，不过相对简陋的多，这样至少保证不会出现显而易见的错误。这样可能会出现很多测试不到的地方，毕竟你并没有对式样进行深入的分析，只要这个点不是变更内容，十有八九是可以无视的，新规制造不在此列。
（6）、差分
这真的是一个不错的办法，除了花费一定的时间，但是这对于小小的错误是很好的自检办法。毕竟你我都不希望仅仅因为一个被忽略的小错误而多出一张障碍票。
似乎没有足够的时间很难保证质量地完成上面的一系列操作，这点我也赞同。只是这个很必要，也会在之后减少不必要的返工。
End Sub
回看上面所言，似乎有些笼统，但是这个对我来说真的很难表述清楚，或者说要表述清楚的话需要重写几本类似于《需求分析》、《可行性分析》、《Thinking in Java》的书了。目前没有如此想法，各位都是从开发者中来，希望以上所言能起到抛砖引玉的作用，我们都想把项目做好，虽然我们的能力着实有限。若是各位老大能够总结某些经验并实施，相信会有好的作用的。
