软件工程的大泥球

（原文地址：http://www.laputan.org/mud/）

　　大泥球的定义：A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.

　　文中作者拿软件构建和建筑做类比，我觉得是很合理的。软件架构师对应于建筑设计师，要做整体规划，设计“建筑图纸”；开发人员则与施工人员相对应，做具体的构建工作。

　　作者提到What forces drive good programmers to build ugly systems?在后面也给出了答案：

　　Time

　　系统的设计和实现必须要考虑时间因素，建筑的修建有工期的限制，软件的构建同样有deadline

　　Cost

　　引用文中的话Architecture is expensive, especially when a new domain is being explored.成本的影响毋庸赘言。 

　　Experience

　　经验的缺乏会导致很难“discover and develop new abstractions”,从而影响软件架构的复杂程度。（domain experience和architectural experience还不太理解。）

　　Skill

　　程序员之间的技能水平、适应能力以及开发工具的偏好等方面都有差异

　　Visibility

 　　可见性是建筑和软件构建的差异之一：所有人走进一栋大楼就可以看见这栋大楼的内部结构，而软件的内部结构只有开发软件的人才能知晓。

　　Complexity

　　软件本身的复杂度直接影响了设计一个清晰的架构的困难度；the software is ugly because the problem is ugly, or at least not well understood.

　　Change

　　软件的需求一旦改变，软件的体系架构也要相应地改变。

　　Scale

　　项目规模变大，即便采用了分而治之的思想，也无法很好地解决问题

　　这部分提到了艾伦·凯的一句话："good ideas don‘t always scale."

　　Scale的动词含义我特意查了下，衡量，攀登，脱落似乎都不太符合。

　　然后去查资料，发现这句话出现在下面这篇访谈中http://www.folklore.org/StoryView.py?project=Macintosh&story=Creative_Think.txt

　　于是我的理解：好的想法，倘若要付诸实现，不会要求其涉及的规模很大。

　　（附：艾伦·凯Alan Kay是Smalltalk的最初设计者，说过"The best way to predict the future is to invent it."预测未来的最佳方式就是去创造它。）

个人能力有限，所以下面还是摘录几段文中的话，算是记一点笔记。

　　1.The time and money to chase perfection are seldom available, nor should they be. To survive, we must do what it takes to get our software working and out the door on time. Indeed, if a team completes a project with time to spare, today’s managers are likely to take that as a sign to provide less time and money or fewer people the next time around.

　　追求软件的设计完美，是不太现实的。时间和预算都会成为不可忽视的因素，不断提醒着你做出一个能用、按时交付的软件才是正道。一个团队提前完成了一个项目，不要高兴得太早，或许下一个项目的开发时间会有所缩减的！

　　2.focus first on features and functionality, then focus on architecture and performance.

　　3.BIG BALL OF MUD might be thought of as an anti-pattern, since our intention is to show how passivity in the face of forces that undermine architecture can lead to a quagmire. However, its undeniable popularity leads to the inexorable conclusion that it is a pattern in its own right. It is certainly a pervasive, recurring solution to the problem of producing a working system in the context of software development. It would seem to be the path of least resistance when one confronts the sorts of forces discussed above. Only by understanding the logic of its appeal can we channel or counteract the forces that lead to a BIG BALL OF MUD.

　　4.One of mud‘s most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.

　　代码复审或许正是化解“大泥球”的阳光

　　5.Indeed, reviews and pair programming provide programmers with something their work would not otherwise have: an audience. Sunlight, it is said is a powerful disinfectant. Pair-practices add an element of performance to programming. An immediate audience of one‘s peers provides immediate incentives to programmers to keep their code clear and comprehensible, as well as functional.

　　极限编程-结对编程，有人在旁边盯着你敲代码，这就好比有观众在专心致志地看着你在舞台上表演，你会不由自主地投入其中。并且，这样一来代码的清晰度和可读性都会有大幅的提升。我记得结对编程时，我的同伴每敲出一段代码，我一旦不明白就会问她这个是什么意思，是要实现什么功能，在这样的一问一答中，我们对自己写的代码的理解得更清楚了，也使得代码的逻辑性有了一定的保障。毕竟两个人都能看懂的代码的可读性，是要高于一个人能懂的代码的可读性的。

　　6.An additional benefit of pairing is that accumulated wisdom and best practices can be rapidly disseminated throughout an organization through successive pairings. This is, incidentally, the same benefit that sexual reproduction brought to the genome.

　　结对编程的好处：智慧的累加

 　　7.There are three ways to deal with BIG BALLS OF MUD. The first is to keep the system healthy. Conscientiously alternating periods of EXPANSION with periods ofCONSOLIDATION, refactoring and repair can maintain, and even enhance a system‘s structure as it evolves. The second is to throw the system away and start over. TheRECONSTRUCTION pattern explores this drastic, but frequently necessary alternative. The third is to simply surrender to entropy, and wallow in the mire.

　　处理大泥球的三种方式：1在大泥球的基础上，不断修复、改善，甚至增强系统结构；重新构建3干脆放任自流，随它自己去发展。

　　8.Master plans are often rigid, misguided and out of date. Users’ needs change with time.

 　　9.Successful software attracts a wider audience, which can, in turn, place a broader range of requirements on it. These new requirements can run against the grain of the original design. Nonetheless, they can frequently be addressed, but at the cost of cutting across the grain of existing architectural assumptions.

　　又是用户需求的问题。软件构建之前的整体规划往往会随着用户需求的变化而不断改变。

　　我觉得有趣的是描红的那句话。软件做的成功会吸引大量的用户，反过来，正因为用户量之大，才会导致需求更多。所以这个暗示着需求增加也许不是坏事，反而说明你开发的软件很受欢迎？这一点挑明了，程序员们面对需求的改变就不会如此郁闷了吧。

 　　10.Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system.

　　维修需要积累，大修不明智，因为可能会破坏系统

 　　11.Microsoft mandates that a DAILY BUILD of each product be performed at the end of each working day……Indeed, this approach, and keeping the last working version around, are nearly universal practices among successful maintenance programmers.

　　每日构建

　　12.If you can’t make a mess go away, at least you can hide it.

　　接口

　　（后面的漫画，画风很别致呀..可惜没有看懂）

阅读笔记-软件工程的大泥球