在“我的框架比你的更有生产力”一文中，Ken DeLong 逐一审视了提高软件项目生产力的方法。他发现，尽管大家都在宣传框架、语言、项目管理工具等等的重要性，但它们并非瓶颈。Ken 相信，大幅度的生产力提升来自于增进沟通、提高代码的可读性和可调试性。
从约束理论中我们了解到，可以持续增加生产力的唯一方式就是攻克瓶颈。从其他方面所带来的收获与瓶颈限制相比，无疑天壤之别。
Ken 提到，框架在兜售自己的时候，总是提到把项目配置好是多么简单的事情。这点确实很有用，但当我们环顾项目生命周期，配置时间绝非那么重要。
另一个可以优化的地方就是减少编码的时间，但这个看起来对生产力也没有多大影响。固然有些语言、框架或者编程技术可以大量减少人工编码的数量，但这并不能转化为生产力的大幅提升：
我对那种“声明式”编程语言实在信不过。要做到“声明式”的办法很多——一般都意味着在一行代码中塞进狂多功能。那些曾经为了阅读“声明式” 的 Perl 或 C 程序而绞尽脑汁的人，想必会不介意发表一些评论，谈谈把整个程序都塞到一行代码里面是多么精彩绝伦的事情。我要说的是，代码的可读性要比你 用多么牛 x 的方式写代码重要的多。
最近在 Stack Overflow 上有篇帖子，里面谈到雇一些打字更快的人来提高生产力。回帖的人都认为用打字速度衡量开发人员的生产力实在很不靠谱，也对在面试中进行打字测试表示反对。 Martin Fowler 在“结对编程的迷思”中指出，结对编程可以提高生产力而不是降低生产力，其中一部分原因就在于打字并不是编程中最困难的部分。
在指出哪些地方不是编程人员的瓶颈限制之后，Ken 谈到了某些更像是瓶颈的地方：与业务人员沟通、理解现有的代码、调试。
Ken 说到：“推敲需求、理解真正的业务目标、找出从技术上可行的折中方案，这些占了我绝大多数时间”。从他的案例中来看，拥抱敏捷开发中那些增进开发与 业务沟通的实践，才能够最大的提升生产力。例如，把产品负责人跟团队放到一起，或者做到现场客户，这样就可以有更频繁的沟通，人们就可以对业务目标和需求 有更深入的认识。同样，我们还可以把那些重型的需求规范用这些东西来替代：用户故事、谈话、验收测试（有时也被称作可以执行的测试），也会减少对需求的误 解和分歧。
在你的环境中，开发人员的瓶颈限制在哪里？
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论