On Long Term Software Development - Bert Hubert's writingsa day agohttps://berthub.eu/articles/posts/on-long-term-software-development/限制并仔细审计依赖项；避免大量小型依赖。大力投资测试，以捕捉因依赖项变动而导致的回归，并支持重构。保持代码简单且平淡；尽早并频繁重构以管理复杂度。不仅记录代码，还要记录设计理念、理由和架构。维护稳定的长期员工团队，而非依赖顾问。考虑将代码开源，以强制执行更高标准并获得外部审查。从一开始就实施全面的日志记录和遥测，用于调试和性能监控。定期审查依赖项的变更、安全问题或新功能。避免追逐炒作的技术选择；优先选择经过验证、长期存在的解决方案。
Stop Using (only) GitHub Releasesa day agohttps://hugotunius.se/2024/01/20/stop-using-github-releases.html作者意外升级了Rust依赖项，但因项目缺少CHANGELOG.md文件而面临困难，仅依赖GitHub发布说明。GitHub发布存在缺陷：分页导致交叉引用困难，它们不属于仓库本身，且若GitHub衰落则可能丢失。仓库中的CHANGELOG.md文件会随代码迁移，应作为发布说明的主要来源。该原则不仅限于变更日志：提交信息应解释变更原因，文档应存储在markdown文件中，任何能以文件形式表达的项目相关数据都应作为文件保存在仓库中。
Command Line Interface Guidelines17 days agohttps://clig.dev/现代命令行程序设计指南，平衡传统 UNIX 原则与人本化改进。作者包括阿南德·普拉萨德、本·菲尔什曼、卡尔·塔希安和伊娃·帕里什，并得到其他行业专家的贡献。指南倡导以人为本的设计，强调可用性、可发现性和同理心，同时不牺牲 UNIX 的可组合性和一致性。关键准则包括使用参数解析库、提供详尽的帮助文本、将主要输出发送到 stdout 并将错误发送到 stderr。输出应默认具备人类可读性，并支持如 --json 的机器可读选项，审慎使用颜色、格式和表情符号。应捕获错误并重写以提高清晰度，提供纠正建议和简易的故障报告功能。参数和标志应遵循标准，优先使用标志而非参数以提升清晰度，并出于安全考虑避免在标志中传递敏感信息。交互性应仅在 TTY 环境中进行，对危险操作设置提示和确认，并配备清晰的退出机制。子命令应保持一致性，避免使用歧义名称，并具备输入验证、超时处理和并行执行等鲁棒性功能。配置遵循优先级顺序（标志 > 环境变量 > 配置文件），分发应倾向于单二进制文件并支持轻松卸载。数据收集需获得明确同意或提供透明的退出选项，建议采用网页文档和用户反馈等替代方式。
Write code like a human will maintain it19 days agohttps://unstack.io/write-code-like-a-human-will-maintain-itLLMs能为你编写代码，减少手动工作，但会导致逻辑重复。不同文件中重复的条件检查会造成维护问题。LLMs从现有代码模式中学习，如果使用了捷径，会强化不良实践。重复的代码会提示模型继续采用相同风格。代码异味积累，使得后续难以提示LLM修复问题。LLMs并非在真空中运作；它们模仿代码库的模式。随着不良习惯被强化，维护变得具有挑战性。编写可维护的代码至关重要，因为LLMs会吸收并复制它们所看到的内容。