软件开发应该优先服务谁？——广发开发者讨论

菏泽炫佑科技

软件开发应该优先服务谁？——广发开发者讨论

编译| 楚杏娟、核子可乐

近日，从事开发工作十余年的Olano写了一篇《软件开发中谁应该被优先考虑？》的文章，引发了GF开发者的讨论。 文中提出，业务和用户的优先级永远大于维护者，维护者大于开发者，但业务和用户的优先级无法确定。

对此，有开发商指出，开发商必须真正满足中层管理者的需求而不是实际用户的需求，否则就拿不到订单。 那么，在这个研发生态中，开发者显然处于底层，那么谁又处于“食物链的顶端”呢？

“阅读代码的次数多于编写代码的次数。” 相信很多程序员朋友都听过这句话。 它提醒我们，作为代码开发者，千万不要为了自己的方便而牺牲以后的阅读和修改空间。 换句话说，阅读的代码多于编写的代码，因此*好找到保持代码简洁明了的方法，并使用测试和文档等有助于提高可维护性的元素。

我个人总结得比较简洁：

维护者>作者

事实上，除了编码之外，这样的经验法则也适用于发现问题和做出决策。

代码是用来运行的，不是用来阅读的

代码只是达到目的的一种手段。 软件有自己的用途软件开发，负责为特定用户提供服务。 如果代码不能达到项目的目的，不能为用户提供良好的体验，那么无论代码本身的质量有多高，可维护性有多大，涉及的技术有多精深，都是没有意义的。 所以：

用户>维护者>作者

换句话说，如果我们统一开发者部分，我们得到：

用户>开发者

正因为如此，我们应该尽早将程序交付给用户，然后根据他们的反馈不断进行优化，而不是提前做很多假设或反复询问他们想要什么。

这是一个强大的思维模型。 只要在开发过程中始终以用户为中心，我们就能走得更远、更稳。 这也是我在漫长的职业生涯中总结出的*具指导性的发展方针。

代码运行次数大于读取次数

当我说“操作”时，我指的不仅仅是执行程序，还包括生产操作的各个方面：部署、升级、观察、审计、监控、修复、报废等。正如 Dan 所说：

“一般来说，保持系统长期可靠运行的成本远远超过构建系统带来的不便。”

我们也可以将这个结论代入到上面提到的小模型中：

用户 > 运营商 > 开发者

我花了很长时间才明白这一点。 因为从个人经验来看，很多实际构建的软件从未真正投入生产，至少没有大规模投入生产。 这是因为大多数软件都是建立在未经测试的假设之上的。

在生产环境中运行代码时，看似简单的保持简单/为傻瓜设计的原则通常很难实现。 它不仅指代码本身，还要求减少软件中的活动部件并了解软件的故障模式。 也就是说，即使某些部分出现故障，软件仍然能够正常工作。

别忘了，软件是为业务服务的

要让开发过程顺利进行，核心要素在于用户。 基本假设是软件本身有用且运行良好，并且软件对用户和组织有价值。 这种进步可以转化为这样的理解：开发者需要写出好的、可用的软件，然后业务部门将其转化为经济效益。

此外，该软件应该整体有效并更好地满足消费者和企业的需求。 通过结合商业角度，我们的基本政策进一步扩展为这样的形式：

业务 > 用户 > 运营商 > 开发者

*典型的例子就是预算：我们不可能有无限的资源来满足用户需求，所以我们必须首先衡量成本和收益，并弄清楚如何设置营销活动和发布期限。 此外，还有利益相关者和投资者，每个人都有自己的利益和要求。

在如此复杂的情况下软件开发应该优先服务谁？——广发开发者讨论，乍一看对软件、开发团队或用户有利的决策往往会对整个组织产生负面影响。 有时，我们需要创造收入而不仅仅是取悦用户。

反面例子

至此，我们有了一个小模型，它表达了软件开发过程中各种因素的相对重要性。 或许可以帮助大家从宏观的角度关注真正关键的环节。 接下来，我们将研究常见的软件开发障碍，并尝试将它们纳入我们的思维模型中。

无法维护的代码：作者 > 维护者

这就是我们文章开头提到的情况。 开发人员很聪明，但太懒了，所以他们写的代码变得纠结、混合意大利面。 后来的继承者永远不会明白为什么要这样设计。

无用的软件：开发者>用户

对于那些不关心用户体验，或者坚持把技术放在**位的团队来说，他们开发出这种无用的软件。 它充满了过度设计的“现代”元素，降低了用户体验，Web应用程序甚至可能导致浏览器崩溃。

它显然可以在我的机器上运行：>

该软件在设计时并未考虑运维需求，因此软件本身过于复杂，包含大量移动部件、专用于小数据负载的数据库、由许多小团队管理的微服务生态系统等等。 简而言之，软件架构在没有必要的时候就开始考虑后续的规模扩展问题。 *终运维人员被折磨致死，开发人员也被诟病。

科技赋能商业：开发者>商业

将代码本身视为目的。 这是一群想成为工匠的人、泰坦尼克号音乐家和 Lisp 极客想出来的。

简历驱动的开发：开发人员 > 一切

这种软件的开发没有任何限制，可以让开发人员发挥他们的想象力。

纯幻想软件：业务 > 用户 > 运营开发人员

尽管可以开发此类软件，但很少（如果有的话）投入生产。 我个人称之为幻想软件，因为它完全是基于业务部门的想象。

业务>用户>运营商>开发者

这又是一个不考虑用户需求的乌托邦软件。 它根本没有解决问题，或者解决了错误/不存在的问题。 这类软件会迫使用户向它靠拢，以便让大量的前期投资看起来有点用处。

极端资本主义软件：商业 > 用户 > 运营商 > 开发人员

这是由风险投资支持的软件，没有健康的商业模式。 换句话说，商业模式只追求持续增长，实现垄断，剥削用户。

一点总结

*后，让我们总结一下这个有趣的思想实验：

商业>用户，这将带来不可估量的灾难性后果。

前面说过，我们之所以开发软件，就是为了给*终用户解决问题。 《程序员之道》总结得很好：我们的目标是取悦用户，而不仅仅是交付代码。 但自从我投身于程序开发以来，我发现随着软件的普及程度不断提高，这个假设变得越来越不受重视并且难以维持。

如今广泛使用的许多软件根本不关心用户，甚至操纵用户，将其变成产品的一部分。 这不仅仅局限于社交媒体——作为用户，我们甚至无法避免各种页面和功能栏上的广告弹出，谷歌搜索显示的垃圾内容也越来越多。

在我看来，好软件的定义与业内大多数人认为的盈利软件严重脱节，这也是许多软件专家强烈不适的根源。 虽然我们不能忽视软件开发领域底层的商业逻辑，但我们至少应该采取更强硬的道德立场，拒绝无休止地伤害用户。 用户不一定总是优先于业务，但也不应该无条件地将业务放在**位：

用户 > 运营商 > 开发者

业务>运营商>开发商

业务≹用户

网友：其实你要考虑管理

这篇文章引起了 GF 开发人员的共鸣。 同时，这些开发人员根据自己的实际经验做了一些补充，比如管理的关键作用。

一位开发者直接指出，有些用户使用某个系统并不是因为他们喜欢它，而是因为他们的公司购买了它。 “在‘​​业务>用户’的情况下，开发人员*终不得不迎合中层管理人员而不是实际用户。不这样做的代价就是无法赢得合同。但是当你忙于实现中层管理人员喜欢的新功能时，用户的需求将被锁定在你能在有限时间内提供的‘垃圾’中。”

“我有过这样的经历。我在一家向市政府销售软件的公司工作。重要的是市长/镇长/市议会的意见。如果报告看起来不错，价格合适，他们就会更新。二记得在会议上，每天使用它的人面对面告诉我们它有多糟糕。毫无疑问，该网站承诺修复一些特定的错误，并将价格提高到*低。” 网友“”提到。

“通常情况下，中层管理人员也是用户，”指出，“但他们只占用户群的少数，并且使用不同的功能集（例如报告）。因此，现在的问题是哪些用户被优先考虑，以及在哪里找到平衡点少数授权用户的体验与保持产品足够可用以供其他用户提供一些数据价值之间的关系。”

对此，一位开发者指出，“你需要考虑中层管理人员的需求，因为他们付钱给你，但通常还有工艺空间为*终用户带来真正出色的用户体验。 大多数软件工程师缺乏真正的工艺意识，因此当不需要构建出色的用户体验时，他们通常不会为此烦恼。”

参考链接：

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等