BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

关注改善瓶颈限制

| 作者 Chris Sims 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2009年4月1日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在“我的框架比你的更有生产力”一文中,Ken DeLong逐一审视了提高软件项目生产力的方法。他发现,尽管大家都在宣传框架、语言、项目管理工具等等的重要性,但它们并非瓶颈。Ken相信,大幅度的生产力提升来自于增进沟通、提高代码的可读性和可调试性。

约束理论中我们了解到,可以持续增加生产力的唯一方式就是攻克瓶颈。从其他方面所带来的收获与瓶颈限制相比,无疑天壤之别。

Ken提到,框架在兜售自己的时候,总是提到把项目配置好是多么简单的事情。这点确实很有用,但当我们环顾项目生命周期,配置时间绝非那么重要。

另一个可以优化的地方就是减少编码的时间,但这个看起来对生产力也没有多大影响。固然有些语言、框架或者编程技术可以大量减少人工编码的数量,但这并不能转化为生产力的大幅提升:

我对那种“声明式”编程语言实在信不过。要做到“声明式”的办法很多——一般都意味着在一行代码中塞进狂多功能。那些曾经为了阅读“声明式” 的Perl或C程序而绞尽脑汁的人,想必会不介意发表一些评论,谈谈把整个程序都塞到一行代码里面是多么精彩绝伦的事情。我要说的是,代码的可读性要比你 用多么牛x的方式写代码重要的多。

最近在Stack Overflow上有篇帖子,里面谈到雇一些打字更快的人来提高生产力。回帖的人都认为用打字速度衡量开发人员的生产力实在很不靠谱,也对在面试中进行打字测试表示反对。Martin Fowler在“结对编程的迷思”中指出,结对编程可以提高生产力而不是降低生产力,其中一部分原因就在于打字并不是编程中最困难的部分。

在指出哪些地方不是编程人员的瓶颈限制之后,Ken谈到了某些更像是瓶颈的地方:与业务人员沟通、理解现有的代码、调试。

Ken说到:“推敲需求、理解真正的业务目标、找出从技术上可行的折中方案,这些占了我绝大多数时间”。从他的案例中来看,拥抱敏捷开发中那些增进开发与 业务沟通的实践,才能够最大的提升生产力。例如,把产品负责人跟团队放到一起,或者做到现场客户,这样就可以有更频繁的沟通,人们就可以对业务目标和需求 有更深入的认识。同样,我们还可以把那些重型的需求规范用这些东西来替代:用户故事、谈话、验收测试(有时也被称作可以执行的测试),也会减少对需求的误 解和分歧。

在你的环境中,开发人员的瓶颈限制在哪里?

查看英文原文Focus Improvement on Bottleneck Constraints

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

这一点实在是太重要了 by zhang 3

这也应该是衡量一门编程语言是否更好的绝对标准。

不论是声明式或者命令式,能够用让人类的头脑感到亲切的表达方式去表达代码,这才是一门编程语言最关键的所在。

我把这一条排在所有原则之前。

翻译成限制理论不是很好 by Vest Metal

TOC一般翻译为约束理论

Re: 翻译成限制理论不是很好 by Jacky Li

不好意思,翻译的时候没过大脑。。。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT