混 乱 的 系 统
我看过很多，自己也做过一些糟糕的事情，产生了很多混乱的，不可维护的系统，那些系统真的象垃圾，说得严重些，更象地狱，他让一个又一个的维护者前覆后继，并为此而蒙羞，但终于有一天轰然倒下，完成了苟且的一生。我们来粗粗的分析一下这些混乱的系统。
一、表现形式
1． 功能杂合导致的混乱
系统分析人员（或是程序员本身）为了一时的方便或是为了在一个特定的场景中盲目的将一些不想关的功能集在一起处理。
2． 功能细分不够导致的混乱
通常是在同一个过程处理了过多的业务环节，将一些不相关的功能放在同一个过程处理导致的代码过长，同一过程业务流程太复杂引起的混乱
3． 系统公共功能公共处理引起的混乱
由于没有人总体分析（或是有分析但不实施），将各个模块共用的功能析取出来建立公共的处理模块库，而是各个模块自行处理导致同一个业务有多份代码副本，并且有可能有不同的处理流程而导致的混乱。（如身份验证、加解密、传输协议等功能）
4． 业务流程混乱导致的系统混乱
业务流程的混乱引起的混乱除了第三点所述的以外更多的是一个管理方面的问题，很多企业本身的业务都很混乱和随意，并且系统在设计时并没有让领域专家参与，或是系统设计开始并不混乱，但在实施中却受到管理者的左右终于变得混乱。
二、原因分析
1．缺乏系统分析阶段
很多系统并没有经过分析阶段（需要分析、系统总体设计、系统详细设计），在他们接到系统后的第一天就说：“coding now”，当然灾难也就开始啦，但如果coder是真正的Veteran，并且系统不是复杂得超过其个人能力，也能出现快而精致的作品，但这多半是一个梦想，并且即便如此，快而精致的作品也并不是好维护的，维护者通常并没有Veteran那样的资历，所以快而精致的作品最终也会走上混乱的道路。
2．代码过程没有全程把握
现在一般的团队在接到项目后通常超过了最原始的“coding now”，能坐到会议室讨论，也会到现场调研，但是在设计书出来后大家就以为系统就同设计书一样完美，他们不关心程序员在怎么做，也没有实时的听取程序员的意见做修正设计，当然最终程序员会自己“修改”，有时这种修改是更好的设计，有时不是，但不管怎么样系统不再是设计方案里的那样啦，人们在系统交付的时候或是在系统维护的过程中才发现了这个事实，那时程序员可能已经到了另一个位置。
3．不视领域知识
IT行业的人不是领域专家（当前除了IT行业本身），当你做企业应用时一定要摆正自己的心态，计算机系统是一个工具，是实现业务目标的，我们的位置为辅，领域专家为主，必须尊重他们的意见，必须具有这样的心态。
5． 不视实施过程
好的系统、好的实施才能让你避免因为你的系统而蒙羞，避免你的系统才为地狱，对此我不想多说。
三、解决方案
这个留给我们一起讨论吧！
