我正在尝试开发一种全新的多任务软件。该软件将具有多个组件，它们将/可以相互通信以使系统正常工作。在将此软件发布给最终用户之前，我们将进行多轮验证以确保良好的质量。在验证周期中，我们的开发人员将主要依靠收集的日志来排除故障并诊断问题。由于我们的调试功能和上市时间将严重依赖于收集的跟踪，因此我们希望尽可能多地获得开发人员可用的信息。另一方面，如果我们添加大量的跟踪，它将减慢我们的软件速度，并可以吃掉许多宝贵的资源，如CPU周期等。我们希望保持跟踪/记录最佳。为了解决这个问题，我们希望为我们的开发人员明智地使用不同的日志级别提供指导，例如：调试，信息，警告，错误等。这里没有调试中的跟踪＆gt;信息＆gt;警告＆gt;错误。我们希望使用say＆＃34; info＆＃34;开始我们的软件验证周期。水平并逐渐进入＆＃34;警告＆＃34;和＆＃34;错误＆＃34;随着软件的成熟。开发人员倾向于尽可能多地追踪他们可以获得的所有信息。但是，由于我们将使用多组件系统，跟踪总数变得非常高且无法管理导致大日志大小，s / w性能问题等。我们希望给出一个通用指导，就像你有100个日志/跟踪一样组件然后说100应该在调试中可用，70应该在Info中可用，g＆＃34;，10应该是错误的等等。这样我们就可以获得良好的跟踪质量以及我们对总日志的控制/跟踪大小。我们应该使用哪些指导/标准？
答案 0 :(得分：0)
标准做法是在运行时使日志记录级别可配置。这是通过使用日志框架（如winston for javascript）或slf4j实现java来完成的。
鉴于此，我会让开发人员自己研究调试和调试的数量。跟踪他们需要的信息。当需要记录错误时，通常也很清楚。因此，我们唯一的指导/讨论是在信息级别应记录多少信息。我会让开发人员使用他们最好的判断和然后根据需要进行调整，并提供一般指导，即处理错误或数据转储的堆栈跟踪应仅在调试或跟踪级别完成。
部署系统时，日志级别应设置为info或更高。如果在已部署的系统上出现问题，则可以临时增加日志记录级别以进行调试（或可能更高）以允许调查问题。
开发人员可以使用调试或跟踪日志级别作为默认值运行开发系统。
在验证周期中，您可以根据需要打开调试日志以捕获信息。