随笔分类 - Google软件工程
摘要：大多数工程师维护、使用文档时共同的一个抱怨就是文档质量的问题。 软件工程师总是需要自己编写文档。 什么是文档 工程师为了完成工作而需要编写的所有补充文档，不仅是独立文档、还有代码注释。 为什么需要文档 高质量的文档对工程组织帮助很大。 代码和API变得更容易理解，可以减少犯错。 当设计目标与团队目标
阅读全文
摘要：代码评审时一个由作者意外的人评审代码的流程，通常在将代码引入代码库之前进行。 一些组织在整个代码库中由一组经过选拔的“看门人”，负责评审代码变更。 每天变更在提交强都要经过评审，每个工程师都要负责发起评审和评审变更。 代码评审通常需要一个流程，以及支持该流程的工具。 代码评审流程 作者会在其自己的工
阅读全文
摘要：管理代码库的规则：关于源文件存储位置的规则、关于代码风格的规则、关于命名、模式、异常、线程的规则。 规则就是法律，他们不仅仅是建议或者提示，而是严格的强制性法律。 这些规则是普遍可支持的，除非在必要使用的基础上获得批准，否则不得与易忽视。 指南提供了建议和最佳做法。 为什么要有规则？ 制定规则的目的
阅读全文
摘要：粒度是指测试所消耗的资源和允许它做的事情。 范围是指测试打算验证多少代码。 我们的”单元测试“一词用来指范围相对狭窄的测试，例如单个类或者方法的测试。 测试最重要的是提高工程师的工作效率。 小型测试时快速和确定的，允许开发人员在工作流程中频繁的运行它们并获得即使反馈。 在编写生产代码的同时编写对应的
阅读全文
摘要：测试一直是编程的一部分。 测试发展的核心是开发人员驱动的自动化测试实践。 自动化测试可以防止缺陷逃逸，这些缺陷可能会影响到用户。在开发周期中，一个缺陷被捕获的时间越晚，它的成本越高。 “捕获缺陷”只是做自动化测试的一部分动机。 另一个同样重要的原因是支持变更的能力。无论添加新功能还是进行保持代码健康
阅读全文
摘要：使用适当的指标进行数据渠道决策。 依赖数据往往使大多数决策是客观的而不是主观的。 但是从人的角度收集和分析数据有其自身的挑战。 为什么要度量工程生产力 业务的大规模发展，需要增加额外的人员，也可以通过提高每个人的生产力来解决。那么我们就要学会如何提供工程师的工作效率。要做到这一点，我们需要了解是什么
阅读全文
摘要：从领导一个团队到领导一一组相关的团队是一个自然的过程，如何能在工程领导力不但发展的道理上保持有效性。 随着角色得到发展变化，所有最佳实践任然使用，只能要解决的问题的范围变得越来越大，越来越抽象。 然后你越来越不能深入到技术或者工程的细节中去，你被推者去汪更广阔的领域，而不是更“深入”。你开始意识到你
阅读全文
摘要：没有领导者任何团队都无法正常运作。 经理和技术主管 经验丰富的人员经理将担任管理职务，而经验丰富的高级工程师将担任技术主管职务。 技术主管 一个团的技术主管向团队的经理汇报，负责产品的技术方面，包括技术决策和选择、架构、优先级、速度和项目管理。 从个人共享到领导者 如果你的产品想要有所进展，无论是否
阅读全文
摘要：工程师为广大用户设计产品时的独特职责，要做出更公平的产品设计。 人类的偏见 工程师应该关注到用户的国籍、种族、性别、年龄等等的差异，才可以不会让用户失望。 理解多样性的必要性 作为一个名优秀的工程师，需要关注将不同的观点带入到产品设计和实现中。 工程师应该首要把所有的工作集中在他们想要影响的整个生态
阅读全文
摘要：一个组织往往应该比某个网上的人更了解该组织自身的问题，而且，他也应该能够回答他自身的大部分问题。 为了达到这一点，你应该了解到哪些专家能够解决这些问题，也需要知道如何将他们的知识分发出去的机制。 一个组织需要一种学习型文化，它能为员工创造一种心理安全感，让员工承认自己缺乏知识。 学习的挑战 缺乏心里
阅读全文
摘要：我认为一个高效、成功的软件工程师需要把主要是时间花费在编写代码上，而不是整体都在与人沟通问题。 隐藏代码： 人们害怕别人看到自己的代码，因为有可能收到他人的批评。这种不安全感是一个更大的问题。 另一个隐藏工作的动机是担心别人窃取自己的想法并执行。 隐藏有害 软件开发中的协同和评审很重要，可以避免个人
阅读全文
摘要：变成与软件工程之间三个关键差一点：时间、规模、权衡。 关注时间的流失和可能的需求变更 关注规模和效率 做出更多复杂且高风险的决策（这是由于对时间和增长的不精确估计导致的） 如果在软件的预期生命周期内，无论是处于技术理由还是业务理由，你都有能力对任何有价值的变化作出反应，那么你的项目是可持续的。 团队
阅读全文
