在2017年3月左右，我被要求对产品进行代码审查，然后再发布。 该公司存在内存泄漏，自发崩溃，加载缓慢，CPU消耗高峰以及计划在数周内发布的问题。 您可能已经听说过这个故事-不是来自我，也不是关于这家公司的。 她出奇的典型。
周末我们聚在一起，开始一起看代码。 大约半天后，发现了已知问题的来源，又花了半天的时间为开发人员编写了一份修复文档。 发行是成功的，但是这个故事让我思考：产品如何达到这种状态。
当我与开发人员交谈时，他们似乎很聪明。 唯一明显的问题是缺乏经验。 我以前遇到过。 这是一种常见且很正常的现象。 但是在这种情况下，发现了一个令人毛骨悚然的缺陷：对于
所有开发人员来说，经验是不够的。
最近创建了一个开发部门，并且在没有技术总监的情况下雇用了一个团队。 甚至技术人员也很难测试另一个程序员-我什至无法想象没有技术知识的测试。 他们雇用了第一个开发人员，他检查了第二个开发人员，依此类推，直到组建了一个团队。
如果您很幸运，并且第一个开发人员具有丰富的经验并且渴望培训，那么您就是女士。 但是，如果您不走运-而且发生这种情况的机会很高-那么您将拥有一支快速发展的团队，该团队创建非常脆弱的软件。
他们说：“迅速采取行动，破坏一切。” 但是，如果企业依赖少数大客户，这将是一个非常糟糕的主意。 损坏的产品通常会将它们吓跑，这反过来会打击您的业务。 您可以用不同的方式描述有效的策略，但是“缓慢而稳定地朝目标迈进”这一短语显然并不令人印象深刻。
实际上，快慢之间是平衡的。 很难找到这种平衡，因为每种产品都有自己的平衡。 我认为直觉是基于经验的，这对于初学者来说是一个糟糕的答案。
对新开发者怎么办？
在互联网上寻找答案似乎很自然。 事实证明，它
非常有效 。
但这也是
非常危险的 。
产品发布后，我与该公司合作。 我浏览了大量代码，帮助培训了开发人员并为他们创建了新项目。 一切顺利。
一旦我的注意力被一段代码吸引了。 我可能发誓我以前见过他。 当然，通过搜索该行，我在一篇博客文章中找到了该代码的精确副本。 自然，我会阅读整篇文章，直到以下段落：
“请勿在生产中进行此操作 。
”但是这些行直接从生产中的代码库看着我。
从相似的文章中找到许多代码并不需要很长时间。 几乎到处都写有免责声明，否则显然不够。 他们所有人都解决了一小部分问题，但是允许很多自由来使代码更易于阅读。 这可以理解。 大多数读者在学习一个概念时都会很简洁。
这些博客条目中的代码以感染的形式传播到整个代码库中，从而在任何地方或任何地方引起问题，而没有任何原因或模式。 除了连续读取所有代码并逐个手动修复问题之外，没有其他明显的解决方法。 没有单元测试和自动部署，花了
将近一年的时间 。 我很确定修复代码的成本超过了编写代码的成本。
但是这些开发人员有什么选择？ 他们需要发布一些东西，而他们从未发布过生产中的应用程序。 因此，他们做了任何理智的人都会尝试做的事情-并一路吸取教训。
生产系统以多种方式失效。 没有这些故障的经验或理论知识，很难直观地理解如何预防或解决此类问题。 要求一个新的团队来取得完美的结果非常困难，尤其是在没有某种领导能力的情况下。
在继续之前，我想指出，每个陷入混乱的人都有良好的意愿。 开发人员想要创建一个好的产品并进行开发。 经理们想要同样的事情。 博客作者希望分享有用的解决方案。 每个人都试图互相帮助，记住这一点很重要。
问题不在于人。我非常同情这个职位的开发人员。 他们拥有比所需更多的信息，但信息却完全杂乱无章。 这类似于尝试组装十块拼图，您只需要在10,000,000件的堆中找到它们，所有的块都是方形的，最终结果是未知的。 祝你好运
如果您在这里阅读并希望得到答案，那么对不起：我没有一个简单的答案。 这个问题很难解决。 解决方案对于一篇文章来说太大了，它每天都在变化，并且每个项目的细微差别都不同。
这个问题促使我开始写博客。 我很幸运地向有才能的导师，作家和同事学习了近二十年。 没有这些人的建议，我仍然会在QBasic（brrr）中编写
GOTO指令。 是时候接球了，继续进攻了。
总结一下。
该博客致力于开发现成的应用程序的各个方面：从基础结构自动化到测试，设计，调试，文档，开发过程和安全性。 每篇文章都是独立的，适合在现实世界
中使用 -
适用于生产 。