最佳实践与经验分享

构建软件：*过早优化是万恶之源。不要低估这个说法。* 您很少需要从头开始构建某些东西。几乎每个用例都有库和依赖项。所以握住你的键盘，不要重新发明轮子。

Slack是一种可以把各种碎片化的企业沟通和协作集中到一起（类似钉钉）：多年来，我们始终牢记的一件事是为出色的开发人员体验而设计。虽然我们可以在幕后更改我们功能的实现，但删除或更改现有 API 的行为契约是非常困难的。这就是为什么从一开始就仔细考虑您的 API 设计很重要。 

Spring Framework 及其顶层实现 Spring Boot 和 Spring MVC 是 Java 世界中最常用的框架。它被使用得越多，随着时间的推移就会出现越多的不好和好的做法。 Spring DI：构造注入优先于 Field 和 Setter

本文是世界最大问答社区Stack Overflow和 Discourse 的联合创始人的文章：2004 年，当我第一次阅读

需要一万小时编程才可能是世界级专家：在任何技能上获得世界级专业知识的关键在很大程度上取决于以正确的方式练习，总共大约 10,000 小时 ——Malcolm Gladwell in Outliers好吧，我当然不是世界级的专家，但我已经将 10,000 小时的刻

本文列举了一些可以应用于软件开发的最流行的规则和原则。对于每条定律，我们将快速讨论其主要命题，然后探讨如何将其应用于软件开发。 帕累托原则（80/20 规则）帕累托原则指出，通常80% 的结果来自 20% 的原因。数字 80 和 20

重构这个词语refactoring的德文定义：

自世纪之交以来，金融科技行业呈指数级增长，支付欺诈的威胁同样与之相匹配。随着在线信用卡交易和无线支付在世界范围内越来越受欢迎和需求，新的金融科技企业出现了。然而，在这个竞争激烈的市场中，那些缺乏严格安全标准的企业会吸引恶意行为者。金融科技开发商不断面临为客户提供价值的压力，但他们也需

微服务似乎是完美的解决方案。从理论上讲，它们可以提高开发速度，同时允许您独立扩展应用程序的不同部分。但实际上，微服务带有隐藏的成本。也就是说，我认为如果不亲自构建它们，您就无法真正理解它们的复杂性。这是我使用微服务构建（有时失败）的经验。 管理

现在相信的事情： 当您和不同经验水平的团队合作时，使用类型语言会更好（不是动态语言） 敏捷的站立会议实际上对于新手很有用。 Sprint 刺有自己的存在价值，前提是只要他们是实际路线修正（即“神圣的狗屎，那又不好！”），而不是一些神可怕的“敏捷”

有相当多的人在进行系统建模，不少人认为自己是系统思想家，但相当随意地使用建模等技术。即使有可用的建模工具，我也经常走直观建模的捷径，随着时间的推移，这让我在犯善意的推理错误方面受到了很大的教育。George Lakoff 的《

电子商务企业正在使用微服务为其商店构建一组可重用的组件。这些服务通过独立于前端运行，可以更轻松地将您的内容大规模交付到多个渠道。在这篇文章中，我将讨论您可以实现的几种设计模式并解释它们提供的功能。我还将讨论常见的用例。 理解软件设计模式

本文介绍了一组用于管理应用程序依赖项的最佳实践，包括漏洞监控、工件验证以及减少依赖项足迹并使其可重现的步骤。这些实践中的每一个的具体情况可能会因您的语言生态系统和您使用的工具的具体情况而异，但一般原则适用。 版本锁定简而言之，

《Effective Java》一书的大部分内容都是聚焦构建一个干净、易懂的 API 以及它如何成为一个伟大库的基础。类的 API 的一部分是任何异常，它可能会抛出已检查（它成为签名的一部分）或未检查的堆栈。作为代码的编写者，我们有责任确保此 API 不会出现任何意外或令人震惊的情况。发生这

在本文中，将分享PagerDuty如何通过很少的新软件开发和一些简单的流程更改来启动的API 开发。API 契约本质上是一成不变的，添加、更改或迭代它们通常既麻烦又困难。API 更改过程本身可能会令人沮丧和缓慢，并且错误可能会造成极高的代价。但随着产品功能的增长，其 API 也应该增

代码应该以不言自明、易于理解、易于修改或扩展新功能的方式编写。因为代码被阅读的比写的多，这就是为什么如此强调干净的代码。我们的源代码更具可读性： 越容易维护 新开发人员理解实现所需的时间更少 越容易发现哪些代码可以重用 在这篇博文中，我将分享