四天工作制,比你想象的更近了一点

原文:Andrew Keshner - 2024.05.30 软件公司、大型企业甚至警察部门都在试验这一看似遥不可及的概念。 教育软件公司 Kuali 的会议精简,除非绝对必要,员工尽量避免安排会议。即使有会议,也鼓励员工跳过与自己工作无关的部分。在 Kuali,每周工作只有 32 小时,因此高效利用时间至关重要。 公司没有计划恢复传统的周一至周五工作制。 “K……

阅读全文

最佳实践的实践 - API 不应将 HTTP 重定向到 HTTPS

原文:jviide - 2024.05.23 TL;DR: 与其将 API 调用从 HTTP 重定向到 HTTPS,不如让失败显而易见。要么完全禁用 HTTP 接口,要么返回明确的 HTTP 错误响应,并撤销通过未加密连接发送的 API 密钥。遗憾的是,许多知名的 API 提供商目前并没有这样做。 背景 当用户将网络浏览器指向 HTTP URL 时,服务通常会将请求重定向到相应的 HTTPS 页面。通信流的这一未加密部分……

阅读全文

代码界的草台班子 - 一个单文件 11000 行代码的项目

原文:Austin Z. Henley - 2022.04.03 很久以前,在我的第一份软件工作中,我收到了一份内部产品的错误报告,而我甚至不知道这个产品的存在。 结果发现这是一个应用程序,它基本上提供了公司员工可能需要的所有表格。从本质上讲,这是一个包罗万象的资源。你需要向人力资源部举报某人吗?这里有一份表格。你需要为新客户准备一份合同吗……

阅读全文

JS、Go、Rust 错误处理的不同 - JS 可以不用 Try/Catch 吗?

原文:Mateusz Piorowski - 2023.07.24 先来了解一下我的背景吧。我是一名软件开发人员,有大约十年的工作经验,最初使用 PHP,后来逐渐转向 JavaScript。 大约五年前,我开始使用 TypeScript,从那时起,我就再也没有使用过 JavaScript。从开始使用 TypeScript 的那一刻起,我就认为它是有史以来最好的编程语言。每……

阅读全文

谈谈无责文化 - 程序员的锅谁来背

原文:Michael Hart - 2023.09.11 无责文化的概念在其他行业由来已久,虽然具体的历史不详,但可以说,自从 2016 年出版了权威著作《SRE : Google 运维解密》 后,无责文化“正式”成为科技行业的一部分。 我对“无责文化”的总结是:当服务出现故障、事故或漏洞时,假定相关人员的初衷是好的,但要么他们没有获得正确的信息来做出更好的决……

阅读全文

网络传输,请每次都开启 TCP_NODELAY

原文:Marc Brooker - 2024.05.09 (注:不必过于担心这个问题,大部分现代库,语言(如 Go),代理(如 Envoy),都默认设置了 TCP_NODELAY。如果遇到网络延迟问题,可再检查该套接字选项。) 我们已经不再生活在上世纪 80 年代了,谢天谢地! 在调试分布式系统的延迟问题时,我首先检查的就是 TCP_NODELAY 是否启用。不仅仅是我,我认……

阅读全文

软件开发故事 - 我对 CTO 撒谎并挽救了项目

原文:GrumpyOldDev - 2024.04.18 这是几年前的事情了。还记得在我职业生涯的初期,父亲曾告诉我,做好工作往往意味着要在上司的阻碍下做好需要做的事情。他的意思是,你可以让上司成功并感到快乐;也可以让上司做每一个决定,在这种情况下,没有人会成功或快乐。 当时,我在一家财富 500 强公司工作,我们的 CTO 承诺要为一个重……

阅读全文

不抽象:Increase API 设计原则

原文:Increase - 2024.04.26 (注:Increase 是一家提供金融技术服务的公司。) API 资源是 API 的实体或对象。决定如何为这些实体命名和建模可以说是设计 API 最难也是最重要的部分。您所公开的资源组织了用户对您的产品如何工作以及它能做什么的心智模型。在 Increase,我们的团队采用了一项名为“不抽象”的原则来帮……

阅读全文

修复所有 bug 并不能解决所有问题

原文:jeffpsherman - 2024.04.08 在软件领域,如同在制造业,有些问题是由于 bug 或“特殊原因”引发的,而有些则是“常见原因”,这是由于系统设计和实现的性质所导致的。修复 bug 就是移除特殊原因,消除 bug 可以极大地提升软件质量,但它并不会影响“常见原因”问题。 我遇到的一些“常见原因”导致软件的性能问题,包括: 软件……

阅读全文

理想的 PR 长度为 50 行

原文:Greg Foster - 2023.07.25 大多数工程师都有一种直觉,那就是小的代码更改总是比大的更好。逻辑论证也很简单——小的 pull requests 更容易 review,出现错误的可能性更小,从构思到部署的速度也更快。 关于这个问题,我很喜欢几篇论文 - 如果想进一步阅读,可以参考: Small patches get in! Do small code changes merge faster? A multi-language empirical investigation 但是,什么样的更改才算小呢?PR 会不……

阅读全文

最近文章

分类

标签

其它