模块重构中遇到的分歧

    在重构和代码迁移的工作中，团队内部分歧比较大。是产出较为完善的规范后开始逐个模块重构还是边重构边完善呢？
    其实重构工作很早就已经确定，产品运行3年没有技术方面的考虑，人员换了一拨又一拨，没有积累。我觉得目标无外乎三个。
        第一：重新梳理产品线业务层技术开发遇到的问题，并以问题驱动产出规范和架构
        第二：在规范和架构基础上，实现代码迁移，组件化是团队整体开发风格统一
        第三：补充必要的文档
    从这个目的出发，迁移工作分为在初期至少需要梳理出目前遇到的问题，并在架构层面抽象出解决方案和后续的开发规范。团队中的两种意见都有些极端。
    第一种是将规范做到完美，然后拓展，这显然不现实，重构的工作必须有阶段性的产出，否则漫无尽头的工作很容易被时间淹没，同时也不利于后续工作的开展。
    第二种，我理解是没有思考全面重构的整体思路，走一步看一步，对于这一点，我并不能相信重构工作能够解决当前问题，与其不能解决不如理清楚再做。
    由此在会上提出几个问题：
        1. 当前团队遇到的技术问题都有哪些，问题暴露是否清晰？
        2. 对于问题是否进行深度的思考和总结，是执行层面不到位还是规范缺失，还是架构问题？
     这两个问题在团队后续的讨论中没有结论，这经印证了团队在开展工作时并没有深入的了解现状，有一些潜在现象联想到我们需要重构，这就导致后续在做整体规划时无从下手的情况。
    这件事对于我后续的工作也敲响了警钟，在决定一件事的时候多问问自己几个问题。先说到这里，留个尾巴。。。。