混乱的系统

[visiond]

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

[ljin]

业务人员（所谓领域专家）经常性的不确定答复，有时会让你痛苦不堪

我们现在就这样

[jobs2001]

清晰的系统总是在清晰的开发流程众产生的。所以
1 开发流程要清晰
2 对流程中的每一步的加工要做好质量检查
流程清晰、控制得力才能生产出好的系统

[goldg]

软件开发技术的缺乏，分析、设计、实现和测试以及项目管理的技术，很多人以前只注意到了实现的技术，当意识到这些问题的存在的时候，开始改进却又茫然。
过程是必须的，任何过程的实现都是以技术为基础的。

[walaqi]

过程改进一开始不失败的大概很少很少。失败又坚持的而且成功的大概也不多。但是多少都可以为以后的工作带来一些好处。。。。

[RedGuest]

虽然没有接触过什么大项目，不过，对楼主的话很有感触
一个项目设计后，不会十全十美，何况，国内很多公司的设计还是拍脑瓜而成的。在程序的编写过程中，往往要改动设计，programmer又没有这个权力，想告诉上级，但往往上级和下级关系不好，或者上级顾及自己的面子等等因素，而往往这些问题当初很微小，将就一点无所谓的，于是没有改成。就只有写下去了，结果就产生更多的问题。中途，找了bug，改了什么，设计的人知道的往往不是很详细。最后，项目不知道成了什么了，和最初的文档大相径庭。

所以，我觉得，软件公司，一定要有自己的项目管理工具，包括最初的设计文档，设计的细化文档，框架，版本管理，bug管理等等，而且，项目组要相互尊重，设计人员跟到底，最好有三个层次：设计人员（对需求很熟悉，很有项目经验），组长（技术要扎实，有一定项目经验），programmer

听过rational的工具rup，不知道有没有人用过，介绍一下如何？
拙见

[leoric]

协作，协作，没有协作，制作一个成功的系统是不可能的。单单依靠programmer？不可能。

解决方案就是沟通与协作。它是在当事人水平不变的前提下提高质量的最好方法。

[intercs]

作一个双方都认可并遵守的开发协议，然后与客户多沟通，对确定的需求让他们签字画押，这样有个纸面上的预定，他们就不会改来改去了。

[RedGuest]

楼上的不可行吧？ 因为客户他自己也不是很清楚他需要什么，你这样做只是强人所难

我虽然工作时间不长，却感受到，写代码其实花的时间很少，关键是技术和沟通，技术可以尽量用成熟的，应该不是问题。沟通就是难点了，不仅仅是和客户要有个和谐的关系（不是冰冷的合同关系和利用关系），还要和底层的开发人员有个和谐的关系（不是领导的关系和压迫的关系）


如果能找几个志同道合的兄弟一起开发，那是何等快意的事情！

[intercs]

楼上的同志你误会了。
优秀的软件是建立在优秀的需求基础上的，只有当用户和开发方都明白要成功自己需要什么，同时也应该知道要成功合作方需要什么时，才能建立起一种合作关系。但随着项目压力的增大，这个共同目标很容易被遗忘，所以在开发的前期要建立一个合作的约定，这些约定包括客户的权利、义务，开发者的权利、义务。不是所有的用户都能成为你的好哥们的，所以这一点很重要。

[consultant]

在国外的团队中，两种人是我们不真正具备的：用户专家，质量控制人员。

[visiond]

很感谢大家这么热情，上面有人提到RUP，RUP我倒是琢磨过，提供了很好的框架，只是实作的时候还得具体情况具体分析，但不管怎么样，大家有时间的话值得看看