刚加入互联网企业时，有两个事情让我印象深刻，并给我很深的思考，1.互联网企业做性能测试时，一般10分钟左右就完成测试，而传统企业性能测试时间大多在几个小时，有什么甚至要做到7*24小时，为什么会这样呢？到底是什么原因导致有这么大的差异？2.另外一个事情是刚到金融不久，开发金条项目，第一个版本上线的是借款，第二个版本上线的是还钱（大概2周后），后续的版本逐渐上线的合规风控等。这个事情当时给我一个很大
做好一件事Unix的哲学是使用每一个简洁又专业的工具来做好每一件事，然后将它们像流水线一样连接起来操作数据。这是一个很棒的主意，并且在过去的几十年里一直运作良好。这一理念在1978年BellSystemTechnicalJournal前言中有所概述，描述了UNIX分时系统：列出的第一项和第二项实际上已经被我们反复实践。但现在是时候通过进一步定义非交互式的标准输出格式将这一理念带入21世纪。具体来说
关键点技术教练可以帮助开发者改变他们的日常习惯和工作方法，以更好的支持敏捷模式和开发运维。很少的团队可以成功的运用TDD。开发者从TDD练习到实践，都需要一些支持与帮助。与有经验的练习者一起工作去学习TDD是非常有效的，尤其是结合常规的实际训练课程。“Samman”是一种技术教练的方法。它有两个主要组成部分：团队协作和学习时间。技术教练太少了，像Samman这样具体的方法可以帮助开发者开始训练。对
更新（2021.8.21）我不是反对使用IDE有时候他们提供很有用的工具，像代码重构工具和方法重命名，只需要很简单的手动操作。我自己也几乎每天都在使用IntelliJ，CLion和MySQLworkbench。我只是简单的列举一下不要一直使用IDE的原因。对于一些项目而言，不使用IDE有许多好处。但是，我认为，有时候使用IDE才是最好的选择。IDE（集成开发环境）非常流行。他们在静态类型语言上支持
不论你是什么时候开始接触测试这个行业的，你首先听说的应该是功能测试。通过一些测试手段来验证开发做出的代码是否符合产品的需求？当然你也有自己对功能测试的理解，但是最近两年感觉功能测试好像不太受欢迎，同时不少同学真的是功能测试都没有做好，就去尝试自动化测试，测试开发什么的，结果是越学越迷茫，这是为什么呢？究其原因是，你功能测试还没有学好呢！我们通常认为的功能测试是根据需求，采取如下测试流程：需求分析，
前段时间读了一篇文章：“外卖骑手，困在系统里”，引发了我很多的思考，后来有幸和作者有过一次交流更是让我印象深刻。上两周我写了一篇文章“如何用研发效能搞垮一个团队”引起了业界同行大量的讨论与关注，今天想借此继续来聊聊研发效能提升过程中另一个无法回避的的话题：“度量”。历史上度量失败的案例这其实是“窗户税”所引发的不良后果。1696年之前，英国政府对于个人房屋的税收采用的是“壁炉税”，也就是根据屋内的
敏捷开发模式和DevOps的实践促进了开发、运维和质量团队更多的合作和更好的沟通，同时也模糊了这些团队之间的界限，强调每个人都对质量负责。敏捷实践让研发团队在交付速度上变快了，但不知不觉中质量却因此受到影响。本文总结了在质量工程实践中应该遵循的六大原则。原则1-团队应从第0天开始考虑质量问题，将质量工程彻底融入软件开发的生命周期。质量工程需要组织内管理层的支持和所有团队的参与。质量工程的建设将改变
“转敏捷后，测试经理的话语权没有了，团队更加关注交付速度而不重视质量怎么办？”在跟某转型中的团队进行交流时，一位测试经理表达了这样的担忧。我理解这里的困惑在于两个方面：●传统模式下测试是一个独立的部门，测试经理可以在测试这个阶段严格把关质量，有很强的话语权；在敏捷模式下，测试需要融入开发团队，都由开发团队PM来统一管理，很有可能会更关注交付速度，这种情况下，测试经理的话语权似乎减弱了，该如何发挥价
根据2021年的自动化测试报告，超过40%的公司正在寻求扩展和投资于自动化测试的资源。虽然这并不意味着手动测试会消失，但从ROI的角度来看，人们对自动化越来越感兴趣——无论是在金钱还是时间方面。毕竟，我们都承认编写和运行单元测试很无聊。一个好的自动化策略可以腾出测试人员的时间来解决一些更复杂的问题并及早发现错误。然而，团队经常在没有适当测试策略的情况下急于自动化测试，这会导致在进行大修时出现问题。
摘要我们努力不说："谷歌的软件工程”是唯一真正的方法，因为我们认识到，我们的规模和资源与其他组织完全不同。软件工程不是（单纯的）编程，而是长期的编程。我们主要关注的是如何让事情随着时间的推移持续发展，以及如何与其他人协调和合作。书中的代码很少，但其主要的内容依旧是关于软件的讨论。谷歌在技术上和组织上都是不完美的。你可以从我们对外部软件包的维护等技术问题的处理中看到，也可以从我们围绕公平和多样性的文
热门文章