阅读后感
看到这篇文章的发表日期是1997年，感觉这本书在讲的比较像现代软件工程的探索阶段的一个总结，题目也比较有意思，大泥球这个词大概能感觉到，当时软件开发的不易，在*上，这个词的意思是：泥泞的大球是一个缺乏可感知的架构的软件系统。尽管从软件工程的角度来看是不合需要的，但由于业务压力，开发人员更替和代码熵，这种系统在实践中是常见的。它们是一种设计反模式。书中用了一个非常恰到好处的比喻：
Shantytowns are usually built from common, inexpensive materials and simple tools. Shantytowns can be built using relatively unskilled labor. Even though the labor force is "unskilled" in the customary sense, the construction and maintenance of this sort of housing can be quite labor intensive. There is little specialization. Each housing unit is constructed and maintained primarily by its inhabitants, and each inhabitant must be a jack of all the necessary trades. There is little concern for infrastructure, since infrastructure requires coordination and capital, and specialized resources, equipment, and skills. There is little overall planning or regulation of growth. Shantytowns emerge where there is a need for housing, a surplus of unskilled labor, and a dearth of capital investment. Shantytowns fulfill an immediate, local need for housing by bringing available resources to bear on the problem. Loftier architectural goals are a luxury that has to wait.
就是，这种缺乏可感知，缺乏结构化的软件系统就好像棚户区（贫民窟）一样，不熟练的劳动力所组成，受制于有限的资源，缺乏组织，并且没有人建设基础设施，没有总体的监管和规划，每个部分不受限制的增长，并且基础设施和体系结构，导致允许系统的一部分侵蚀和污染相邻的部分。Deadline像季风一样隐约出现，建筑的优雅性就完全顾不上了。在我们对联组的alpha阶段中，刚开始缺乏经验也产生一定程度上的大泥球，开发之前对微信小程序的了解不够，没有意识到一些问题，到最后全部完成了，进行联合测试的时候才发现这个问题，导致项目拖了一两天，到最后换了很多不同的解决方案才把问题解决。一定程度上这个问题来源于我们在冲刺之前没有充分的去了解这个平台，属于规划上的失误。
另一个问题在于，由于之前目标是功能实现，所以服务器端全用python实现，这就给我们后期带来了一些隐患，一个是服务器的稳定性，另一个就是服务器代码的运行速度，beta阶段打算使用apache进行处理，也就是如书中所说的大泥球的解决方案重构代码，基本上后端为了服务的稳定与高效，需要将之前的服务功能的部分转移到apache上实现，在这个框架下，就更加的规范化，高效，也变得更加的专业。重构问题上，文中也用了一个非常形象的例子来举例说明：
Atlanta’s Fulton County Stadium was built in 1966 to serve as the home of baseball’s Atlanta Braves, and football’s Atlanta Falcons. In August of 1997, the stadium was demolished. Two factors contributed to its relatively rapid obsolescence. One was that the architecture of the original stadium was incapable of accommodating the addition of the "sky-box" suites that the spreadsheets of ‘90s sporting economics demanded. No conceivable retrofit could accommodate this requirement. Addressing it meant starting over, from the ground up. The second was that the stadium’s attempt to provide a cheap, general solution to the problem of providing a forum for both baseball and football audiences compromised the needs of both. In only thirty-one years, the balance among these forces had shifted decidedly. The facility is being replaced by two new single-purpose stadia.
说的是1966年所建设的亚特兰大富尔顿县体育场，由于所容纳的人数不能满足90年代体育经济数据的要求，不论是什么样的改造都无法完成满足这样的需求，在1997年只能将其拆除重建，和我们的服务器后端代码一样，目前的运行速度是30sec服务一个用户，但随着用户增加，这个用户体验会逐渐的变差，为了能够同时服务更多的用户，对python代码的修改是无法满足这一要求的，只能选择apache进行回炉重造，重新用新的架构搭建一个服务器，使其满足用户的需求。
文中另外比较重要的一点是PIECEMEAL GROWTH，我本身是学自动化的，对反馈就比较敏感，文中提出，在零碎增长中不可忽略反馈所起到的作用，这种机制用到软件工程中也是很有必要的，对于PM对项目的掌控，还是组员之间的团结协作，都大有裨益，我们组在开发对联的时候，就充分的发挥了反馈的作用，这才导致后期的联合测试相对较为顺利。
One of the most striking things about PIECEMEAL GROWTH is the role played by Feedback. Herbert Simon [Simon 1969] has observed that few of the adaptive systems that have been forged by evolution or shaped by man depend on prediction as their main means of coping with the future. He notes that two complementary mechanisms, homeostasis, and retrospective feedback, are often far more effective. Homeostasis insulates the system from short-range fluctuations in its environment, while feedback mechanisms respond to long-term discrepancies between a system's actual and desired behavior, and adjust it accordingly. Alexander [Alexander 1964] has written extensively the roles that homeostasis and feedback play in adaptation as well.
很早之前就听到关于计算机发展的摩尔定律：当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。计算机硬件成本也随之下降，但计算机光是硬件的成本下降也是不行的，为了使得软件的成本的下降，作者提出了一种范式转变称为银弹，是一种基于可重复使用和可互换部件的软件工业革命，它将改变软件世界，就像工业革命改变制造一样。这样的变革在当时是非常的重要的思想，因为当时的软件价格昂贵质量不足，几乎无法管理。
软件开发如果从最初的原则发明并构建它们，而软件领域中的所有内容都是独一无二的，由以前从未见过的模块和例程组成，永远不会再被看到的话，这种话软件价格昂贵，质量不足，无法管理的现实就没法改变。作者在文中问了一个比较形象的例子来说明这个问题：我们在建造房屋时是否会考虑购买完全由独特的定制零件制造的管道系统？显然不会，这个在现实生活中考虑是比较荒谬的，但在当时的软件开发过程中没有意识到。作者所提出的这枚银弹就是市场上缺乏的细粒度的可重用系统软件。这一点其实在游戏开发行业中就是比较鲜明的一个例子，最初的游戏开发都是从0开始写代码，需要什么功能，写什么功能，但随着技术的更新换代，以及游戏行业的发展，游戏逐渐走向更加复杂化，更加逼真的方向上发展，如此复杂的一个系统，要重头开始写，要面对的两方面因素：第一个是开发的困难程度，第二个就是开发的周期。因此细粒度的可重用的代码库就应运而生，也就是后来的游戏引擎，极大的缩短了游戏开发周期，减少了开发成本。游戏作为一个特殊的软件，也得益于银弹。
再举一个例子就是我们组的微信小程序，其中微信提供的小程序框架，小程序api库就是这个银弹在当今时代的一个产物，在这个api库里面，组成小程序的每一个特殊的组建都是一个api，编写一个小程序软件所需要的门槛大大降低，以及小程序的开发周期大大缩短，不需要重0开始写代码，将每一个细微的功能可重构的进行模块化，使得我们不需要去懂得底层代码的实现原理就可以快速的开发微信小程序，可见可重用的组件对于软件开发的作用之大 。正如文中所述：
Building software applications (rack-level modules) solely with tightly coupled technologies like subroutine libraries (block-level modules) is logically equivalent to wafer-scale integration, which is something that hardware engineering can barely accomplish to this day. Yet this is just what every software developer must do.
仅使用子程序库等紧密耦合技术构建软件应用程序在逻辑上等同于晶圆级集成。然而，这正是每个软件开发人员必须做的事情。我觉得虽然现在这件事看起来好像理所应当，但我们这可是站在2019年看2004年的一篇文章呀，当时提出来也是很不容易的。
读了这篇和上面这篇文章，我感觉大师们说的东西真的幽默风趣呀，我查到这篇文章最初是原先是在1986年都柏林IFIP研讨会的一篇受邀论文，后来接着在一系列的刊物上发表了，并且封面用了一些类似电影的恐怖剧照做封面，还附有人狼传说的故事，第一眼坑定看不出来这是一篇严肃的技术类文章，并且还是大师所作，后来还被奉为经典。所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。文中做了个著名的断言：
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productiveity, in reliability, in simplicity.
文中指出，软件的复杂性，也就是软件的开发困难程度，可以分为两类，本质性和附属性，我的理解就是一个是问题抽象出解决方案，另一个是怎么将解决方案在计算机上实现，实现上的困难。作者认为，实现这方面，也就是附属性的困难，会随着工具的改善逐渐淡化，最难解决的是本质性困难，因为这类的活动一般需要我们去思考，缺乏辅助工具。而这种本质性困难，又是由于问题本质上的几个特点造成的：complexity(复杂性)，invisible(隐匿性)，还有confirmity(配合性)，changeability(易变性)。牵扯到计算，各种复杂的操作，并且也没法可视化出来，还要保持各个接口一致，最后就是应用设备，领域，人群不同，很容易变化。
文中说的这些复杂性在做这个对联项目的时候我也有体会，最开始拿到题目的时候，图片需要生成对联，从理论上的计算，到软件架构，再到实现方式可以说都是非常困难的，理论计算上其实也不能算完全的解决，我们的query方法更多的是用图片内容去索引，因此多样性和相关性就会受到干扰，最终实现的效果证明，对于山水图片相关性可以很高，但是对于其他的图片相关性就较差了。软件架构，目前整个后端是用python搭建服务器的方式，也导致一些问题，服务器的稳定性还有速度，没有用到数据库去提交服务请求订单的方式，所以对于服务多人还存在很多问题。我们组的本质性困难看上去解决了，实际上还有很长的路要走。并且，一般情况下附属性困难由客观条件决定了，决定使用微信小程序实现的时候，它提供的api就是我们的辅助工具，但是之前的思路是没有任何的辅助工具的。
CatB – Cathedral and the Bazaar
这是一篇讲软件开发的文章，讲述了两种不一样的开发模式，一种是自上而下，另一种是自下而上的设计模式，也就是大教堂模型与集市模型，这个是怎么来的呢，作者认为，世界上的教堂分为两种，一种是天天开放，从未u导游，从小到大的集市，另外一种就是几代人呕心沥血，几十年建成投入使用的大教堂，这两种建筑模式对应两种软件开发模式，集市这种开放式建设，成本低，周期短，品质平庸，大教堂这种成本高，周期长，品质优异，作者想问，有没有办法，用集市方式造出一个大教堂。
我认为我们团队的做法两者都有，我们有独立自主自己测试开发的阶段，同时也有开放给大家一起找bug的阶段，说我们的开发过程是集市的话，我们没有完全开放，说我们的开发过程是大教堂的话也没有高的时间和成本的投入（冲刺只有10天）。
这本书文字流畅，带着理科生的刻板气息。没有花边，没有伏笔，没有同科研无关的个人生活描述，就像是一份实验报告一样。作者举了一个运动员的例子，并不是所有的经过刻苦训练的人都能成为职业运动员，但是没有这些训练，连触碰职业运动员的资格也没有，而且，通过这些训练，尽管最后无法成为职业运动员，这个过程本身就是一笔财富，可能在这个过程中收获了坚强，勇敢，拼搏的品质。作者在六年的博士过程的前四年一直处于没有idea状态，但是通过不断的总结和反省，梳理了自己的point，然后把脑海的理念实现。我在不管是继续深造还是尽早的出来工作，都是一种选择，我做出来了一个选择，遵循了是内心的感受，然后踏踏实实的去做，这才是最重要的。虽然这个与我们的项目没有很大的关系，与软件工程没有很大的关系，但我觉得对于我们即将进入phd培养的pre-phd班的同学还是很有用的。
A Generation Lost in the Bazaar
文章是写给集市开发的迷失的一带，其实我们还没有真正的经历过集市开发的过程，真正意义上的开源，所以读的时候并没有太多的感受，印象比较深刻的是文中提到的
Qality happens only if somebody has the responsibility for it, and that "somebody" can be no more than one single person
心想，这不就是我们的PM吗？我们组的PM：dacheng一直都很认真负责，我觉得这个项目质量，dacheng在项目中所起到的作用是不可忽视的，每天的开会，总结，大家的讨论都是在dacheng的组织之下的，项目也取得不错的成果。