将旧数据转换为 json 格式
我正在处理一些遗留代码，其中我使用列值及其早期历史记录来进行一些比较并突出显示差异。然而，该列以任意分隔方式存储，并且围绕比较的代码非常难以理解。
我最初的想法是重构代码 - 但当我后来思考时，我想为什么不修复问题的原始来源，即本例中的数据。我对表结构有一些限制，因此不能将其从单列转换为多列数据。
有了这个，我想是否值得将这种任意分隔数据转换为像 json 这样的标准化格式。我的方法是将这些数据导出到某个文件并应用一些正则表达式并将这些数据转换为 json 格式，然后重新导入回来。
我想与这个小组核实我是否以正确的方式解决这个问题，以及是否还有其他我应该考虑的想法。 JSON 首先是正确的格式吗？我想知道您是如何解决类似问题的。谢谢！
I am working with some legacy code where I am using a column value and its earlier history to make some comparisons and highlight the differences. However, the column is stored in an arbitary delimited fashion and the code around comparison is well, very hard to understand.
My initial thought was to refactor the code - but when I later thought about it, I thought why not fix the original source of the issue which is the data in this case. I have some limitations around the table structure and hence converting this from a single column into multiple column data is not an option.
With that, I thought if its worth to convert this arbitary delimited data into a standardized format like json. My approach would be to export this data to some file and apply some regular expressions and convert this data to json format and then re-import it back.
I wanted to check with this group if I am approaching this problem the right way and if there are other ideas that I should consider. Is JSON the right format in the first place? I'd like to know how you approached a similar problem. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所以看来问题在于添加或修改功能的代码的可维护性/可演化性。
我的意见是：为什么？我认为你最初的想法是对的。您应该重构（即“......重组现有的代码体，改变其内部结构而不改变其外部行为”）以获得您想要的东西。如果您更改数据格式，则在任何情况下都可能会在新的更酷的数据格式之上以混乱的代码结束。
换句话说，您可以拥有所有组合，因为它们并不严格相关：您可以拥有很酷的数据格式，但带有混乱的代码或美妙的代码，也可以拥有丑陋的数据格式，带有美妙的代码或混乱的代码。
看来您处于最后一种情况，但从这种情况转移到：酷数据格式 + 混乱的代码，然后到酷数据格式 + 精彩的代码，比：精彩的代码 + 丑陋的数据格式，然后酷的数据格式 + 精彩的代码更不简单（选修的）。
所以我的观点是以一种简单的方式指出你的目标：
1）为当前功能编写测试（如果你没有）并使用当前代码验证它们（重构的第一步）
2）更改由所编写的测试驱动的代码1
3）如果您仍然想要，请更改测试所指导的数据格式
问候
So it seems the problem is in the maintainability/evolvability of the code for adding or modifying functionalities.
My opinion is: why? I think your initial thought was right. You should refactor (i.e. " ...restructuring an existing body of code, altering its internal structure without changing its external behavior") to gain what you want. If you change the data format you could end with a messy code above the new cooler data format in any case.
In others words you can have all the combinations because they are not strictly related: you can have a cool data format with a messy cody or with a fantastic code, and you can have a ugly data format with a fantastic code or a messy code.
It seems you are in the last case but moving from this case to: cool data format + messy code and then to cool data format + fantastic code is less straightforward than: fantastic code + ugly data format and then cool data format + fantastic code (optional).
So my opinion is point your goal in a straightforward way:
1) write tests (if you haven't) for the current functionalities and verify them with the current code (first step for refactoring)
2) change the code driven by the tests wrote in 1
3) If you still want, change the data format ever guided by your tests
Regards