#程序员提效技巧##如何高效开发软件# 作为一名程序员，Evan Hahn经常被产品经理催ddl。 于是，他总结了自己多年的提效方法。整体思路是：不求完美，而是尽快拿出可用版本，在此基础上不断迭代优化。 他表示，代码做到80分即可，关键是按时交付。大多数时候，写出“够用但不完美”的代码，比花时间追求极致更现实。 初版代码可以很粗糙，先写个“能跑”的草稿，就比如： - 充满TODO注释 - 只保证能跑，不处理异常 - 性能差，用print调试，Linter不断报警 - 重复代码多，结构混乱，依赖不清 虽然看起来“不堪入目”，但这样做有几大好处： 1. 尽早暴露潜在问题，减少返工 2. 有些担心的问题其实根本不需要处理 3. 避免过早抽象，确保方案贴近实际需求 4. 能快速向团队展示方向，尽早收集反馈 草稿期的三件重点事： 1. 优先决定“定死”的关键选项，比如用哪个数据库 2. 所有拿不准的都要明确标注TODO，后续集中处理 3. 自顶向下编写代码，比如先搭UI结构，再填业务逻辑，避免陷入细节 能少做就少做，适当压缩场景、合并页面、少处理边界情况，甚至直接问一句“能不能不做这个？” 避免“在代码里乱逛”：很多人修bug过程中容易走神，越修越偏。可以： - 设置计时器，提醒自己评估投入产出 - 尝试结对编程，提高专注度和反馈效率 每次只改一个点。小改动好写、好审、好回滚，还不容易出新bug。大型功能也可以拆成多个补丁，逐个合入。 关键技能也不可忽视： - 读代码是最重要的技能之一 - 数据建模要避免“非法状态”，减少逻辑漏洞 - 写脚本可以显著节省重复操作的时间 - 熟练使用调试器远比到处打print高效 - 适时休息有助于提升持续工作效率 - 优先使用纯函数和不可变数据结构，减少副作用和耦合 - 使用LLM生成辅助脚本是好事，但不要完全依赖它 作者总结道：这是他花了多年才琢磨出来的方法，写代码关键不是把活干完，而是干得快、还能撑得住。 感兴趣的小伙伴可以阅读原文：evanhahn.com/how-i-build-software-quickly/ Grok AI 模型在回答问题之前会检查马斯克的观点
