程序的“通用性”和“过度设计”困境

在软件工程的实际操作中,我常常遇到这样一种现象:本可以用简单代码解决的问题,却因为设计者过分关注“通用性”、“可维护性”和“可扩展性”而变得不必要地复杂,难以理解。

他们的思维方式是这样的:“这段代码未来可能会在更多场景中使用,所以我现在应该考虑它的可扩展性。”结果,他们在代码中加入了各种“框架结构”,以便在未来有新需求时,无需修改就能在新的地方使用。

“通用性”的价值与误区

作者并不否认“通用性”的价值,我的一些程序也具有很高的通用性。然而,很多人所谓的“通用性”实际上适得其反,这种现象通常被称为 “过度设计” 。关于过度设计,有一个有趣的故事:

传说在上世纪60年代美国和俄罗斯的“太空竞赛”期间,NASA 遇到了一个严重的技术问题:宇航员需要一支能在外太空真空环境中书写的笔。最终,NASA 花费了150万美元开发了这样一支笔。不幸的是,这种笔在市场上并不畅销。

俄罗斯人也面临同样的问题,他们则用了铅笔。

虽然这个故事是虚构的,但它具备了伊索寓言的力量。现在让我们看看软件行业,可能会发现:

代码需要“重用”的场合比您想象的要少得多

许多人在写程序时,连“当前异常”都处理不好,却关注“未来的需求”。他们总是想象别人会重用这段代码。然而,实际上,由于设计过于复杂,理解这些设计所需的心智努力已经超过了从头开始的成本。因此,大多数人根本不会使用他们的代码,而是重新写一个。有些人最终会发现自己甚至看不下去之前写的代码,更愿意删除它并重新开始,而不是谈论重用。

继续阅读程序的“通用性”和“过度设计”困境

发布于

什么是远程物联网设备管理

工业4.0的兴起和连接设备的指数级增长,导致了远程物联网设备管理解决方案的出现。物联网可以看作是一个生态系统,可以通过蓝牙、WiFi、LoRa等无线网络连接多个智能设备。信标、传感器和跟踪器等智能设备很常见,每个设备都分配有唯一的IP地址用于识别。连接设备管理后,无需人工干预,自动采集和传输大量数据,辅助监控和故障排除。本文将深入探讨有关远程物联网设备管理的定义,及其他内容。

什么是远程物联网设备管理?

远程物联网设备管理是指从中央位置或平台监视、管理和控制联网设备。远程管理允许管理员通过基于云的工具安全地管理整个分布式物联网资产组,而不必在物理上靠近设备来配置设置或解决问题。

远程物联网设备管理对于大规模高效操作分散的连接设备是必不可少的。基本系统提供监控和远程控制,而高级平台则利用遥测数据分析进行深入的监督。总而言之,预先诊断即将发生的问题的能力非常有价值。

继续阅读什么是远程物联网设备管理

发布于

IT经理把项目带崩是因为这几点没做好

分享一个来自码哥工作中遇到的时间紧任务重,对系统不熟悉,没有产品文档,目标就是将原有系统改造成客户本地部署运行的多重困难跨团队协作项目管理差点带崩的经历。

通过该经历重点在于给大家分享如何避免项目搞砸,以及一个项目初期、中期、收尾阶段需要做的工作重点和注意事项,如何管理项目规避风险。

项目背景

项目的目标是将公司 saas 团队的供应链金融系统移植到客户独立部署,主要有以下几个风险和难点。

  • 团队内的人包括我并不熟悉该系统的业务流和系统的代码,难以分析项目的风险和改造点。
  • 干系人分析不足,没有将熟悉该系统的人引入,导致风险无法识别,进度缓慢。
  • 时间和人力明显不足:人力极致压榨。
  • 跨多个团队协作:开发该系统的团队并没有参与此次迁移工作。
  • 原系统与公司内部的接口交互需要全部通过 Http 来实现:原有的系统架构并不适用直接迁移到客户部署,部分接口能力是调用公司的其他团队实现,比如 AI 识别或用到 MQ 通信,通过 Dubbo 或者 HTTP 调用其他团队接口实现逻辑,需要统一改造成通过 Http 调用公司开放的接口实现。

除此之外,该 saas 系统由于原先开发人员的技术能力较弱,以及历史渊源,框架设计不合理,可读性和可维护性比较弱的情况下,如何更好的与原维护者沟通也是一大难题。

因为技术人会容易看不上别人的代码和设计,尤其是架构确实有明显不足的时候。

打开项目代码发现这是一个披着微服务外衣的大单体巨石服务。一边骂别人系统垃圾,一边还要请求人家帮助的事情需要合理手段解决。

最终发现拆了一堆的服务,可是实际上业务逻辑和系统的压力全都集中在 web-service 上。

至于拆出来的微服务,只干了一件事:myabtis 作为 ORM 框架操作数据库,也不懂这个项目的原开发和架构是怎么想的,单一职责不是这样理解的,大兄弟。

真的是「黛玉骑鬼火,该强的强,该弱的弱」。

遇到这种情况,我们一定要秉着谦虚的态度,因为还要请教他们解答项目如何迁移,需要我们想方设法用彩虹屁夸他们,让他们觉得受到尊重,虽然很反人类,可这是我们的必修课:

  1. “大佬,你们这块的设计思路是基于什么考虑呢,能这么平稳的运行一定有道理”
  2. 这块的设计真棒,学到了很多。

总之一定要一顿夸,切不可用技术人的视角把实际情况说出来,要是指出系统懂得各个不是,各种技术垃圾,你觉得别人还会帮你么?

继续阅读IT经理把项目带崩是因为这几点没做好

发布于

通过滴滴技术博客:探寻造成此次P0故障的真正原因

2023年11月27日晚至2023年11月28日早晨,滴滴发生了长达12小时的P0级故障,导致滴滴核心业务都受到了影响,比如不显示定位无法打车、滴滴单车无法扫码等问题,期间滴滴进行了多次致歉。

来源:https://weibo.com/2838754010/NuMAAaUEl

目前问题故障已经恢复,根据最新的消息得知造成此次事故的原因,是由于升级K8S 集群导致。

1. 集群体量大

最大集群规模已经远远超出了社区推荐的5千个 node 上限,有问题的爆炸半径大。

2. 版本升级跨度大

直接从1.12 升级到了1.20,跨越多个版本,有可能存在api不兼容的问题。

3. 升级方式应该选择了原地升级

虽然滴滴有能力基于K8S二次开发,但是由于版本跨度较大,细节点较多,原地升级风险我觉得比替换升级大不少。

比如集群版本已经升级为1.20,但是Node节点的kubelet的版本还是 1.12,如果api不兼容,那么这个影响是非常大的,集群回滚又没有那么快。

至于为什么采用原地升级方案,估计还有很多细节我们不得而知,但是此种方式确实有点激进,船大不好掉头。

 

来源:https://www.51cto.com/article/775071.html

发布于

YouTube 仅用 9 名工程师就能支持每天 1 亿次视频观看的 11 个原因

作者 | NK

策划 | 言征

2005 年 2 月, 美国加利福尼亚州。全球知名的在线支付服务公司PayPal已经走过 6 年零 2 个月的时间,3 名早期员工就像发现了互联网世界的流量密码一样,开始寻找属于他们的机会。

最后,他们希望建立一个分享视频的平台。后来这个在车库里诞生的平台,就是大名鼎鼎的YouTube。

最初,他们的财力有限,只能通过信用卡债务和基础设施借款为 YouTube 筹集资金。但财务上的紧张,也倒逼着他们打造出一套出色的可扩展性技术。

第二年,他们平台的视频日播放量就达到了 1 亿。更令人出乎意料的是,他们只用了 9 名工程师就做到了这一点。

YouTube 是如何做到的?下面为大家一一揭开当年的设计要点。(Ps:乍看起来,朴实无华,大巧不工。)

1、神奇飞轮

他们采用一种“飞轮”的方法去收集和分析系统数据,以便于可扩展性的实现。他们的工作流程是一个不断循环的过程:识别瓶颈→修复瓶颈→喝水→睡觉。这种方法好处在于避免了对高端硬件的需求(不用大规模部署),降低了硬件成本。

可扩展性循环(Scalability loop)

继续阅读YouTube 仅用 9 名工程师就能支持每天 1 亿次视频观看的 11 个原因

发布于