从一个例子看看一个典型的混乱是如何形成

一个服务程序前后写了几年之久，几乎是在公司的发展之初就做出来。前后根据无数的需求加以修改，其中有技术需求有产品需求。服务程序的控制命令就有上百个之多！看似很雄伟的大楼却少有只言片语，一点文档都没。如今一个功能的逻辑流程有了问题需要修改，但显然不是很严重的问题，只涉及到了部分代码在逻辑层次上是否流畅。或者多几个判断多也可以解决的整个问题。而不必修改逻辑流程，这个时候想当然的是就加几个判断解决这个看似简单的问题。错！

先来看下困境，逻辑流程如果要修改就要检测相关的需求。按照绝对没有，没有用处的代码，反推回来，所有的代码都是有作用的。但用代码来分析当时的功能需求的工作庞杂而难以操作。这里正确的思考方式是收集所有功能需求结合新代码逻辑整理一个套新的代码。如果没有相关的文档没有人会知道这段代码需求是什么！！！这么困难的事情就是连原始的作者也会摇头的。任何人也都不能保证新做的代码不会缺少功能，会和现在运行良好的代码一样运行良好。分析所谓利弊之后大部分人的选择是修改加上几个if了事。

接下来会发生更糟糕的事情，如果一个窗户做歪了，在把窗框弄破来合适窗户，也许还弄了几个洞之后，人们的心态就发生了微妙变化。

一个窗户破掉的车子会在几个钟头之后就拆的无影无踪的。

 

接下来说点技术的事情一个函数拆分和复用。

 

良好的语感是所有编程语言通用的，不论是面向对象还是非面向对象。好比优质的小说，逻辑不清结构混乱的叙述虽然不会让机器混乱，却会让阅读者难以接受。经过多年的沉淀所有编程语言不外乎if,while,for的逻辑结构。有些人可能2句话说清楚，有些人可能说10句。一个函数完成多少功能也完全凭借经验积累。有一种理论是所有函数就只描述最简单的功能。让人不敢苟同。我个人就很讨厌那种串在一起的函数块。函数功能的分割最好是建立在功能的分支上或反复循环执行的大段程序。但个中原则也只能灵活把握，尽量让人能看懂你要说的话。并且自己说的话不会天马行空，让人看着像精神病的咿语。