软件开发被误解了，因为人们认为它是短期的创造，但是不明白：高质量却是将软件投入生产的最快方式。
高质量的代码使维护更容易并减少代码交互时间。低质量的代码会慢慢地产生更多的问题并减慢开发速度。
非开发人员和缺乏经验的开发人员没有着眼长远，也没有意识到质量在软件开发中的重要性。
这就是为什么低代码开发不会成为开发人员或代码的终结，因为作为软件开发人员不仅仅是编写代码。
软件开发被误解
有一点知识的人不理解甚至看不到软件开发的复杂性。没有经验的开发人员和非开发人员（管理层、客户等）无法理解许多最佳实践和流程。这是非专家不知道自己在做什么以及为什么要这样做的专业知识深度。
这被称为 Dunning-Kruger 效应，它解释了为什么知识太少是危险的，因为很少的知识会让你认为你理解了一些东西（满瓶不动半瓶摇）
你真的没那么聪明：邓宁-克鲁格效应
软件很有创意
一个主要的误解是软件开发是一个创造性的过程，以及为什么软件评估是错误的。事先不了解软件需求，软件开始开发以后才确定正确的软件版本。
这些有问题、错误的初稿版本最终也不会变得正确，创建复杂软件的事实是：它是一个涉及很多人的创造性过程。为什么软件开发时间中的最后 1% 比前 99% 一样长，因为我们通常不知道需要构建什么或需要什么样的技术解决方案。
Standish Group 的年度 CHAOS 报告显示，66% 的技术项目以部分或全部失败告终。然而几乎每个软件项目都预设这种失败不会发生在他们身上，这是因为软件开发被误解了。
软件开发的短期观点
软件开发是根据创建代码和软件的短期目标来衡量的。创建的代码和软件越快越好，故事点是用来衡量用户故事的创建。
如果你创建了错误的软件，你必须再做一次。
如果开发人员开发出质量低劣的软件，就会产生技术债务，从而使与代码的每次交互都变慢。
创建的任何错误都会降低整个团队的速度。你越迟发现bug，修复所需的时间就越长。
走捷径，错过质量步骤（例如测试，文档）感觉更快，但后来减慢了开发团队的速度。由于超出计划因此需要新增新员工，由此带来沟通成本，为什么向项目添加更多人并不会使其进展更快，但这些是普通人加速开发的首选方法。
软件开发中的捷径最终导致代码投放到生产之前会走很长一段路。
从长远来看，软件开发中的廉价选择成本更高，因为技能较低的开发人员需要更长的时间并且他们的工作质量较低。你以更便宜的价格获得的短期收益后来证明是对项目的昂贵扩展。
没有经验的开发人员专注于创建代码，专家专注于创建易于维护的代码，因为维护代码最耗时。
代码的创建
创建代码后，代码的质量会影响与其交互的时间。创建软件是开始而不是结束，代码的维护将越来越受到关注。
与代码交互意味着什么：
- 可读性——当开发人员阅读并理解代码时
- 用途 - 调用代码，例如类、方法、函数
- Debug — 读取和调试代码
- 测试 - 对代码进行单元测试
- 改变——由于错误或需求而改变代码的工作方式
- 扩展 - 向代码添加更多功能
复杂的代码/低质量的代码会减慢使用它的开发人员的速度。
最佳实践不直观
软件开发中有最佳实践，但它们并不直观，遵循它们的好处是创建更简单的代码，易于维护。
最佳实践和建议侧重于质量，这会减慢创建速度但使维护更容易。大多数参与软件开发的人都专注于短期。
SOLID原则
- 单责任原则：“从来就应该是因为一个原因改变一个类。”
- 开闭原则：“软件实体…应该对扩展开放，但是对修改关闭。”
- 里氏替换原则：“函数在使用指针或引用基类必须能够使用派生类的对象而不自知”。
- 接口分离原则：“很多个与客户端相关的特定接口好于一个通用的接口。”
- 依赖倒置原则：“依赖于抽象，而不是具体实现。”
KISS（保持简单愚蠢）——每一行代码都必须被理解和维护。更少的代码行减少了开销。
TDD（测试驱动开发）——它迫使开发人员预先编写测试。他们不会错过这一步，并且代码是为快乐、悲伤和异常路径而设计的。它应该帮助开发人员编写易于测试、更易于理解的代码。目标是精心设计、高质量代码并确保创建单元测试。
DRY（不要重复自己）——不要创建相同或相似的方法。更少的代码更容易维护，例如，如果您必须更改方法，如果没有重复，就做一次。
软件开发原则专注于创建简单、高质量的代码，但大多数开发人员不会停下来思考这些背后的目的。
软件是一场失败的游戏
软件开发是失败者的游戏说更快的开发是通过质量而不是速度或生产力实现的。错误和问题会减慢多个开发人员（和非开发人员）的速度。
在开发过程中发现的错误越多，修复所需的时间就越长，对项目的影响就越大。
开发过程中的质量步骤尽可能靠近开发环境查找和修复问题/错误。解决技术债务的最佳时间是在您创建它之前。
创建高质量代码从开发投放到生产的速度更快。低质量代码的创建速度更快，但会减慢所有开发人员和项目的速度。
被误解
创建质量的步骤以及这些步骤对非开发人员来说并不明显，因为他们不考虑维护代码并与代码交互。
软件项目只要关注和衡量软件的创建即可，非开发人员认为这是最重要的方面。伟大的代码不会拯救你，但糟糕的代码会杀了你