NWPC笔记：GRAPES GFS v3.0后处理系统升级进行中
没想到 GRAPES GFS v3.0 的升级会与 GRAPES MESO v5.0 业务切换交织在一起，导致最近几天疲于应付后处理系统建设任务，耽误了部分写作时间。
GRAPES MESO v5.0 后处理系统已在去年进行完全重构，并在今年 5 月份完成平行试验系统的搭建。 最近将 00 和 12 时次的产品切换由冷启动数据驱动，在 nwpc-oper/nwpc-data-client 项目的支持下，仅需要增加配置文件，并少量修改脚本就可以实现。 当然，如果想要保持足够的灵活性，还需要增加新的机制，已在《NWPC笔记：为GRAPES_MESO v5.0后处理增加冷启动数据支持》中介绍。
而今天刚进行测试，并将于后天进行业务化评审的 GRAPES GFS v3.0，就不是一样的剧本。 GRAPES GFS 后处理系统属于历史遗留代码。 自接手以来的两年中，我仅重构了数据产品任务的脚本，对整体结构和大量的绘图任务脚本都没做彻底的改动。 源自 GRAPES MESO 后处理系统的建设经验也没有应用到该系统中。 如果我保留目前的系统结构，那么只需要修改接入数据的地址，使用 nwpc-oper/nwpc-data-client 项目获取模式输出地址即可。 但我想对整个后处理系统进行全面重构，使用与 GRAPES MESO v5.0 后处理系统一样的结构。 这正是最近几天忙碌的原因。
借鉴已有系统的经验，重构 GRAPES GFS 后处理系统更像是一种重复劳动，按照同样的标准逐个修改任务脚本即可。 不过，有两个问题仍然值得我深思：
- 到底应不应该重构历史遗留代码
- 系统建设能带来什么
对待历史遗留代码
到底需不需要重构历史遗留代码？
这是一个很值得思考的问题。为了保持代码的生命力，需要持续更新代码。 不过，任何工作都需要投入时间，在时间有限的情况下，就需要有所权衡。
从代码重构中可能获得些许编程经验，但我确实不知道获得的经验是否值得时间上的投入。 曾看到有文章不建议按照编码规范重构现有代码，认为与其浪费时间优化代码结构，不如多学点儿其它的东西。 当我接手 GRAPES GFS 后处理系统时，我也是这样想的。 升级切换只需要修改接入的数据，其余部分几乎不用改变。
不过，当去年我想要增加新的模块时，发现实在无法在原有系统结构中修改，就重构了数据处理部分。 今年升级并没有增加新模块，似乎不需要进行大范围的修改。 经过一番思考，我还是决定参照最新的后处理系统结构重写 GRAPES GFS 后处理系统。
我认为，如果预计代码会由自己长时间维护，为了提高后续工作的效率，很有必要对历史代码进行重构，持续提高整个系统的灵活性，以便能快速响应后续多变的需求。 在系统足够灵活的情况下，后处理系统的升级切换就可能成为一件很容易的工作。
我也不确定持续修改系统代码是不是浪费时间。 但既然已经开始执行，就应该思考下如何做才能让时间花得更有意义。 这就引出第二个问题。
从系统建设中能获得什么经验
最近写了一篇个人工作业务考核材料，侧重工作的成果。 发现很难将从参加工作以来参与的系统建设任务写入到该材料中。 因为我仅仅是使用已有的工作流软件，编写系统结构脚本和任务运行脚本，没有能让人耳目一新的成果。
这说明我只是机械地构建业务系统，没有在现有构建系统的方式上再抽象总结出相关的科学技术问题。 业务系统建设往往只是一个工程问题，在某种规范下编写系统结构脚本和任务运行脚本，每年所作的业务升级切换更像是一种重复劳动。 而模式研发则更侧重科学问题，比如应用一种新的算法解决某个问题，提高了模式的性能。 想要从系统建设中获得经验，就必须要将工程问题上升到科学问题，从重复劳动中寻找通用概念和方法。
在这一方面，我做得远远不够。仅仅有一些模糊的概念，没有形成完成的思路。 代码重构仅仅是基础中的基础，如果想要在这一领域上更加深入，还有更多的东西值得挖掘。
如何选择
从部门现有的经验看，系统建设很难诞生有影响力的成果，却是部门必须要做的一项任务。 但系统建设并不是我唯一的工作，所以如何选择侧重点一直是我头疼的地方。
如果做出的成果仅在部门内部或者甚至仅在个人范围内才会应用，那么成果的影响力就会大打折扣。 与其将时间投入到受众面太窄的系统建设任务中，还不如将更多时间投入到研发支撑、数据处理等用户更广泛的任务中。 业务系统运维也是同样的道理。
可能这些想法都源自我对系统建设钻研的不够深入，不过我还是需要认真思考下在系统建设方面的下一步工作方向。
工作任务总是会完成，区别在于完成的方式不同，投入的精力也不同。
