念的细节与实施之初

raselbd223

这些 有一天 常常会变成 永远不会 或者当它们最终到来时事实证明概提出的细节不同。在我看来一个好的程序员不应该想 我希望我在这里实现了更多的设计模式。 我们应该专注于使用简单务实的解决方案来解决实际问题。 ł 避免额外的手术是很好的做法。代码应该只包含必要的内容。创建过于复杂的机制并认为它们可能有用是毫无意义的。如果我们不知道某件事是否有用那么它很可能没有用并且我们会在上面花费不必要的时间。然而如果在工作过程中我们注意到需要或模式表明额外的机制或功能会很有用那么就应该添加它。

重构和代码维护是软件开发的一个自然过程 我们不要试图一次完成所有事情。 四．该代码旨在满 电子邮件数据 足特定的业务目标 ł项目应该有一个逻辑结构 划分为与其业务目的一致的模块。这将使工作更容易。此时值得一提的是 领域驱动设计方法它涉及到在项目结构中反映业务现实。 罗伯特在我们的代码中我们应该使用从业务中听到的名称和概念。如果我们听到 被转换为策略 那么在我们的代码中我们应该找到 类它将具有 方法。上述原则也与领域驱动设计 的基本假设之一即唯一语言有关。 我们创建的代码旨在满足生产环境中的特定业务目标。



我们需要能够监控应用程序的工作方式 我们记录有关应用程序中发生的操作或流程的哪些信息？此类日志是否包含敏感数据？应用程序中是否存在意外错误？如果有是否正确处理？我们应该记住发布我们可以监控的指标。多亏了这一点我们才能更快地发现发生了不好的事情。我们有机会在事情完全恶化之前做出反应。