本周我读到的最佳科技文章 - #3

我通过我的新闻邮件 in.snippets() 分享我每周都会阅读的软件工程文章的 TL;DR 版本 。在此注册 即可在您的邮箱中接收这些文章。

#工程 #思维方式

具有产品意识的软件工程师

作为一门新兴学科，我们投入了大量时间研究‘如何’构建软件，这在学校仍然是重点。但一旦打下基础，就需要开发者积极思考‘为什么’。工程师需要渴望运用技术解决人类/用户问题。他们拥有同理心，能够追求非凡的体验。在我看来，这就是产品工程师的定义。糟糕的产品工程师会偷工减料，但优秀的产品工程师知道，在构建阶段，最低限度的可爱产品需要充分考虑其深度。

-Shopify 首席技术官 Jean-Michel Lemieux

文章分享了具有产品意识的软件工程师的 9 个关键特质，以及软件工程师可以做 6 件事来建立产品思维：

1. 了解你的公司如何以及为何成功
2. 与产品经理建立牢固的关系
3. 参与用户研究、客户支持和其他活动，您可以了解有关产品工作原理的更多信息
4. 提出有充分依据的产品建议
5. 为你从事的项目提供产品/工程权衡
6. 向产品经理寻求频繁的反馈。

恕我直言，采用这种思维方式可以帮助所有工程师更深入地了解我们正在开发的产品，进而帮助我们成为制造更好产品的更好的工程师。

阅读需8分钟

#架构 #基础

软件架构的5个关键原则

帮助软件架构师做出有效决策的 5 个软件架构原则：

1. SOLID 原则
a) 单一职责原则：
每个系统功能（例如服务/模块/API）应该只有一个职责

b) 开放封闭原则：
最好扩展系统行为，而不是修改它。

c) 里氏替换原则：
给定两个具有相同契约的分布式组件，其中一个组件应该可以被另一个具有相同契约的组件替换，而不会改变系统的正确性。

d）接口隔离原则：
接口/契约必须尽可能细粒度且特定于客户端

e) 依赖倒置原则：
高级模块不应该依赖于低级模块；它们都应该依赖于抽象。

2. 最小惊讶原则：利用用户已有的知识，最大限度地缩短用户使用模块时的学习曲线

3. 最省力原则：每个人都倾向于选择尽可能轻松的路径。因此，制定正确的架构和预期，才能取得良好的开端。

4. 机会成本原则：选择的机会成本是指我们为了获得该选择而放弃的东西。为了做出好的经济决策，我们希望选择对我们收益最大、成本最低的选项。

5. 最后责任时刻原则：不要过早做出决定，而是推迟承诺，并将重要且不可逆转的决定保留到不做决定的成本大于做决定的成本为止。

阅读需7分钟

#python #生产力

Dropbox 对 400 万行 Python 代码进行类型检查的历程

这篇文章详细分享了 Dropbox 团队将代码迁移到静态类型检查背后的原因；团队在此过程中面临的挑战以及他们如何应对这些挑战；他们在内部采用的各种方法；以及它对团队生产力的影响。以下是一些促使团队全力以赴的优势：

• 类型检查器发现了许多细微（和不那么细微）的错误
• 重构更容易
• 类型检查提供快速反馈并允许更快地迭代。
• 无需编写脆弱、难以维护的单元测试来模拟和修补世界以获得快速反馈。
• PyCharm 和 Visual Studio Code 等 IDE 和编辑器利用类型注释来提供代码完成、突出显示错误并支持更好的转到定义功能

这是研究 Python 静态类型检查对于大型项目的实用性的一个很好的案例研究。

阅读需20分钟

#编程 #文化

结对编程 vs. 代码审查：开发者文化对比

这篇文章是 Paul Hinze 六年前写的，当时他换了工作，从结对编程的开发文化过渡到同行代码评审的开发文化。他分享了对这两种实践的平衡看法。

通过结对编程，团队中的每个人都能通过持续的沟通共同进步。初级开发人员可以通过经验丰富的结对编程轻松获得培训；最佳实践、知识、新工具和技术会在团队中自然而快速地传播。然而，结对编程并非总是充满阳光和彩虹。它可能会导致核心人才的过度稀释，从而扼杀生产力和士气。当涉及到解决系统设计和架构等需要更多深度思考或创造力的更大问题时，结对编程可能会阻碍团队的进步。

在遵循代码审查实践的团队中，团队会感受到一种激励压力，促使他们在审查中表现出色。深入思考问题时没有任何障碍。由于代码审查是异步的，因此工作时间安排非常灵活。代码审查可以策略性地分配，以确保经验丰富的开发人员始终参与特定类型的代码审查，从而提供额外的质量控制，并防止生产环境中出现错误。然而，在采用代码审查流程的团队中，你可能会感到孤独，长时间心不在焉，并且无法按时完成任务。如果代码审查的节奏不够紧凑，它们可能会成为瓶颈。

阅读需10分钟

#解决问题 #学习

程序员的纪律

Sidu Ponnapa 的大部分职业生涯都致力于拓展科技的“人性化”层面。在过去的四年里，他帮助 GojekTech 从 100 万 GMV 成长到 100 亿 GMV。在这篇文章中，Sidu 阐述了团队领导和决策者如何运用程序员的学科知识，构建并扩展高效的组织。编程本身就很困难。程序员在构建难题的解决方案时，面临着编程固有的挑战——模糊性、复杂性、集成性和悖论。为了降低问题的难度，程序员将问题分解为“系统”，并通过“学科”定义如何与这些系统互动。许多学科知识在处理业务扩展过程中固有的问题时都非常适合。由于所有优秀的程序员都拥有设计、构建和运行大型复杂系统的经验，因此在开发非技术系统时，他们是极佳的参考。

阅读需8分钟

附言：我分享了我们Appsmith团队本周阅读的最佳技术文章列表。

你可以在这里和这里找到最后两本。很想听听大家的反馈，也想知道你们在读什么？