领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
代码行数是致命因素吗？
作者 Niclas Nilsson 译者 郭晓刚 发布于 2007年12月26日
Steve Yegge最近的一个帖子触动了开发社区的神经。Steve主张将代码数量保持在一个绝对的最小值，是软件开发中最重要的事情。依他的看法，即便仅仅出于缩减代码行数的理由，你或许也该牺牲一些设计模式和避免一些重构。如果问题域太大，做不到这一点——那么你可以换到另一种编程语言。
……我相信，相当坚定地相信，对于一个代码库来说，最坏的事情就是它的大小。
Steve认为，代码大小有毁灭性的影响：
多数人可能不认同我的观点：山一样的代码是一个人、一个团队、一家公司所能遭遇的最严重的灾害。我认为代码的重量会压垮项目和公司，它迫使人们在达到一定大小后就不得不重写，明智的团队会尽其所能阻止代码库变成一座大山。
Steve说他本来也可以用代码肿胀的说法，但问题是开发者鉴别不出肿胀，而且他要说的也不是一般偶然遇到的复杂性。
我说的“大小”只是用来代替一个相对更加合适的概念，因为我暂时找不到更好的词汇来表达。我会来回说明这个词所代表的含义，直到你理解我的意思，或者帮我找到一个更合适的词。“肿胀”这个词可能更准确，因为每个人都知道肿胀是不好的，但不幸很多所谓有经验的程序员都不知道该怎么检测肿胀，他们会指着一个剧烈肿胀的代码库，说它瘦得像电线杆一样。
这个帖子的背景是Steve曾经用Java写了一个在线游戏，现在已经达到了500,000行代码，他无法再自己一个人维护这么大的代码库。因此不久前他把游戏撤了下来，现正用JavaScript重写。
我是经历过很多才得出这样的观点。人们很少关心代码库的大小，它并不被广泛认为是一个问题，实际上它被广泛认为不是一个问题。
那工具又如何呢？工具能让代码管理变轻松吗？
这一行的人们对于名义上有助于对付巨大的代码库的各种思路非常热衷，比如能把代码当成“代数结构（algebraic structure）”来操弄的IDE，搜索索引之类。这些人看待代码库的眼光和建筑工人看待一堆土差不多：他们想要能把这堆土随意搬来搬去的大机器。
如果只是说到这个份上，很多开发者都还同意Steve的观点。凡是曾经接手大型代码库的人都清楚，代码行数本身就令人头痛。
如果你有1百万行代码，按每“页”50行算，那就是20,000页的代码。你读完一本20,000页的说明书需要多长时间？仅仅是浏览代码库，尝试辨认出总体的结构可能就要花费数周甚至数月，取决于信息的密度。重大的架构变更可能需要数月甚至数年。
Steve比大多数开发者更激进，他主张出于最小化代码库的目的，避免设计模式和重构可能是好的选择。
重构在Java这类语言身上表现出来的问题，很接近我的命题的中心：重构会使代码库变大。我估计现有IDE所支持的各种标准重构当中，能使代码库变小的不超过5%。
至于设计模式，他写道：
设计模式——至少GoF书中的大部分模式——使代码库变得更大。可悲的是，唯一有助于缩小代码库的GoF模式（Interpreter）被那些程序员全然忽略了，而他们甚至把设计模式的名称纹在了身上。
不久之前InfoQ总结过对依赖注入的争论，Steve把DI也归入了代码肿胀的类别：
像依赖注入这类流行的新Java设计模式，Ruby、Python、Perl和JavaScript程序员可能从未听过。即便听过，他们也很可能（正确地）断定自己不需要它。依赖注入是一种极其精妙的基础架构，它在某些方面令Java更加动态，而那些方面正是更高级语言的本质所在。而且，用不着猜，DI会让你的Java代码库变得更大。
用Java就要忍受它变大。活着就要生长。Java就像是俄罗斯方块游戏，没有哪一块能完全填满其他块造成的缺口，而不造成新的缺口，因此你只能无休止地叠下去。
在跟贴里人们争论得很热烈。很多人觉得解决的方法是把代码分解成库，这样就不需要去理解全部的代码，至少不需要一下子全部理解。Udi Dahan问：
假如你按照这样的方式去组织代码，比如说每次做一件有意义的工作时只需要查阅不超过1000行代码，那么总共有50万行代码是一个大问题吗？
Jay Levitt插了进来，他不同意Udi，还借用了“成层现象（stratification）”这个词来表述他的意思。
我不断看到这样一种反模式，不过还没给它找到很好的名字。我叫它“成层现象”。
简单说，你越是编写高级的库来包装低级的库，低级库就用得越少，于是你就更不了解它们。渐渐地，你甚至忘了它们的存在。到了那个时候，你将（不可避免地）在高级库之上编写更高级的库，目的却是重新实现低级库的功能。
大小重要吗？我们都同意偶然的复杂性是不好的，应当消除；但如果代码实际上是清晰的，却仍然很庞大呢——我们是接受现实，还是采取非同一般的手段，像回避重构或者换用其它编程语言，去缩减代码的大小？大小有多重要？
查看英文原文：Does lines of code kill?译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。
Fall Back
发表人
Guo Xiaogang
发表于
Re: Fall Back
发表人
Guo Xiaogang
发表于
Re: Fall Back
发表人
小刀 凉粉
发表于
Re: Fall Back
发表人
李 佳
发表于
Re: Fall Back
发表人
Boqi Tang
发表于
Re: Fall Back
发表人
Boqi Tang
发表于
Re: Fall Back
发表人
曹 云飞
发表于
-
简单说，你越是编写高级的库来包装低级的库，低级库就用得越少，于是你就更不了解它们。渐渐地，你甚至忘了它们的存在。到了那个时候，你将（不可避免地）在高级库之上编写更高级的库，目的却是重新实现低级库的功能。
我想设计库/API的时候应该留下一个fall back的口子，高级库只针对80%的情况去做简化，剩下的留一条路让人直接用低级库。举例：Spring AOP和AspectJ，Hibernate和JDBC。 -
极端一点的话，对于大多数人：
1、不要自己写库；
2、如果必须自己写库的话，参见第一条。 -
赞同
-
前提是开发人员既要会Spring AOP又要会AspectJ，这个前提不那么容易成立，所以实践起来难度比较大呀。
总的来说，我喜欢短的代码。也有一些例外，有些短代码不易于理解，如果长代码更容易理解的话，我会用长的。 -
极端一点的话，对于大多数人：
1、不要自己写库；
2、如果必须自己写库的话，参见第一条。
就会没有库 哈哈哈 -
没库就光了，不许出屋，哈哈，
-
java项目本来就是多个库组合而成，用一些开源库和自己写库，本质上没什么分别吧，
关键是开发文档要全，对以后的修改很方便
java项目的开发如果没有一个好的领导会很容易成为垃圾项目的，
7 条回复
关注此讨论 回复