排除某些字段的时刻——使其“瞬态”

我们都使用过数十种序列化框架——用于 JSON、XML、二进制和 ORM（它们是关系数据库的有效序列化框架）。并且总是有需要从对象中排除某些字段的时刻——使其“瞬态”。

到目前为止一切都很好，但随后出现了一个对象被同一个项目/运行时中的多个序列化框架使用的地步。不一定是这种情况，但让我先讨论两种选择：

• 对所有序列化使用相同的对象（API 的 JSON/XML，内部归档的二进制序列化，ORM/数据库）——如果序列化/持久化字段之间只有微小差异，则首选。使用同一个对象可以省去很多 DTO 之间繁琐的传输。
• 对不同的序列化使用不同的 DTO——当场景变得更加复杂并且使用相同的对象成为定制和异常的拼凑时，这将成为必需品

请注意，这两种策略可以存在于同一个项目中——有简单对象和复杂对象，而后者只能有多种 DTO。但是让我们讨论第一个选项。

如果每个序列化框架都有自己的“瞬态”注解，那么很容易调整一两个字段的序列化。更重要的是，它将具有可预测的行为。如果不是，那么即使对于一个字段在序列化目标之间的行为不同的类，您也可能被迫拥有单独的 DTO。

例如，前几天我有以下惊喜——我们使用 Java 二进制序列化 (ObjectOutputStream) 对大型集合进行一些内部缓冲，然后对对象进行索引。在应用程序的一个完全独立的部分中，同一类的对象使用与二进制序列化无关的附加属性进行索引，因此使用 Java 瞬态修饰符进行标记。事实证明，GSON 尊重“瞬态”修饰符，并且这些字段永远不会被索引。

总之，这篇文章有两点。第一个是 – 期望来自序列化框架的任何行为，并通过测试来验证不同的序列化场景。第二个是针对框架设计者的——不要重用来自语言本身或其他框架的瞬态修饰符/注释，这是违反直觉的。

系统日志。您可能已经听说过这一点，尤其是如果您从事监控或安全方面的工作。Syslog 被认为是系统可以将日志发送到其他系统的通用、统一的方式。Linux 支持 syslog，许多网络和安全设备都支持 syslog 作为共享日志的一种方式。另一方面，系统日志服务器正在接收所有系统日志消息。这在理论上听起来很棒——有一种简单、通用的方式来表示日志消息并跨系统发送它们。

现实不可能比这更进一步。Syslog 不是一回事——有多个“标准”，而且每个标准都经常被错误地实施。许多供应商都有自己的数据表示方式，而且都是一团糟。

首先，RFC。有两个 RFC—淘汰 3164 的新变体）。RFC3164 不是标准，而 RFC5424 是（大部分）。

https://www.douban.com/note/838613426/

这些 RFC 涉及系统日志消息的内容。然后是关于通过 TCP 传输系统日志消也不是标准，而是“观察”。Syslog 通常通过 UDP 传输，因此将其装入 TCP 需要一些额外的考虑。现在在其上添加 TLS。

https://www.xiaohongshu.com/discovery/item/6331d3f30000000017038123

Then there are content formats. RFC5424 defines a key-value structure, but RFC 3164 does not – everything after the syslog header is just a non-structured message string. So many custom formats exist. For example firewall vendors tend to define their own message formats. At least they are often documented (e.g.t parsing them requires a lot of custom knowledge about that vendor’s choices. Sometimes the documentation doesn’t fully reflect the reality, though.

除了供应商特定的格式，还行的 LEEF 等事实上的标准。它们定义了消息的结构并且实际上是独立于系统日志的（您可以将 CEF/LEEF 写入文件）。但是当 syslog 用于传输 CEF/LEEF 时，消息应该遵守 RFC3164。

https://m.douban.com/group/topic/275904703/

现在是“有趣”的部分——不正确的实现。许多供应商并不真正尊重这些文件。他们提出了自己的变体，即使是最简单的东西，比如 syslog 标头。日期格式无处不在，有时缺少主机，有时缺少优先级，使用非主机标识符代替主机，冒号被随意放置。

解析所有这些混乱是非常“hacky”的，大量的正则表达式试图解释所有供应商的怪癖。我正在开发一个 SIEM，我们的收集器是开源的——你可以查看我们一些特定于供应商的解析器仍然缺失，但我们不断添加新的解日期格式讲述了一个好故事。

文本编辑器和 IDE 重要吗？当然，它们是我们每天使用的主要工具之一，因此它应该非常、非常好（请提供更多关于小提琴手和网球运动员的隐喻）。但大多数文本编辑器和 IDE 都不错。他们不断发展，他们互相复制，他们吸引他们的观众。他们在不同的方面也很好，但大多数顶级的都实现了他们的目标（否则他们不会那么受欢迎）。当然，有人更喜欢以某种方式实现某个功能，或者要求具有另一个功能（例如，我要求在所有构造函数上都有调用层次结构，而 IDEA 没有给我，呃……）但这些东西在宏伟的计划。

类似的微不足道来自我们工作的结构，或者我们现在经常被称为“软件工程师”的原因——这与打字速度或用于创建代码的完美优化工具无关。我们的时间致力于思考、设计、阅读、命名事物。而且我们的代码编写/编辑/调试工具的质量不在推动生产力和质量的因素之列。

不过，我们绝对应该掌握我们的工具。创建软件需要的不仅仅是编辑文本。重构、高级搜索、高级代码导航、调试、热交换/热部署/保存时重新加载、版本控制集成——所有这些对于更好地完成工作都很重要。