一种特殊的软件设计模式

对于具有数年经验的程序员而言，始终了解一些软件设计模式。 例如Singleton，Prototype，Facade，Decorator等。太好了，我们有太多种方法可以解决我们业务应用程序代码中出现的许多巨大问题。 这些可能会大量涉及代码级方法。 如果您尚未真正解决问题，那么这类软件设计模式将很难处理。 我将介绍另一种易于学习和使用的方法。

我认为，软件行业中的所有事物都可以称为“设计模式”，如果可以减少重复性工作，则这是另一种技巧。 因此，除了标准设计模式外，许多公司都有自己的设计模式。 也许他们还有另一种说法。 这个概念并不重要，关键是否在于是否有用。

一段时间以来，我发现某些方法非常有用且重要。

1. 完成需求分析后，需要生产一些文档和UI原型以交付给程序员。 无论处理您的项目时间很短，还是使用敏捷开发，您都始终需要生产这些类型的文档。 但是文档并不需要太大或高质量。
   
2. 写下尚未理解的问题清单，并尽快予以澄清。 您可以对它已经一一澄清的问题发表评论。 很明显，您还没有完成。 这也有助于您理解业务需求的整个框架。
   
3. 程序员需要提供一个文档，描述如何使用某些软件技术来实现那些业务需求。 它用于调用详细设计。 但这是由程序员自己产生的，不需要其他人查看。如果没有足够的时间，则无需编写更多细节，而是需要覆盖所有可能仅使用几个单词进行注释的功能。 该文档可能记录了业务需求的所有变更。
   因此，您可以在深入了解某些代码实现后经常查看此文档。 以我的经验，很多程序员需要花费更多的时间来回忆这些事情，并且其中许多可能在编码后会丢失某些功能，或者他们四处奔走以获取那些原来缺少的功能。
   
4. 写作单元测试。 需要编写有意义的参数，这些参数将帮助您快速调试功能。 您仅看到Green Bar可以知道您的所有功能。 经过很长一段时间后，如果要测试功能以解决问题，只需更改几个参数即可。 单元测试代码是长官代码，是另一种提高性能的文档。
   
5. 尽可能写日志。 是的，太多的日志输出会影响程序的性能，因此您避免将所有内容写入日志，尤其是整个xml文件或使用toString（）来打印所有POJO变量或大量参数。 我们可以使用一些个性化的迷你描述内容来代替。
   
6. 记住一些IDE的快捷键。 在这个高速发展的世界中，在您的IDE中进行深入研究可能是胡说八道，没人知道您的枪什么时候会被这个世界抛弃，什么时候会出现。 因此，我们最好控制20％的关键技能，这些技能可以解决80％的实际问题。 但是请记住，一些捷径对您的工作成果来说是一笔大投资。
   
7. 关闭一些不需要的计算机硬件功能。 例如touchPad，某些计算机的touchPad难以控制，如果您不小心触摸它，焦点将改变到一个未知的地方，但是在编码时这些事情总是发生，您需要重复编辑该东西。

这些特殊的软件设计模式太简单了，但对我们的行动非常有用。 随着经验的增加，我们将找到一些可以重用的方法，以减少重复性工作，这些方法可能只适合您或您的公司，或者适合所有软件行业。 总结那些可以减少工作量的事情也是一种设计模式。

From: https://bytes.com/topic/software-development/insights/969192-special-sort-software-design-pattern