Jym好😘，我是珑墨，今天给大家分享关于不良编程实践的一些想法，嘎嘎的😍，看下面。
随着时间的流逝，我发现开发人员似乎为了学习新事物而学习新事物，而不是在现有方法上做得更好。编程就像其他一切一样------新的并不总是更好的。
如果我试着问 100 个程序员以下问题，他们中很少有人（如果有的话）可以在没有网络搜索的情况下回答这个问题：
Bob 刚从编程学校毕业，听说过 MVC，但不确定如何判断哪些代码应该建模，哪些代码应该查看，哪些代码应该被控制。你会如何向 Bob 解释 MVC 代码的划分？
1. 为什么开发人员在REST中决定创建POST并更新put？
HTTP RFC 一直声明 PUT 是创建或更新到服务器上的资源，以便该资源上的 GET 返回 PUT 的内容，并且 POST 基本上是不适合其他动词的任何内容的抓包。RFC 过去说 POST URL 表示操作，现在他们只是说 POST 就是你所说的任何内容。
开发人员经常谈论 POST 和 PUT 的 REST 用法，就像上天自己决定了这种用法一样，就像没有争论一样，我擦。我从未见过任何合法的理由，为什么不能像 RFC 所说的那样创建或更新 PUT，而 POST 可以用于非 CRUD 的东西。任何由客户对功能的需求驱动的真实、复杂的系统都极有可能具有一些非 CRUD 的操作------与其他系统的集成、计算、搜索（例如，在你键入时显示匹配项的过滤器框、根据输入字段查找搜索结果）等等。
通过为这些类型的其他操作保留 POST，你可以立即识别任何不是 CRUD 的内容。否则，你最终会得到 POST 的两种用法------主要用于创建，但在这里和那里用于其他东西。
2. 为什么 Java 开发人员毫无疑问地坚持每个 Java 项目都使用 Spring 和 JPA？
可以说，一个微服务项目应该是微观的。Micro 被定义为一个形容词，意思是极小。当 Spring 和 JPA 占用超过 200MB 的内存并需要 10 秒钟来启动一个几乎为空的项目时，该项目几乎不会将一行写入表，我在这里没有看到微观。
说我疯了，但也许微观应该应用于整个方法，而不仅仅是行数：内存量、手写代码量、新员工理解代码工作原理所需的时间等。你不必对此感到怪胎，尝试 10 种语言，看看哪种语言使用的 RAM 最少，只要合理即可。
Spring 和 JPA 是为单体开发而设计的，在单体开发中，你可能会遇到如下问题：
- 构造函数在代码中被引用 100 次。添加新字段需要修改所有 100 个构造函数调用以提供新字段，但其中只有一个调用实际使用新字段。所以依赖注入是有用的。
- 有数千个表，数以万计的查询，需要在多个数据库（例如，Oracle和MSSQL）中支持，以及多租户和/或分片等用例。在某种程度上，用其他方式做一些事情实在是太过分了，而 JPA 非常有帮助。
3. 为什么每个 Web 应用程序都需要大量的 JS 代码？
当我刚开始干web时，我们使用 JSP（Java Server Pages），一种 SSR（服务器端渲染）。基本上，一个 HTML 模板系统，可以用通常来自数据库的值填充插槽。这意味着当用户点击一个按钮时，整个页面都会重新加载，现在的速度足够快，只需短暂的眨眼。
老的银行软件仍然使用某种SSR。作为客户，我不在乎它有点眨眼。每次点击后，它都会在大约一秒钟内做出响应，在注销之前，我只会在会话中加载 12 页。我在网上找不到任何关于它的投诉。。。
我看到了一个从 JSP 到 Angular 的项目"升级"。他们有很多未注释的 JSP 代码，没有人真正知道它是如何工作的，这些代码变成了 Angular 代码，没有人真正知道它是如何工作的（可能屎山代码的效应）。有些人会向 Angular 添加新的业务逻辑，有些人会将其添加到 Java 代码中，而领导该项目的人认为对此做出决定是个好主意。
从来没有人解释过为什么这次升级有什么好处，或者它会做什么。之后添加的新功能并不比以前复杂或更复杂，因此继续使用 JSP 不会造成任何问题。这似乎是为了升级而升级。
4. 为什么所有新方法都会自动比旧方法好得多？
10 或 15 年前使用的工具有什么问题？毕竟，其他一切都是这样运作的。当然，我们现在有带触摸屏的汽车，但它们仍然使用汽油、轮胎、布或真皮座椅、方向盘、玻璃等。你每天驾驶时接触的零件与几十年前基本相同，只有触摸屏和电动发动机等少数例外。
为什么我们不能只使用一种简单的方法来将 SQL 表映射到对象，比如代码生成器？为什么我们仍然不能将 HTML 模板系统用于主要是 CRUD 的业务线应用程序？为什么我们不能使用仅对手头系统所需的复杂方法？我还没有看到任何在实际使用中明显更好的新语言或工具的真正改进，除了使用容器等少数例外。
5. 你认为其他行业也是这样运作的吗？
我现在可以告诉你，如果工程师像程序员那样构建东西，我迟早躺板板。如果医生以这种方式工作，我每次就诊都会非常害怕。那么，我们为什么要这样做呢？这真的是我们能做的最好的吗？
我和一个在被录用后不久就问过的人一起工作，"为什么我们有一个单声道存储库？当我问 monorepo 有什么问题时，他无法给出任何答案，但说服了管理层如何改变这一点，显然他满怀热情地相信所有微服务项目都必须构建为每个服务的单独存储库。不确定是他还是其他人，但不知何故确定每个项目都必须部署在自己的容器中。这些决定在以下方面对项目有害：
-
一个项目是定义要通过网络发送的所有对象。如果将服务 A 对象更新为需要新字段，则不会在任何地方出现编译错误来显示需要更新构造函数调用。如果服务 B 调用 A 来创建对象，而没有人想到这一点，那么可能只有服务 A 被更新以提供新的必填字段，并且存在一个微妙的难以找到的 bug，这可能需要一段时间才能让任何人注意到。
-
你的普通企业开发箱可以处理 15 个容器，然后翻倒并喘着粗气。因此，我们很快就以一种无法挽回的方式失去了本地开发，团队永远无法将其恢复。
-
每个新开发人员都必须检查数十个存储库。
-
在任何地方都没有跟踪存储库之间的依赖关系信息，因此无法知道必须运行哪个服务子集才能使服务 X 在该服务上工作。再加上无法在本地运行所有存储库，在服务 X 上工作产生了两个同样糟糕的解决方案：
- 通过反复试验来找出哪个子集支持 X 并在本地运行它
- 将每个代码更改部署到开发服务器
当谈到程序员使用他所描述的那种非常复杂的解决方案时，在我看来，这听起来像是开发人员，他们基本上对一切新的和酷的东西都感到抽搐。这在这个行业很常见，每个团队都有这样的人。这本身并不一定是一个大问题，但是当与无法/不愿意确保其他开发人员完全有能力维护系统，以及可能"我说的一切都是最好的"和/或"只有我才能维护这个系统"的傲慢相结合时，这就是弊大于利的杀手组合。