Перейти к содержимому

#Руководства/практика

Сегодня 0 материалов
19.12чт
05.12чт
21.04вс
  1. Jesse Vincent38

    让 LLM 起草我的 commit message

    Jesse Vincent 基于朋友 harper 的工具改造出一套 LLM 自动起草 commit message 的方案,调整了提示词、git hook 和模型 temperature,并向 LLM 提供完整文件上下文。他使用 gpt-4-turbo、temperature 0.02、seed 1,约 90% 的情况下仍需手动修改,但改动较小且 commit message 更详细。

    Ожидает перевода

12.04пт
19.01пт
  1. Jesse Vincent22

    KiCAD 8 用 kicad-cli 取代 500MB Docker 镜像生成制造文件

    KiCAD 8 首个 Release Candidate 发布后,作者用一段由 LLM 代写的 shell 脚本,通过 kicad-cli 一条命令导出 gerber、PDF 原理图、BOM、坐标文件、STEP 3D 模型和钻孔文件并打包成 zip。此前他为此维护过一个 500MB 的 Docker 镜像,靠无头 X server 模拟点击 GUI 才能生成原理图和 BOM。

    Ожидает перевода

29.11ср
  1. Martin Fowler · Exploring Generative AI62

    如何应对编码助手不可靠的问题

    Martin Fowler 针对编码助手不可靠带来的代码质量下降和浪费时间两类风险,提出一套评估建议可信度的自问清单:反馈回路是否够快、是否可靠、出错的影响范围有多大、是否需要很新的信息。

    Ожидает перевода

26.08сб
25.08пт
  1. Ryan Lopopolo36

    做最简单可行的事:一位工程师谈如何用最小方案破解本地化项目设计僵局

    面对一个12名工程师参与、前5周未写一行代码的 Web 与移动端本地化项目,作者主张“做最简单可行的事”:只处理 happy path、尽量打桩、推迟行为定义。团队随后一周内用 react-i18next 和两个硬编码 JSON 文件,让 Web 与移动端设置页、登录页和仪表盘实现德语与英语切换,并以每周手动拉取翻译快照提 PR 的 toil 替代自动化流水线。

    Ожидает перевода

10.08чт
  1. Martin Fowler · Exploring Generative AI32

    编码助手无法取代结对编程

    Thoughtworks 的 Martin Fowler 撰文指出,GenAI 编码助手只能覆盖结对编程的一小部分收益,GitHub 将 Copilot 称为“你的 AI 结对程序员”是对结对实践的误导。结对编程还能带来集体代码所有权、代码库历史与隐性知识共享、改善团队流动与持续集成,并锻炼沟通、共情等协作能力,这些是大语言模型无法提供的。他建议用编码助手让结对更好,而非取代结对。

    Ожидает перевода

01.08вт
  1. Martin Fowler · Exploring Generative AI52

    行内代码补全什么时候更有用

    Martin Fowler 结合 Thoughtworks 内部使用 GitHub Copilot 的经验,分析行内代码生成在什么情况下更有用。他给出的有利条件包括技术栈更主流、问题更常见、生成片段更小、开发者更有经验、出错代价更低,并指出经验不足的开发者使用这类工具时任务耗时可能反而增加 7% 到 10%。他建议开发者花一段时间在安全区内外实验,逐步建立对工具适用边界的判断。

    Ожидает перевода

27.07чт
  1. Ryan Lopopolo26

    Ryan Lopopolo:如何通过让团队失败来扩展自己的管理半径

    Ryan Lopopolo 作为管理 5 个团队、35 名工程师的 Group Tech Lead,提出用"失败成本"判断哪些项目可以放手让团队自主试错,从而把每周注意力集中在最多 3 件不能失败的事情上。当团队在自主处理遗留基础设施时反复出现 SLA 违规,他转而通过结对写代码、引入可复制的代码模式和代码审查示范来补齐技能缺口。

    Ожидает перевода

14.06ср
  1. Ryan Lopopolo15

    Rust RFC 的反馈窗口:为什么提案不该对所有人在所有阶段开放

    Rust 项目成员在讨论一个有争议的 RFC 时提出,并非所有提案在其生命周期每个阶段都对所有相关方开放反馈。作者由此总结出反馈窗口的实践:用类似根回的方式先建立共识,文档和设计未成熟前不广泛分享,明确反馈截止时间和期望的反馈类型,决策后明确“锁定”并做到 disagree and commit。作者认为,在反馈窗口之外提意见往往收效不佳并引发摩擦。

    Ожидает перевода

13.06вт
19.09вс
24.12чт
15.07пн
03.03вс
  1. Ryan Lopopolo31

    Stripe 资深工程师如何用 nemawashi 构建共识

    Stripe 工程师 Ryan Lopopolo 分享用 nemawashi(缓慢、审慎的共识构建)推动变革的经验:他通过跨基础设施团队的一对一沟通,最终以四行 PR 移除了 AWS 对 EBS 实例类型的限制。这一改动两年后带来 API 性能提升、构建加速、集群效率提高和边缘网络容量增加等连锁效果。

    Ожидает перевода

27.01вс
  1. Ryan Lopopolo17

    用 Rust 构建 Punchtop 的学习反思

    作者用约 3700 行 Rust 和 JavaScript 重新实现了音频游戏 Punchtop,这是他首次正式上手 Rust。他认为掌握内存模型后 Rust 用起来很顺手,开发中仅出现两次 panic,并特别称赞 Clippy 帮助写出更地道、更高效的代码,以及内联测试和 doc tests 带来的便利。

    Ожидает перевода

28.12пт
16.11пт
05.11пн
27.10сб
  1. Ryan Lopopolo12

    Stripe 云成本核算团队如何与财务团队高效协作

    Stripe 云成本核算团队通过与财务团队建立共享数据、双周 DRI 同步和统一核算口径,显著降低了 AWS 成本。双方统一以公开按需价格衡量 AWS 支出、按 xlarge 归一化单位讨论实例用量,并将 EC2 预留实例覆盖率目标提高 10%,同时开始购买 ElastiCache 预留实例。工程侧还构建了自动对账系统,将月度 AWS 发票与成本和使用报告核对。

    Ожидает перевода