敏捷开发“松结对编程”系列之十：L型代码结构（技术篇之一）
本文是“松结对编程”系列的第十篇。（松结对编程栏目目录）
主题：如何用更少的代码写相同的功能，怎样的团队结构可以推进这一点。
如果你也希望只用国际先进水平的1/4代码量，就实现相同的功能，欢迎阅读本文。
本文会多次切换技术和管理两个平行线，所以结构会负责一些。
前言一直对代码有效性比较感兴趣，所以今天早上重新排布了功能树后，仔细计数了功能点和代码行，大致如下：
代码9883行，来自VS的统计数据（只计算CS文件），加上cshtml中的1420个分号计数（此方法低于VS的统计方法约10%），大约是11200行；
功能点740个，包含33个ILF和127操作（没有区分EI/EO/EQ，每个统一按4FP计算，会略低于标准数值）（关于功能点的计算，请参考http://blog.csdn.net/cheny_com/article/details/7692917 及其下面的4篇文章，火星人产品中未来有这个功能）。
也就是说每个功能点，需要花费15行C#代码。在QSM的网站上，C#的这个数字大约是60（http://www.qsm.com/resources/function-point-languages-table），考虑到能提供这些数据（尤其是基于功能点的数据）的企业都不是等闲之辈，所以15这个数值还是很惊人的（培训课上我曾经提到过大致是19～23，但那时候没仔细整理，是个粗略值）。
代码行/功能点，也就是平均多少行代码可以实现一个功能点，是国际通行的评价编程效率有效性的方法。在MS推出C#的时候，为了证明C#的效率更高，用C#编写了Java的一个例程PetShop（也称PetStore），结果是只使用了Java代码的1/4。Java后来又予以反击，以大致相当的代码效率重写了PetShop（http://www.clintonbegin.com/downloads/JPetStore-1-2-0.pdf）。
当然，后面还会提到更少的代码到底好还是不好的问题。
先解决一个基本问题：如何把代码编得更少呢？
技术手段技术手段不是我们今天说的重点。因为技术手段受限于开发者的水平，极难一下子就提升多少；而且所从事的业务本身也会限制技术手段的发挥。
不过还是大致说几点（另外一些以后再分享）：
1. 限制每个函数的规模火星人中包含2125个Public关键字，姑且将函数的数量大致估算为2000个左右，所以每个函数内的代码，平均低于5行。
小函数有些显而易见的好处：
a. 更容易抽出可复用的部分
先看看火星人手册中提到过的这三个界面：
产生这三个界面（以及另外大约10多个类似的界面），都是下面这段代码：
var ajaxLink = "/MFC/LinkItem2Items/AjaxNode?currentItemID=" + Model.ID + "&leftPadFocusedItemID=" + leftPadFocusedItemID + "&leftPadRootID=" + leftPadViewModel.LeftPadRootID + "&leftPadWhat=" + leftPadViewModel.LeftPadWhat + "&leftPadWhatTypes=" + leftPadViewModel.LeftPadWhatTypes; MvcHtmlString link = Model.Link(outerLink: ajaxLink, updateTargetId: Model.ID.ToString(), onSuccess: "refreshAll(); "); <div id = "LinkedItem@(Model.ID)" class = "@(divclass) toggleLinkedItem @(hideclass) originalLinkedItem hovershowLinkedItemReverse"> @link </div>
所以，不需要担心新手看不懂、不会用的问题，短小而高度封装的代码，反而更容易看懂和使用。
反过来说，我们总不能因为新手看不懂，而让高手都用ABC级别的垃圾代码来编写吧？毕竟应该改变的是新手，而非高手。
其实自己看看，限制函数规模和信息隐匿是一回事情，前者导致了后来。
前面说的计数方法都不太难，但问题是为什么很多团队做不到呢？下一个问题来了：
高手可以这样写代码，新手呢？总不能要求他们也都这样吧？这个，是下篇（管理篇之一）的内容。
