写点什么

什么是好的应用程序?

作者:flow
  • 2022 年 8 月 05 日
  • 本文字数:3185 字

    阅读完需:约 10 分钟

什么是好的应用程序?

我最近申请了我现在的公司的一个职位,我被问到的一个问题是“什么是好的申请?

我以前从未想过。因此,将我自己对优秀软件应用程序的愿景形式化是一个非常好的练习。这是一个技术职位,所以我的答案是从开发人员的角度出发的。自从我给出我的答案以来,我再次考虑了这个问题,这是我对良好应用的愿景。

 

一个简单的应用程序

当我设计应用程序时,我总是认为“越简单越好”。开发人员应该只关注需求,而只关注需求。我真的很讨厌:

  • 过度设计(过度使用设计模式)

  • 过度优化

  • 过度开发

  • “灵活”的架构

没有什么比容易掌握的简单的东西更胜一筹了。大多数时候,为潜在的未来需求而设计的过于复杂的架构永远不会 100%(甚至 50%)使用,因为:

  • 需求已经改变,

  • 期望太高和/或太远(谁能预测 5 年后会发生什么?

  • 该项目的预算已经减少了很多,

  • 企业战略已经改变。

这就是为什么我更喜欢简单的东西,如果架构不足以满足未来的需求,则需要进行大规模的重构。

例如,为什么需要一个大数据集群来构建一个刚刚启动的应用程序,因此处理的数据很少?作为一名大数据开发人员,我面试过的大多数候选人都在从事大数据项目,处理(非常)数百万的数据。当我问他们为什么使用大数据时,有些人告诉我“因为有很多数据”,而另一些人则“因为将来应用程序可以处理更多的数据”。几年前,我在一家大型银行工作,我们用“只有”关系数据库处理数亿数据。在掌握的关系数据库和有缺陷的 Hadoop 集群之间(由于人们的知识很少,分布式平台的复杂性以及不断发展的技术本身而变得错误),选择很简单。例如,Criteo(一家重定向广告初创公司)从 Microsoft SQL 服务器开始。他们只在 2011 年夏天才改用 Hadoop,现在他们拥有欧洲最大的 Hadoop 集群。

对我来说,更复杂的意味着:

  • 更昂贵(因为它更难理解,因此需要更多的时间)

  • 更多的错误(再次,因为它更难理解,因此更难测试)

  • 更难监控(再次,因为它更难理解)

当然,如果未来的需求是 100%确定的(例如,在设计一个非常大的公司的未来参考时,将在 3 年内完全使用),那么设计一个复杂的架构是值得的。

 

可读的代码

一个好的应用程序的一个关键是可读的代码。由于应用程序将由许多开发人员编写和读取,因此他们不要花费太多时间来理解遗留代码,这一点很重要。

在对象编程中,这意味着具有短函数(具有很少的循环复杂性)和具有很少职责的类的代码。我是松散耦合的忠实粉丝,它增加了组件的隔离性,因此有助于在开发人员之间共享工作。

另一个关键点是代码的一致性。在大型项目中,数百名开发人员修改源代码。如果有人按照自己的意愿编码,那么代码很快就会变成一场噩梦,有很多风格的代码。这就像读一本书,有时用英语,有时用法语,有时用德语,有时用俄语......开发团队必须收敛到唯一的代码约定,并且代码必须归任何人所有。我真的很喜欢自我解释的代码:大多数时候,使用函数,类和变量的显式名称,而不是编写注释的音调。当然,仍然需要编写文档(我更喜欢直接在类和函数中编写它)。

我读过的最好的例子之一是Spring框架:它有超过一百万行代码,但我读过的几个部分(关于 Spring Core,Spring Batch 和 Spring Data),其中连贯性和命名约定非常全面(但有些人不喜欢 Spring 使用的代码约定的冗长性)。此外,Spring 文档很棒。一个不好的例子是一个非常著名的 C 库:libavcodec。大多数应用程序使用此库来处理音频和视频流的压缩、解压缩和动态转码。这个库所做的工作非常令人印象深刻,但是,当你是一个初学者并试图理解它时,这完全是一场噩梦。我花了大约 15 个小时来理解它的某些部分,以便在空闲时间制作音频流服务器,但我放弃了它:没有足够的文档,代码约定不够明确(对我来说)在没有文档的情况下快速理解。

 

经过测试的代码

当我开始工作时,一位同事告诉我关于单元和集成测试的信息,我在想“伙计,为什么我需要测试,大多数时候我的代码都是第一次工作”。说实话,我的一部分仍然认为是一样的...但我的愿景已经改变了很多。

当我编码时,我总是想:“它是可单元测试的吗?这是一个非常好的练习,因为它迫使我总是(当我有足够的时间)应用松散耦合。此外,集成和验收测试允许您折射代码并修改其他人的代码,而不必担心修改应用程序的行为。

但是,好吧,假设你有单元测试集成和验收测试,具有非常好的代码覆盖率,最重要的是测试是自动化的(例如 Jenkins)。但这些测试是否相关?我给你两个糟糕(和真实)的例子:

  • 在之前的一个项目中,人们伪造了大部分测试,只是为了增加代码覆盖率,使其看起来像一个非常好的项目。他们没有时间编写真正的测试,并且必须具有高代码覆盖率。

  • 在另一个项目中,我对别人的代码进行了审计,发现这个人测试的不是代码的行为,而是测试测试中使用的模拟的行为。

在这两种情况下,代码覆盖率都很高,但应用程序并没有真正经过测试。

只有当开发团队真正了解客户的需求和测试背后的概念时,才有可能进行相关的测试。当然,这也需要有足够的时间。

 

可利用的应用程序

太好了,你有一个很好的应用程序,但是:

  • 它是否运行良好?3 个月后还会是这样吗?

  • 您是否被黑客入侵?你被黑客入侵了吗?

  • 是否确定?

为了回答问题,您需要能够监视您的应用程序

为此,您必须拥有一个具有不同日志记录级别的良好日志记录系统,以便在您确实不了解 Bug 时可以在更详细的情况下以更详细的方式“切换”生产应用程序。

此外,当问题发生时,您需要记录重要事项。我已经处理过很多次生产中的崩溃,有时我唯一得到的是“错误”。很好,但是是什么导致了这个错误?在这次崩溃之前,变量和用例是什么?我很难理解一些根本原因(这让我想要杀死制作 ##的开发人员)

另一个方面是编写技术和功能指标来监视应用程序行为。例如,内存使用情况,当前进程的数量,客户/合同的数量/每天创建的任何内容......这些指示器可能有助于您检测异常行为。也许内存和 CPU 被过度使用,因为你被黑客入侵了。也许自上次安装以来创建了太多客户,因为您有一个重复创建的新错误。下面是一个糟糕的可利用应用程序的示例:在以前的项目(在一家大公司)中,我们发现在黑客攻击 2 周后,我们被黑客入侵,只是因为黑客变得过于贪婪,我们的集群服务器在负载下崩溃了。有了一个好的监控系统,我们可以更快地检测到入侵。

所有这些日志和指标都需要存储在某个地方。再一次,我喜欢简单的事情。对于简单的应用程序,仅使用平面文件就足够了。但是,如果您的应用程序有许多服务器,则使用集中式日志记录解决方案(如 logstash/kibana/elastic search)非常有用。我从事一个项目,生产中有超过 30 台服务器,没有集中式系统,让我告诉你,阅读每个日志以查看一切是否正常是浪费时间。

 

客户满意

我见过许多开发人员只受技术驱动。但应用程序不是关于技术,而是关于满足客户的需求

我喜欢技术(尤其是新的和闪亮的技术),但有时我会选择我不喜欢的“旧”技术,因为它完全符合客户的需求。

此外,大多数时候,了解一种语言的特殊性是没有用的了解你正在从事的业务领域是有用的。我从来不理解那些不关心业务领域、只关心技术(通常只有几种技术)的开发人员。例如,在处理巴塞尔 II 规范(为避免银行破产而制定的欧洲规范)的银行项目(处理数亿数据的项目)上,该项目中的许多开发人员从未读过有关巴塞尔 II 规范的文章,也没有试图了解这些规范的基础知识。他们本可以在核电站或网络爬虫上工作,这将是相同的:他们只是在不了解其开发用途(甚至一点点)的情况下实现他们被要求的东西。

对我来说,这一点是最重要的。即使你的代码完全是一场噩梦,如果你交付的东西让客户满意,那也很重要。要做到这一点,你需要了解客户的业务领域。

客户满意度应始终是重中之重

 

几句话

你刚刚读到我对一个好的应用程序的愿景,它非常接近敏捷哲学。我没有谈论人体工程学或可用性,因为有许多类型的应用程序(用户界面,批处理,Web 服务......

这是一个非常主观的,因此有争议的话题。那么,您认为什么是好的应用程序?

发布于: 刚刚阅读数: 3
用户头像

flow

关注

还未添加个人签名 2022.07.13 加入

还未添加个人简介

评论

发布
暂无评论
什么是好的应用程序?_签约计划第三季_flow_InfoQ写作社区