阅读文章心得体会
阅读文章心得体会
阅读了几篇文章，感觉大泥鳅这篇文章和我们的团队项目特别贴近，感觉有很多感想想要分享一下，
我想专门就大泥球这篇文章和我们团队项目的改进过程谈谈自己的感悟。
首先文章中说到的大泥球，其引申义在文中是指一个架构随意的、没有明显约束条件的系统，这样的
系统是因为在完成阶段由于各种原因成长失控而导致的结果，为了维护突然出现的各种问题，不断选用权
宜之计在系统整体上进行维修，打上一个接一个的补丁导致整体的无序性，重要的信息在系统的元素之间
被无条件的共享，通常把几乎所有用到的信息变为全局通用的，系统政绩结构可能从来接没有被很好地定
义和设计，即使之前被设计过，也和最开始的计划蓝图相比修改的面目全非。
这一点我深有体会，首先是最开始的个人项目，拿到了问题之后思考了一下，感觉是一个图论的问题，
然后没想太多就开始动笔了，一开始想，我肯定要记录各个节点的邻接信息，那我先定一个结构体来记录
这些信息，写完了以后想了一下，反正最后肯定要写最短路径的搜索，那就先写出来一个再想吧，等把这
些写完了，开始考虑这个问题整体结构是怎样，发现问题好像和我最开始想的有一些出入，路径的搜索好
像没我想的那么简单，那我得把搜索路径的函数修改一下，修改到一半发现，诶呀，我之前定义的结构体
好像也少了点东西，补上去之后再回过头来修改搜索的函数，整个过程就混乱了起来，感觉自己之后在做
的好多工作就是在填之前自己给自己挖的坑，一边后悔自己当初为什么不多想想一边给改的面目全非的代
码上填补丁。就像往代码漏洞上呼上一块泥巴挡住，一块接一块就呼成了一个大泥球。
这一点在文章中也有所体现：
Why does a system become a BIG BALL OF MUD? Sometimes, big, ugly systems emerge from
THROWAWAY CODE. THROWAWAY CODE is quick-and-dirty code that was intended to be used only once
and then discarded. However, such code often takes on a life of its own, despite casual structure and poor
or non-existent documentation. It works, so why fix it? When a related problem arises, the quickest way to
address it might be to expediently modify this working code, rather than design a proper, general program
from the ground up. Over time, a simple throwaway program begets a BIG BALL OF MUD.
系统成为一个大泥球的原因之一是存在很多一次性代码，一次性代码就是指那些快速和肮脏的代码，
旨在仅仅使用一次，然后丢弃，这种代码虽然结构上不够正式准确，并且不存在或者是不良的说明文档，
但是这种代码却经常出现。当出现和这些代码相关的问题的时候，只需要修改这些部分的代码，而不是从
头设计一个适当的程序，随着时间推移，一个接一个补丁打上去，一个简单的一次性程序就补成了一个大
泥球。
这样的行为其实上是对整个系统结构的侵蚀，但是即使的足够良好结构的系统也很容易发生这样的问题
，因为在系统的完善过程中，难免会遇到各种问题的冲击，这些都可能逐渐破坏整体结构，打补丁的行为
如果一直在有增无减那么就会使系统整体陷入一个无法修复的情况，这样的话就跟陷入一个泥沼一样，只
能继续之前打补丁的行为，越陷越深，不断打补丁。这样的后果就是维护起来会变得非常麻烦，因为之前
打的每一个补丁一般都不会有清楚的注释，大多是一次性代码，看到有问题就补上一个，所以在之后的维
护上成本花费就会很大。
在这一点上团队项目也给了我们很好的例子，在阅读上一届的代码过程中，我们也发现了类似的问题，
比如很多类中的函数仅仅是一个空函数，或者函数体里面仅仅是一行调用其他类里面的另一个函数，再者
是加入很多if判断，将所有变量设为全局静态变量等等，这样的后果就是当我们接手代码的时候，根部不
清楚这些判断语句的作用，也不明白这些函数为什么被放在这个类，这个功能到底是在哪个函数里面实现
的，全局变量到底是在哪里被修改的等等，这些工作最终只能通过一行一行调试代码，看调试信息里面哪
一个变量被修改了，这样笨拙的方法去理解。
在建立一个项目的时候保持其完整的结构就十分具有难度，而且在之后的维护过程中依旧保持其完整的
结构同样具有难度，原文中把系统和城池进行类比：
A major flood, fire, or war may require that a city be evacuated and rebuilt from the ground up. More
often, change takes place a building or block at a time, while the city as a whole continues to function. Once
established, a strategy of KEEPING IT WORKING preserves a municipality’s vitality as it grows.
大泥球项目在之后的维护中也十分困难，因为其松散的结构，导致任何重大的突然情况都可能让这个
系统完全的崩溃，让系统保持工作逐渐成为一个艰巨的任务。
在文中提到，我们当然是赞成良好结构的建筑，根据常识我们也十分清楚，良好的结构更能便于建立和
维修，那么如何做到良好的结构，拜托大泥球呢？作者给出的建议如下：
Our ultimate agenda is to help drain these swamps. Where possible, architectural decline should be
prevented, arrested, or reversed. We discuss ways of doing this. In severe cases, architectural abominations
may even need to be demolished.
这一段话给出的建议是为了消耗掉系统中的这些泥沼，在可能的情况下是采取规避的态度，但是在严
重的情况下，我们需要拆除整个结构体，但是在之后的一段作者很快就补充了说明：
At the same time, we seek not to cast blame upon those who must wallow in these mires. In part, our
attitude is to "hate the sin, but love the sinner". But, it goes beyond this. Not every backyard storage shack
needs marble columns. There are significant forces that can conspire to compel architecture to take a back
seat to functionality, particularly early in the evolution of a software artifact. Opportunities and insights that
can allow for architectural progress often are present later rather than earlier in the lifecycle.
作者的原话是“憎恨罪恶，但是爱罪人”，这句话我的理解是，进行一定的修改，这些修改可以保留原
来的部分内容，特别是在项目的初期，而允许架构优化的机会一般在整体的后期出现，折断的理解我可能
不是特别明白，但是大概意思我认为说的是对于出现问题的部分，在早期要有所保留的拆除和修改，而对
于项目进步优化等机会，一般是在项目的后期出现。
在这一点上，我认为我们的团队项目做的很符合这一理论，在我们发现原有项目存在结构混乱、代码
冗余等问题后，我们认为这样的代码很难为后续开发提供高效的环境，所以我们决定对原有的代码进行一
定程度上的抛弃和重新构建，对于部分功能代码，我们选取其最核心的部分进行保留。于是我们把这个作
为我们β阶段的核心目标，我们重新构建了往届的代码，将整体的结构进行了重新的设计，删除了没有被
使用的类，对于核心功能进行改进，填入了新的功能，将功能划分为各个模块，将最终的完整部分组合，
成为了一个结构重新构建、功能填充优化的项目。我认为我们所做的这些部分其实就是在把大泥球解体，
把之前呼上的一块块泥巴洗掉，拿出干净的代码，在上面加上新的功能代码，然后重新组装，把原本的项
目从大泥球里面拔出来，便于之后的发展与维护。
上一届的学长在最后感叹：
警戒下一届的学弟学妹们：
请推倒我们的代码，重新架构！一开始与所有组进行沟通，了解所
有情况之后再来着手，否则就会陷入泥潭之中不可自拔。谨记谨记。。。。。
如果上一届的学长能看到这个博客，我想告诉前辈，我们谨听教诲，将项目从泥潭中干干净净的脱
离了出来，我们不会再被大泥球所困扰了，请您放心。
