关于软件开发 关于软件开发，都应该知道的10个常识

2011年，马克·安德森写了一篇文章，预言“软件吞噬世界”。主要有两种观点:一是很多传统业务正在被软件公司取代；第二，所有其他公司都发现他们提供的价值越来越来自软件系统。

安德森写这篇文章的时候，市值最大的10家公司都没有从事软件驱动的业务。今天，10家最大的公司中有6家主要是由软件驱动的，而另外4家公司准备转型。

Stack Overflow和LinkedIn列出的非技术公司的软件工程招聘广告比技术行业本身多。这是经济发展的一个巨大变化，说明公司正在加强软件工程实践。

会计和软件哪个对公司更重要？本文无答案。但是现在许多不认为自己是软件公司的公司开始发现软件系统是他们运营的关键组成部分。

如果各级CEO和经理不懂软件，那就可有可无了。这要么会限制他们的职业发展，要么会对公司的业绩产生负面影响。无论如何，不懂软件，注定失败。(Gartner预测，到2020年，50%的首席信息官(CIO)将被取代，因为他们没有能力改造公司。)

这篇文章列出了管理者应该知道的10个常识:

软件不是魔术软件永远不会“完成”软件开发是团队作战，没有人能做所有事情设计不是外观，而是工作原理安全是每个人的责任feature大小并不能预测开发时间伟大来自于成千上万的小进步技术债很讨厌，但不可避免软件不会自己运行（软件需要运维）复杂的系统需要DevOps才能良好运行

关于软件，本文认为这是所有管理者需要知道的十件最重要的事情:

1.软件不是魔法

软件不是魔法。虽然看起来像魔术，或者说是魔术，但其实不是魔术。每一个元素都是人类设计的，都有它的数学基础，或者说是可以用人类语言解释的过程。

与魔法不同，软件不是由空创造的。它需要设计、建造和维护。就像一个房子有很多系统一起工作(基础、结构、管道、房间、家具等)。)，软件系统也需要很多层和子系统来创建整个系统。可以设计的很好，也可以设计的很差，快速设计很少能持久。

如果人们无法用语言描述它会做什么(包括想要的结果和如何实现)，那么计算机也做不到。“如何”叫算法，不算神奇。

机器学习等人工智能技术并不惊艳。机器学习是基于数据预测，而不是显式的规则或指令。一般用线性代数来做。如果有100万张已知香蕉的照片和100万张没有香蕉的照片，一个训练有素的机器学习系统会根据它从前面的照片中学到的知识告诉你它看起来像第一组还是第二组。这不是魔法。使用机器学习根据过去的招聘决策对简历进行排序，即使没有任何有意的偏见，也可能会扩大经验性的招聘历史。

2.软件永远不会“完成”

软件永远不会“完成”。软件是一个迭代的过程，在其生命周期中有许多修订和更新。我们的工作是创造一个能够认识到这一点的环境。

同样，我们也从来没有期望营销和客户获取能够“完成”，它们是迭代的过程。在每一次迭代中，当我们继续向业务交付价值时，我们继续学习和成长。即使已经有一些成功的发布，我们也从未打算“停止”做这些事情。

如果软件可以一个版本完成就好了，但事实并非如此。需求文档充满了歧义，软件第一版全是“哦，我写的，不是故意的”。最好的软件可以激发新的想法和功能需求。看到新的销售管理系统效率更高，就会激发更高的效率。世界在变，竞争对手提供新的功能，人们有了新的想法。此外，总有一些错误需要修复:要么在代码中，要么在构建代码的底层软件框架和系统中。有些软件可能很完美，但我们可以肯定，随着时间的推移，人们会发现它搭建的平台存在各种漏洞。

我们的工作是让一个组织意识到这一点。

实现这一点的方法是建立一个有信心定期发布新版本的组织。当全自动测试和其他工程规范到位时，我们建立信心。这种信心创造了每季度、每月甚至每周发布高质量软件的能力，而不是过长的发布周期。具体频率不重要，信心重要。自信可以带来更快的创新。

3.软件开发是一场团队战斗，没有人能做到一切

软件开发是一场团队战斗。开发人员既不是产品经理，也不是UX设计师，也不是质量工程师、分析师、安全专家、技术作家或运营工程师。组织需要所有的角色。

没有一个经理会建议每个销售人员都去做营销和公关，否则销售团队就会被开除(因为营销人员知道产品，也能做销售)。营销和销售是有联系的，但又是不同的。所以，他们之间是有分工的。

同样，开发团队需要独立的人员来收集需求、质量保证和测试、代码编写等等。

开发人员可以“无所不能”的神话被称为“全栈开发人员”或“10x工程师”，通常只存在于小公司。是的，一个很小的公司可能会自己做营销和销售，但是你不一定会加入这么小的公司。

不要用自己的兴趣去挑战别人吃饭。孩子“擅长Facebook”并不代表他或她会成为下一个扎克伯格；一个孩子对工程感兴趣，不代表他或她会用微积分。一个孩子可以自己建一个网站，并不意味着这个网站每小时可以处理数十亿的金融交易。

4.设计不是外观，而是工作原理

史蒂夫·乔布斯有句名言:“设计不仅仅是外观和感觉。设计就是它的工作方式。”UX的设计师不会坐下来决定菜单的颜色或者按钮是圆形还是方形。他们决定什么是工作流和交互。

用户会看到一个有三个选项的屏幕，还是一个屏幕只显示一个选项？这个设计决策需要心理学，需要对用户的同理心，需要测试，测试，再测试。

UX设计面临的最大挑战之一是，一旦你熟悉了这个系统，你就失去了预测新用户的能力。当预测新用户的需求时，设计系统的人将被自动取消资格。UX也许美丽而优雅，可以与一件艺术品相提并论，但要求UX设计师将背景换成帆船的图片是没有帮助的。

我们的工作是相信测试数据而不是主观臆测，创造一个环境，计划在产品发布前做几次修改，期望在产品发布后做进一步的改进。不要混淆UX设计师和平面设计师。让UX设计师设计公司节日贺卡，让技术作家写公司时事通讯，也是同样的不尊重行为。这些是不同的技能。

5.安全是每个人的责任

不管知不知道，不管喜不喜欢，我们都是从事安防行业的。所有软件都有安全要求和潜在的安全漏洞。参与软件开发的系统也有安全要求和漏洞。虽然防火墙和入侵检测等安全基础设施组件是必要的，但它们是不够的:软件平台必须通过使用内置的安全控制来设计、实施和维护。安全既是好的技术，也是好的流程。

认为我们不是攻击的目标是错误的。所有的计算机系统都是攻击的目标，因为攻击不仅仅是针对其中的信息，而仅仅是针对它是一台计算机这一事实。例如，一个没有有价值信息的系统是网络攻击的目标，因为它可以用来转发对其他计算机的攻击，挖掘比特币，或者存储他人的盗版视频。

安全不是一个开/关按钮，有很多灰色区域。安全性最好从一开始就考虑。事后修补既费钱又往往无效。我们不会先造一艘船，然后“加”一个函数让它浮起来。同样，也不可能先建立一个系统，然后按下“安全”按钮就安全了。

安全是关于风险和对风险的承受能力。加密两个节点之间的通信不能保证其安全性，但提高了安全性，只有超强的计算能力才能破解密码。降低一个领域的风险对其他领域没有帮助。保护网络并不能防止物理安全问题。一个人开门，别人就能偷你的备份磁带。

正如吉恩·斯帕福德(Gene Spafford)的名言所说，“唯一真正安全的系统是一个关闭的系统，用混凝土浇筑，由全副武装的警卫在一个绝缘的房间里守卫——尽管如此，我仍然有疑问。”

遵守NIST CSF(国家标准与技术研究所网络安全框架)、PCI DSS(支付卡行业数据安全标准)和SOC 2(服务组织控制报告)可以量化风险，如果做得好，可以降低风险。这些标准不能保证绝对安全，绝对安全是不存在的。更重要的是，它们为如何负责任地处理和报告不可避免的安全漏洞提供了指导。诚实、坦率、开放是很好的建议。

软件，如果任其发展，会变得像面包一样古老。我们的工作是平衡安全错觉和现实，并适当地预算时间和资源。

6.功能大小无法预测开发时间

特征尺寸(由用户感知)与创建特征所需的时间无关。小功能可能需要几天或几年，大功能(被用户感知)也可能需要几天或几年。

我们的工作是创建和支持一个软件开发过程，这个过程接受这个事实，而不是拍拍脑袋去评估数量。工作量评估本身可能需要非常长的时间。

鼓励沟通解决工作量考核问题。工程师可能会给出一个令人惊讶的长工作估算，但他们也会对需求提出更改，从而大大缩短时间。请记住，工作量评估应包括测试、培训、部署和意外假期(如病假)。

在没有咨询工程部门工作量的情况下，不要承诺某个特性。这不是我们在公司权力的标志。需要的是一个专业的过程，在这个过程中，开发人员的请求被认真对待，工作量被评估并按时交付(或者由于诚实的原因被延迟)。

7.伟大来自成千上万的微小进步

伟大来自于在很长一段时间内数以千计，也许数百万计的微小进步(变化)。如果变更的影响都被测量为负，则变更将被回滚。

谷歌不是一天建成的。谷歌的搜索引擎是数百万人改进的结果。搜索质量团队每周开会一次，工程师走上平台提出修改建议。他们展示了在模拟环境中会有多大的改善，委员会进行了辩论和投票。几周后，将对测量结果进行审查，并决定保留还是回滚更改。

Google搜索是迭代开发对“生活大爆炸”思维的胜利。没有人能在一开始就做出好的搜索引擎。只有在好莱坞电影里，一个聪明的极客才能想出惊人的新点子，第一次完美实现。在现实世界中，一夜成名需要几年时间。

无论目标是为客户提供更好的服务、更高效、错误更少的系统还是更流畅的系统，这都是正确的。

我们的工作是要求系统设计能够容易地接受新的变化，并定义相关的关键绩效指标(关键绩效指标)，这些指标可以在变化前后容易地测量。最重要的是，必须有一个过程来检查结果，并决定是保留还是回滚更改。回滚不应被视为失败或惩罚。从每次回滚中学到的东西和从每次保留的更改中学到的东西一样有价值。

托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当记者问他“失败1000次是什么感觉？””他回答，“我没有失败1000次。灯泡是1000步的发明。"

8.技术债很烦，但不可避免

技术债务是未来需要做的工作，因为我们选择了更简单的解决方案，而不是使用更长时间的更好解决方案。任何规模合理的软件项目都有技术债务。技术债务让所有的进步都变慢了。我们越忽视它，它就越滚雪球。

有财务背景的管理者听到“负债”这个词，会认为这是一项未来会有回报的投资。相反，技术债是有毒的，是痛苦的，是定时炸弹。

1972年，Fram为其滤油器做了一个电视广告。广告中，一位汽车修理工解释说，一位客户为了节省4美元，没有更换机油滤清器。后来，客户不得不花200美元更换一个昂贵的主轴承。汽车修理工总结道:“你可以现在付我钱，也可以以后再付。”

有一个软件项目，其中一个子系统与供应商通信。一开始系统只和一个供应商沟通，所以很简单。然后一个接一个，然后又一个。有些功能必须实现三次，每个供应商一次，不可持续。当被要求支持第四家供应商时，开发商表示反对。是的，他们可以在一个月左右移植，但是软件架构开始嘎吱作响，就像飓风中的老房子。这些权宜之计积累了大量的技术债务。

开发者的建议是花两个月时间重构供应商架构，成为一个插件系统。然后，新的提供商可以在一周内而不是一个月内支持访问。

管理者不高兴。为什么下一个供应商需要两个多月才能支持，而上一个供应商一个月内就支持了？花两个月偿还技术债，会让以后的支持更快，代码更稳定，更容易添加新特性。很难衡量确切的好处。

你可以现在付钱给我，也可以以后付钱给我。

我们的工作是分期偿还技术债务。失控的技术债务降低了添加其他功能的能力，并导致软件系统的不稳定。技术债务的偿还应与业务目标挂钩，类似于非功能性要求。

9.软件不会自己运行(软件需要运维)

虽然厂商和开发者可能会尝试告诉你不同的情况，但是软件不会自己运行。任何基于软件的系统，尤其是网站和web应用，都需要运维人员和运维流程。否则，软件就像一本合着的书，必须有人打开它，管理它，照顾它的需要。

运维比软件开发本身更重要。代码只写一次，但可能运行几百万次。所以，粗略衡量一下，运维的重要性是不是高了几百万倍？

我们的工作是期望操作和维护成为任何软件系统的一部分。它必须像任何其他项目一样进行有效的规划、预算、管理和运行。

运维功能(一般称为非功能性需求)除了作为次要需求外，对用户是不可见的。数据备份是非功能性需求的一个很好的例子。没有用户请求数据备份，但用户请求恢复已删除的数据。不幸的是，没有备份就没有恢复。恢复是功能性要求，而备份是操作性(非功能性)要求。

使软件服务易于维护或高效运行的功能需求从来不是由用户提出的。然而，他们确实享受低成本和高可靠性系统的好处。客户会离开那些不靠谱的网站，再也不会回来。

持续改进的需求不仅包括新的功能需求，还包括新的非功能需求。所以我们的工作不仅仅是为客户提出的功能需求分配资源，还要为运维需求分配资源。很难在两种相互竞争的需求之间取得平衡。

然而，一个成功的产品是在业务需求和操作维护需求之间权衡的结果。

10.复杂系统需要DevOps才能运行良好

复杂系统最好通过DevOps来改进。DevOps的定义有很多，但是DevOps通常被认为是通过快速迭代(特性、bug修复、流程改进等)来加速交付价值。).要做到这一点，每个参与的人都必须参与。也就是说，他们必须跨职能团队协作。DevOps这个名字来源于消除开发人员和运维(IT)之间的隔阂，这对于快速发布是绝对必要的。然而，优秀的DevOps环境将其扩展到所有职能团队的端到端工作。

DevOps被误解为做运维的开发人员。这种“构建它，运行它”的策略是跨职能团队工作的一种方式(消除障碍)，但不是唯一的方式。

一个复杂的系统需要三样东西:良好的流程，所有相关人员之间良好的沟通，以及尝试新事物的能力。

结论

软件正在吞噬世界。本文总结了软件和软件工程的十条谚语，希望管理者和相关从业者能够理解它们的重要性并从中受益。

原文:https://queue.acm.org/detail.cfm? id = 3325792