构建软件

(1)过早优化是万恶之源。不要低估这个说法。

(2) 您很少需要从头开始构建某些东西。几乎每个用例都有库和依赖项。所以握住你的键盘，不要重新发明轮子。

(3) 了解问题的范围是您在找到解决方案之前需要做的第一步。我们错过了第一步而直接跳入解决方案是很常见的。

(4) 不要太完美主义者。首先，让它工作，然后让它干净。软件交付始终具有最高优先级。

(5) 糟糕的程序员担心代码。优秀的程序员担心数据结构及其关系。- 莱纳斯·托瓦兹

(6) 使用代码注释来解释你为什么要做某事，而不是你在做什么。不要过度描述并在代码注释中开始写小说。

(7) 拥有有意义的错误日志可以节省大量调试问题的时间。在错误消息中提供所有相关信息，而不是仅仅说“函数 X 中发生错误！”。并且永远不要记录任何敏感或个人信息。

(8) 100% 行/分支覆盖率并不意味着您的代码没有错误。编写测试以涵盖所有功能需求，而不是涵盖行/分支。

(9) 如果你正在修复一个bug，写一个相应的测试用例，这样以后就不会发生了。错误的发生通常是由于错误假设，为所有这些错误假设编写测试用例将使应用程序更加健壮。

(10) 当有人阅读你的代码时，他们不应该需要记住超过 7 件事来理解它。嗯，因为在我们的短期记忆中，我们的大脑一次不能保存超过 7 件东西。这也是许多代码 linter 在函数中警告超过 7 个参数的原因之一。

(11) 不要仅仅因为有人要求你做某事就以特定的方式做某事，明白为什么，如果你不相信，那就挑战现状。

(12) 解决问题是每个工程师应该真正擅长的最重要的技能。您的组织存在很多问题。开始解决它们，不是所有的都能解决，甚至20%都解决不了。但是在尝试解决的过程中，您会学到很多东西。

设计系统

(13) 最好的系统设计通常是最简单的。保持简单愚蠢！(KISS)

(14) 设计模式和最佳实践并不是适用于任何地方的魔法药水。优秀的工程师知道最佳实践，但高级工程师知道何时打破最佳实践。

(15) 理解抽象。代码中不必要的复杂性通常是由于抽象不佳而引入的。

(16) 一个系统的强弱取决于它的最弱点。聚焦瓶颈。

(17) 离主要源头的步骤越多，一切都变得越腐败。尽量减少中间步骤，这适用于技术和非技术环境。

(18) 没有完美的解决方案，只有权衡。列出优点和缺点，以及做出正确权衡的要求。

(19) 您在项目中引入的每项技术都伴随着风险。衡量风险并制定减轻风险的计划。不要在没有救生衣的情况下跳入大海。

(20) 避免过早的抽象。解决您现在遇到的问题，仅此而已。当您看到类似的问题出现并且您看到一种模式出现时，那么您应该考虑围绕它构建抽象。

(21) “构建软件设计有两种方法：一种方法是简单到没有明显缺陷，另一种方法是复杂到没有明显缺陷。第一种方法是困难得多。简单很难。” - 托尼·霍尔。

(22) 不要太偏向于语言或框架，如果你喜欢某种语言，就不要一直崇拜它，不要开始到处使用它。如果你讨厌它，也不要一直抱怨它。每种语言或框架都是为特定用例设计的。作为工程师，您的工作是为用例选择正确的工具。

(23) 如果当你弄清楚某些东西是如何工作的时候，你已经忘记了为什么部分，那么代码中有很多不必要的抽象和复杂性需要清理。

(24) 复杂性一旦累积，就很难消除。不要认为您当前的更改引入的一点点复杂性没什么大不了的。如果每个开发人员都遵循相同的方法，那么复杂性会呈指数级累积。

(25) 如果您决定重写组件/服务，请务必重新考虑您的决定。阅读代码比编写代码更难，这就是为什么“我应该重写它！” 在软件开发中很常见。

(26) 不要犹豫挑战你的高级工程师或架构师提出的设计，有时你的设计会更好。提出有效的令人信服的观点并客观地进行比较。只是不要因为过于自信的混蛋而把这带到极端。

(27) 大多数情况下，静态类型语言比动态类型语言要好，尽管静态类型系统会带来开销。这就解释了为什么 TypeScript 是最受欢迎的语言之一。

其他提示

(28) 优化您的代码以提高可理解性。无聊冗长的 20 行代码总是比巧妙编写的单行代码要好。

(29) 新手与他们编写的代码建立情感联系是很常见的。但在敏捷环境中，需求和代码不断变化。习惯于修改和删除旧代码。

(30) 为任何问题想出不止一种解决方案。试图找到多种解决方案会迫使您以不同的方式思考，一旦您有了不同的解决方案，您就可以通过选择正确的权衡来做出决定。

(31) 你处理的模块越多，你获得的领域知识就越多。您拥有的领域知识越多，您需要加入的会议就越多。您加入的会议越多，您编写的代码就越少。通过记录和共享领域知识来打破链条，这样您就不是唯一的联系点。我知道说比实施它容易。

(32) 当你被某个问题困在某个问题上很长时间没有任何进展时，重新表述这个问题或向某人解释这个问题，这在大多数情况下都很有效。为什么你认为rubber duck调试如此受欢迎。

(33) 您不需要了解整个代码库才可以开始处理它。了解架构和生命周期，并开始使用您的模块。不要浪费你的时间去试图理解每个类。

(34) 代码是负债而不是资产。您拥有的代码越多，就越需要阅读、理解、测试和维护。最好的代码是没有代码。

(35) 了解如何在 StackOverflow 上发布问题。您很少需要发布问题，但这是一项有用的技能，当您在文档和用户有限的库/框架上工作时，它会派上用场。

(36) 如果您在其他模块中偶然发现您没有处理的问题或错误，请通知相应的开发人员，或在 scrum 中提及。请不要说：我不对其他模块负责。

(37) 您编写的函数应该具有零/最小的副作用。这使得该功能可以轻松且独立地进行测试。

(38) 看在上帝的份上，请不要编写自己的日期格式/解析函数。每种编程语言都有许多流行的日期库，只需使用它们即可。日期和时区比您想象的要复杂得多。

安全

(39) 每个开发人员都应该知道如何编写安全代码。编写具有糟糕设计/抽象的代码是可以的，但编写具有安全漏洞的代码绝对不行。阅读OWASP Top 10文档以开始使用。

(40) 当您想快速格式化或验证某些 JSON/XML/YAML 数据时，不要使用在线格式化程序或验证程序。特别是如果您正在处理一些机密的生产数据，则对任何在线工具都是严格禁止的。请改用任何本地编辑器或命令行工具。不要冒险将您公司的数据泄露到某个随机站点。（推荐工具：CyberChef - 下载离线使用）

(41) 永远，永远不要在你的代码库中推送任何敏感信息。在提交和推送之前，请务必仔细检查您的代码是否包含电子邮件地址、电话号码、密码、身份验证令牌、私钥等。

(42) 始终验证和清理用户输入。永远不要假设或期望用户会以正确的格式发送某些输入。并且在验证时总是更喜欢白名单而不是黑名单。

拉取请求

(43) 猜猜看！您还可以在拉取请求评论中给予赞美。我们在复习的时候总是专注于不好的部分，小小的赞赏可以给你的同行带来微笑。下次试试。

(44) 将阅读拉取请求和理解其他开发人员的评论作为日常实践，以获得对功能和编码标准的不同观点。

(45) 代码格式和其他标准应该自动化。使用代码格式化程序和 linter 构建您的项目开发管道，以便整个代码库保持一致和干净。请停止在公关评论中争论标签与空格的问题！

(46) 创建简短的拉取请求。如果您正在处理多个功能，请将它们分成多个 PR。并且给审稿人足够的审稿时间，不要在部署前一小时创建PR。