日记：关于交互诊断软件开发任务的一些想法
今天上午科里和领导与华信公司讨论明年与工程项目相关的各项工作计划。 加上昨天科里对明年工作计划的讨论，以及本周早些时候单独与华信公司的交流，我已坚定近两年一直都没有下定的决心：退出交互诊断软件开发任务。
背景
我从2013年入职起，就一直在开发数值预报模式交互诊断桌面软件。历经十二五科技支撑项目（2012-2017年）和海洋工程一期（2018-2020年），累积开发已超过六年时间。 期间经历过二次代码重写和四次大版本变动，包括：
- Linux原型开发（2013年）
- Linux使用后台NCL批量绘图（2014年-2015年）
- Linux使用Qwt实时绘图（2016年）
- 移植到Windows使用Qwt实时绘图（2017年）
- Windows使用GIS实时绘图（2018年）
- Windows重写架构（2019年）
可以看到，几乎每年都会对整个软件进行大范围的改动，导致多年来一直在重复开发，在功能上没有形成良性的持续迭代。 所以这么多年来一直没能拿出一个能够推广应用的版本。
重新回顾下我从2013年到2019年的工作总结，可以发现很有意思的事情。 在2018年以前，我一直以交互诊断软件为我的核心工作任务，放在第一位介绍。而从2018年开始，诊断软件已基本放在总结的最后部分，不再作为核心任务。 其实，我应该在2018年就应该果断地退出这项任务，但新的工程项目给了我希望，让我错误地认为软件没有做出来是公司的问题，并让我在2019年初依然认为自己可以做出一定的成果。
但是，我其实早就应该意识到，因为自己的局限性，这项工作一定不会有拿得出手的成果。
局限
最大的问题在于我从事的其它工作与数值模式诊断没有一点儿联系，我一直以来都不清楚交互诊断工具该做成什么样子。 这显然与我没有深入了解和学习数值模式和诊断方法有关系。我们不能将自己局限在已了解的领域中，应该积极拥抱新的挑战。 不过，直面挑战不是一件很容易的事情，我从入职以来一直将自己限制在IT相关的领域，而没有花心思去了解业务，了解数值预报模式系统。
另一个问题在于我们缺乏一整套支持交互分析的完整工具包，包括数据平台、解码工具、绘图引擎等等。交互分析涉及到的每一个部分，都需要项目组自己去寻找解决方案。 这么多年来光是绘图引擎我们就尝试了三套完全不同的方案，大量的精力都浪费在交互软件与绘图引擎之间的匹配上。 另外，交互工具项目一直都强调同时具备实时绘图和批量绘图功能，但2018年之前我们一直使用NCL实现后台批量绘图，导致我们需要同时维护两种绘图和显示方案，给整个软件带来繁重的开发量。 尽管2019年我已经意识到这个问题，开始强调前后台使用同样的技术实现，但借助第三方公司来提供绘图引擎对我来说不是一个很好的选择。 明年会实现简化版本的后台批量绘图，但未来是否还需要沿着现有的技术路线前进，我个人持怀疑态度。
数据平台是构建数据分析软件的基础，尤其是我们需要在桌面电脑Windows中上运行交互工具，但数据却保存到HPC上。 今年我们将业务数据和部分实验数据保存到二级存储中，并将之前开发的数据平台部署到连接二级存储的Linux服务器中，接入业务系统输出的数据。 明年会对接数据平台，部分解决数据接入的问题。
但还是需要面对一个问题：我们是否需要Windows下的桌面软件？这也是最近几天讨论工作时，我与领导最大的分歧所在。
纷争
鉴于连续六年失败的开发经历，我认为开发桌面版的交互分析软件投入太大，以目前单人负责一个项目的组织方式，对于我来说难以实现。
我们有很多工程项目，做的事情往往都是一样的：管理数据，分析数据，制作产品，展示结果。正如我之前的博文提到，我们不同项目之间缺乏成果共享，导致严重的重复建设。 我个人对绘制气象图形不是很擅长，但交互分析软件就是要绘制出模式研发人员需要的图形，导致做出来的效果距离实际应用还有很大的差距。 而图形绘制仅仅是软件中的一个组件，其余诸如数据接入、交互分析、元数据管理等等也需要大量设计和开发工作。 每一块都需要开发，即便通过工程项目与公司合作，我也觉得力不从心。我本身的项目管理能力也是一个大问题。
我建议改变技术路线，抛去桌面交互分析工具的想法，开发基于绘图脚本的批量绘图工具和基于Web的显示工具，不再强调交互功能。 初始版本并不需要提供强大的定制和交互功能，满足研发人员的部分需求，能应用起来就可以了。 领导担心这样的思路与已应用的A工具没有区别，会让人觉得这样的工具能被A工具覆盖，不是我们科应该做的。 我也觉得领导的担心很有道理，上面的提议就是完全仿照A工具开发诊断工具，与直接放到A工具中没有任何区别。针对这点，我又提了下面的建议。
目前多个工程项目在开发基于WebGIS的产品展示工具，我建议利用其它工程项目的成果，开发基于Web的交互工具。 从公司角度看，懂Web的人才比懂C++/Qt的人才更多也更容易招到。气象中心除了Micaps外也开发了MOAP平台。 不能打包票说以后的模式数据分析都会基于Web技术在浏览器中进行，但我觉得应该是未来的趋势。 简单的分析操作完全可以由浏览器来实现，复杂的分析操作可以直接写代码实现。 即便真的需要桌面工具，诸如Electron的工具也可以将Web网站做成桌面软件。 这个技术路线同样会涉及到与其他科室的任务有重叠，所以和之前的建议一样，不被认可。
所以，最后我建议领导考虑让其他更懂模式诊断的同事接手这个项目。如果再由我负责，沿着现有的技术路线做下去，永远不会有结果。 领导说我们的试验工具做了15年，经历了几波人员变动，到现在终于有了可以应用的成果。只要坚持不懈的钻研，总能做出来。 但我已经做了6年，可以想一想还需要多长时间才能拿出来成果。
有一说一，我很佩服领导的工作态度，领导之所以成为领导，就是因为有我们所不具备的能力。
未来
讨论当然没有最终的结果。我会负责到明年海洋工程一期项目验收，后续的工作我会建议重新讨论并安排。
工程项目的事情很难说清楚，我相信包括我在内的很多同事都意识到现在项目执行所面临的一些问题，但想改变单位的工作惯例是一件很困难的事情。 办公室领导在年终总结时也提到明年会考虑工程项目的管理问题。 无论明年是否有所改变，我都期望后面的工程项目能考虑核心技术是否应该由我们的员工负责技术设计和开发，并在执行上考虑项目之间的成果共享。
从我所在的科的角度来讲，我希望我们能像信息中心学习，设计一套通用底层框架，支撑各种应用级别的工程项目。 应用项目所涉及的部分往往不是我们的日常工作，底层框架正是我们所擅长的。 想法是美好的，但现实会怎么样就不好说了。我们评价项目成果往往只会考虑单一个人，而不是某个团队的。
无论如何，我觉得未来我应该把精力投入到对提高工作效率有帮助的任务和自己感兴趣的任务中。
