Beyond "Clean Code": Why Your Comments Matter2 months agohttps://blog.moertel.com/posts/2026-07-27-beyond-clean-code-why-your-comments-ma...注释是必要的，用于表达意图和'为什么'的信息，这些是逻辑本身无法传达的。Bob大叔声称'注释总是失败的'过于极端，而且可能有害。逻辑只显示代码做了什么，而不显示程序员的意图或决策背后的推理。注释应该用于自然地沟通，而不扭曲逻辑。关于注释说谎或过时的反对意见，比起完全没有注释来说问题更小。注释既能改善好代码也能改善坏代码；它们不是糟糕代码的拐杖。作者挑战批评者：在不丢失信息或扭曲逻辑的情况下删除注释。
Cull your dependencies2 months agohttps://tomrenner.com/posts/cull-your-dependencies/- Log4J 漏洞是一个警示，表明一个广泛使用的日志库（16.8万行代码）如何引入关键安全风险。- 依赖项积累了海量代码（通常超过100万行），每1000行代码估计有15到50个错误，导致导入的代码中存在数千个潜在问题。- 开发者常直接导入完整库以避免编写小型实用函数，增加不必要的臃肿和未知的代码质量。- 存在一种错误假设，即来自官方包管理器的包天生高质量且安全，尽管它们由志愿者维护且没有强制检查。- 由于被认为的最佳实践，依赖项变得根深蒂固并扩散，导致移除困难，漏洞悄悄积累。- 检测未使用依赖项的工具不足，导致过时的包作为臃肿持续存在。- 建议规则：避免添加依赖项，对每个添加要求明确理由和日志记录，并标准化为单一实用工具包。
<antirez>2 months agohttp://antirez.com/news/134最好的代码往往是在程序员本该做其他事情时写成的，这常见于开源项目中。开源软件反映了程序员的激情、喜悦或愤怒，驱使他们追求完美。开源中的用户需求并非关乎金钱，而是反映了对软件质量的共同关心。贡献者帮助改进软件；忽视他们是可行的，但他们的意见源于共同关切。创作者有权控制设计，并拒绝不符合愿景的贡献。将用户互动仅视为金钱交易是错误的；双方都重视质量。编辑者指出，不安的开源开发者可能会发现自己的工作类似于办公室工作。这个悖论凸显了开源编写者对免费代码的关心超过对有偿工作的关心。
Anyone else get a vague GitHub shakedown notice?2 months agohttps://lists.osgeo.org/pipermail/qgis-developer/2026-July/068430.htmlGreg Troxel 收到了 GitHub 发来的一封关于 Code Quality 计费的电子邮件，提到该服务将于 2026 年 7 月全面开放。他怀疑这封邮件是真实的，但感到困惑，因为他没有注册付费计划，也不是 GitHub 赞助者。Greg 质疑是否是 QGIS 使用 Code Quality 可能触发了这封邮件，并询问其他人是否收到了类似的通知或对意外的账单感到担忧。
Why you should not have Managers in your class name2 months agohttps://karankurani.com/writing/post/170793461763/why-you-should-not-have-manage...为类和函数正确命名至关重要，因为它影响代码结构、未来的思维模式、重构和扩展，糟糕的命名会导致技术债务。使用'-er'后缀如'Manager'常暗示设计不良；例如，'ConnectionManager'因承担多重职责变得复杂，而'Connection'本会更清晰简洁。选择精确的名称有助于保持代码整洁、简化扩展和重构、减少复杂性和错误，因此建议在命名上投入额外时间。
Zero-defects code: the prescient Microsoft memo from 19893 months agohttps://digitalseams.com/blog/zero-defects-code-the-prescient-microsoft-memo-fro...微软在1989年发布的《零缺陷备忘录》早在持续集成和测试驱动开发成为主流之前，就倡导了这些原则。备忘录揭示了微软文化中的问题，比如奖励开发人员提交不完整的代码，以及将进度看得比质量更重要。克里斯·梅森认为编写完美的、零缺陷的代码是可以实现的，并强调需要转变思维模式，将质量置于速度之上。提出的关键解决方案包括每天都有一个可工作、可交付的产品，立即修复错误，以及将测试重点转向质量保证而非仅仅是找漏洞。备忘录建议了一些实用技巧，如代码审查、在调试前编写测试、使用断言验证假设，旨在减少错误并提高可预测性。领导层承诺支持现实的进度安排，并抵制为赶工而妥协的压力，强调早期承受轻微压力总比后期出现重大问题时更好。
The Short Leash AI Coding Method for Beating Fable3 months agohttps://blog.okturtles.org/2026/07/short-leash-ai-method/本文讨论了利用AI智能体编写高质量软件的方法，重点介绍了一种适合希望在不牺牲质量的前提下提升性能的专家级开发者的方法。当前流行的AI智能体方法（例如YouTube博主们推广的那些）常常导致低质量代码且缺乏理解，因为AI容易偏离轨道，尤其在训练数据有限的细分领域更是如此。文中介绍了“短链法”，强调开发者的积极参与，包括规划、审查代码差异、必要时拒绝授权以及在小任务完成后提交代码，以保持控制力和质量。针对AI审查，建议结合人工与AI审查，让AI充当代码检查工具，而人类则负责发现更高层次的问题。提交PR时应注明AI使用情况，且作者在提交前应进行彻底审查。