提高软件开发人员效率的 100 个技巧
我从事软件开发工作已有10年。以下是我总结的关于软件开发人员效率的100条经验。
-
在职业生涯初期，快速学习编程会显著提升你的工作效率。一旦你的编程水平“足够好”，这种影响就会大幅降低。注意观察这种变化何时发生。
-
别太骄傲，不要拒绝尝试“破解你的思维”。许多听起来像是居高临下的提高效率技巧，实际上却很有效。
-
把你的任务写下来，并使用待办事项清单。
-
设定一个切实的目标会让你行动得更快。
-
拖延是正常的。先从写一行开始。
-
适合别人的方法未必适合你。
-
试试番茄工作法，也许对你有用。
-
了解什么能让你提高效率。
-
设定界限，使你能够以高效的方式工作。
-
强大的内在动力和好奇心胜过一切提高效率的技巧。
-
学习如何激发你的内在动力。
-
与他人结对编程，并观看其他人编写代码。你可能会学到一两项能帮助你提高工作效率的技能。
-
你的直觉对你的工作效率影响比你想象的要大。要重视培养良好的直觉。
-
改掉坏习惯需要付出努力。要投资培养好习惯。
-
对所有事情都说“好”会严重影响你的工作效率。你需要设定个人在制品（WIP）上限。
-
过度沉迷于工作会暂时提高你的效率，但如果时间过长，会让你精疲力竭。
-
体育锻炼、健康饮食和充足睡眠不仅不会降低你的工作效率，反而会提高你的工作效率。
-
定期休息（例如，每 50 分钟休息 10 分钟）。
-
长时间工作会让你的大脑开始游离，去浏览推特上的各种梗图和热门评论。
-
确保你有足够的专注时间进行深度工作并进入“心流”状态。
-
尽可能关闭所有通知。
-
进入“心流”状态会让你感觉效率很高，但这并不总是意味着你取得了进步。
-
你可以花几个小时来完善一个抽象概念，但却无法为客户和企业创造任何价值。
-
高效并不代表你就能产生影响。努力去做真正重要的事情。
-
经验越丰富，我就越有兴趣改善我的团队或组织如何协同工作，而不是优化我个人的工作效率。
-
在解决需要协作的技术问题时，限制个人开发人员生产力的瓶颈不是你编写代码的能力，而是团队创造可行解决方案的能力。
-
开发优秀软件产品过程中遇到的大多数问题都需要协作。你的协作能力可能会成为瓶颈。
-
你在某些团队/公司会比在其他团队/公司效率更高。
-
最终，制约你生产力的瓶颈将是你周围的团队和组织。
-
开发人员的生产力和薪酬往往并不一致。
-
有些公司对同样的工作会支付比其他公司更高的报酬。
-
最优秀的“10倍工程师”能够使团队和周围的人的工作效率提升10倍。
-
学会授权和帮助他人。学会为他们的成功喝彩。
-
学会使用自动化工具。消除错误和减轻认知负荷对提高工作效率的影响，比“加快工作速度”更为显著。
-
开发者体验和人体工程学至关重要。
-
使用 Prettier 或 Black 等确定性代码格式化工具自动格式化代码。
-
使用代码检查工具。学习如何编写自定义规则，以适应团队的工作方式。
-
编写自动化测试。人生苦短，何必浪费时间在修复琐碎的bug上。
-
搭建持续集成 (CI) 流水线可能比你想象的要容易。学习如何搭建 CI 流水线将为你未来的每个软件项目节省时间。
-
保持反馈循环快速。
-
自动部署到生产环境。
-
尽量缩短构建时间。
-
确保开发人员能够在自己的计算机上运行测试套件。
-
启用文件更改时自动运行相关测试的功能。
-
使用功能标志可以加快将工作成果发布到生产环境的速度。
-
您可能不需要测试环境。
-
您或许可以从测试环境中受益。
-
这取决于。
-
使用 Vim 的开发者似乎比其他开发者效率更高。
-
不要总是选择那些让你感觉效率最高的任务。这样做会阻碍你的学习，让你感觉自己没有进步。
-
优先进行代码审查。这将有助于你的团队保持高效。
-
每当一位开发者重视代码审查，托瓦兹和卡马克星系中就会诞生一颗新星。
-
“敏捷”一词几乎没有任何实际意义。
-
计算速度和故事点数很少能帮助团队提高生产力。
-
基于数据的小规模、务实的变革胜过“敏捷转型”。
-
计划的目标是将大象分解成一口大小的部分。
-
开发人员通常更喜欢长时间独自完成大型任务。
-
开发人员长时间独自处理大型任务，很少能快速交付最小的增量版本。
-
短期来看，团队合作完成任务的效率往往较低。
-
合作完成任务可以提高学习效果，从长远来看往往也更有成效。
-
对于大型代码库，开发人员的生产力很大程度上取决于他们对系统的了解程度。
-
将大型代码库拆分成模块有助于新开发人员更快地提高工作效率。
-
只有当 API 契约清晰且模块之间真正解耦时，模块化架构才能发挥作用。
-
有时，一名开发人员比其他开发人员效率更高，仅仅是因为他们拥有更多的知识和权力。
-
如果团队中某个开发人员拥有不成比例的知识和权力，就会导致一些开发人员表现不佳。
-
拥有过分知识和权力而造就的“十倍工程师”是一种反模式，会导致优秀开发人员离职。务必避免这种情况。
-
仅通过活动量（例如提交次数或 PR 审查次数）来衡量开发人员的生产力是行不通的。
-
试图将开发人员的生产力简化为单一指标将会失败，并导致开发人员对公司管理层失去信任。
-
衡量单个开发人员的生产力非常困难。如果你试图这样做，很可能会得不偿失。
-
在衡量开发人员生产力时，数据质量至关重要。基于劣质数据做出的错误决策代价高昂。
-
关于软件开发人员生产力的研究其实比大多数开发人员意识到的要可靠得多。
-
关注团队和组织层面的开发人员生产力将取得最佳效果。
-
阅读《加速》这本书并理解 SPACE 框架，将为你理解开发团队的生产力奠定良好的基础。
-
衡量开发人员生产力时，应该使用多个相互补充、相互制约的指标。
-
开发者的主观体验是宝贵的数据。
-
仅仅依靠开发人员的主观经验是不够的，尤其是在试图提高整个组织的开发效率时。
-
提高软件团队生产力的关键在于，在保持高质量和可持续工作速度的同时，努力改善工作流程。
-
衡量团队的周期时间和部署频率将有助于改进工作流程。
-
了解你的团队在修复 bug 和开发功能上花费的时间，将有助于你确定编写测试的优先级、解决技术债务并保持高质量。
-
软件开发是一场马拉松，而不是短跑。要据此优化策略。
-
团队应该负责提高自身的生产力，并有权使用必要的指标和工具。
-
了解哪些因素会影响团队的整体生产力，对开发人员个人大有裨益。
-
大多数团队试图同时做太多事情。你需要设定在制品（WIP）限制。
-
在制品限制可以改善协作，并帮助您交付最重要的内容。
-
在制品限制可以减少对棘手任务的拖延。
-
在制品限制加上良好的优先级排序，可以帮助开发人员处理他们不熟悉的事情，并鼓励学习。
-
从长远来看，鼓励学习能提高软件开发人员的生产力。
-
始终如一的出色工作胜过英勇无畏。
-
那些将英雄主义置于持续出色工作之上的组织，从长远来看表现更差。
-
开发人员喜欢衡量其他一切，唯独不喜欢衡量自己的生产力。
-
早期衡量软件开发人员生产力的尝试，对大多数开发人员来说都毁了这一切。
-
行业创伤很难恢复。
-
如果你想提高公司的软件开发速度，就不要把重点放在衡量单个开发人员的绩效上。
-
学习精益和排队论对于提高软件团队生产力很有价值。
-
咨询顾问们把精益生产毁得一塌糊涂，我们其他人都无法再从中受益了。
-
衡量软件团队生产力可以提升工程团队的幸福感。
-
只有当软件团队积极参与并愿意衡量其生产力时，衡量生产力才能让团队更快乐、更高效。
-
如果开发人员不配合，你的指标就会被操纵。
-
不给予开发人员足够的自主权和工作控制权会让他们感到不满。不要过度管理。
-
快乐工程师的工作效率更高。
在 Twitter 上查看和分享
你可以在这里查看这条推特帖子：
文章来源：https://dev.to/apkoponen/100-tips-on-software-developer-productivity-36if