技术债务

恰逢马斯克收购推特之际，马斯克表示将公开推特的算法，最近推特新增又删除了一个名为“算法”却无代码的GitHub存储库，一些人认为这是在与马斯克开玩笑，更专业的观点如下：一些 Reddit 用户将此视为一条神秘信息，认为推特Twitter其实根本没有算法；而其他人则认为 Twitter

你们中的大多数人都熟悉加入一家新公司的感觉，并有那种重写一切的冲动。看到你的新团队成员几年前犯下的亵渎神明的行为，让你的眼睛很痛。当然，你知道的更多，你会在开发该功能时遵循最佳实践。对吗？ 可能是吧。但多年来，我了解到，"最佳实践 "的问题在于它们

本文作者曾经发布《我想离开Golang先生的狂野之旅》，该文反复出现在Reddit、Lobs

亮点：微服务并不能确保良好的模块化：如果您使用微服务足够多，您可能会构建或借用一些不错的工具来简化服务之间的通信。但是，如果你不小心，你最终会得到一个紧密耦合的微服务式单体，每个函数都有大量的 HTTP 调用和要处理的版本控制。 在 Web 软件架

编写大量的测试。这怎么可能是坏事呢？ 但随着时间的推移，我从另一个角度看待它。我认为它是一个非常有限的工具，有非常具体的用例。它不适合我所建立的项目类型，而且经常阻碍它应该促进的流动过程。 在TDD其中，

这是Steinar H. Gunderson离开MYSQL团队感想，据调查很多程序员离职是因为技术债务，他也不例外，离开是因为对代码质量感到沮丧，他认为：MySQL 是一个漂亮的糟糕的数据库，您应该强烈考虑改用 Postgres。详细点击标题 

我们将讨论为什么编写更多可读的代码，而不是简明（短）的代码。之后，以下是关于如何做到这一点的策略： 变量、类和函数的命名 辅助函数 代码注释 枚举/字典/密封类/等等。 包的组织和命名 <

编写可维护的代码很容易。只需保持方法和参数列表简短，名称和注释较长，并遵循样式指南。正如一位著名记者曾经写道：“对于每一个复杂的问题，都有一个清晰、简单和错误的答案。”使代码难以维护的不是样式和形状。这是在缺乏明确的如何代码工作，它代表什么以及为什么它以这种方式被写？

坏代码时有发生——但你不需要成为坏人来打败它。从更轻松的角度来看，糟糕的坏代码还会产生充足的就业机会： 需要许多优秀的开发人员修复错误的代码。 需要一两个高级开发人员审查代码并确保它不会再次变坏。 可能需要不时地咨询糟糕的程序员（写出混乱的逻辑的明星）

许多团队也将考虑“最佳实践”的一些软件工程实践，下面是一些建议： 1、文档与代码在同一个 repo 中的内部文件最重要的特点是信任：人们是否相信文件既存在又是最新的？

这个 Java 代码库工具将帮助您识别应该首先重构的上帝类，也就是意大利面条的“大泥球”类，代码很长都混沌编织在一起的类，这

在软件工程方面，我们的愿景是让 BBC 以其工程和内容而闻名。为此，我们必须进一步发展 BBC 作为产品和技术公司的理念。我们的资产中有数百个微服务，所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作之间取得平衡。我们希望 BBC 以其

这里有一些我相信的关于软件工程的令人不安的事实！（banq：令人焦虑？） ... 具有特殊语法的复杂 DSL 可能是死胡同。Ruby 和 Scala 都非常重视这一点，但都没有让它流行起来。 如果没有其他因素，静态类型语言比动态类型语言更适合大型项目。对此没有

很久以前，在我的第一份软件工作中，我收到了一份关于一个内部产品的错误报告，我甚至不知道这个产品的存在。 结果发现这是一个应用程序，基本上提供了公司内任何员工可能需要的所有表格。基本上是一个万能的资源。你需要向人力资源部门报告某人吗？这里有一个表格。

财务和技术债务现在在很大程度上是众所周知的概念，它们在组织中发挥着极其重要的作用。但是存在第三种债务，可能比它的任何一种债务都更有害，任何希望在 21 世纪建立可持续组织的人都需要了解它。去年，创业大师