想清楚和想的太多? 为什么说软件开发中想的越多，做得越烂?
在软件开发行业中有一个很有趣的悖论。
一个部分就是你在写程序之前一定要想清楚，然后再写，只有这样才能写出好的程序来。
另一部分就是，如果你想的太多，你的程序就会写得越来越烂。
在这里，第1部分讲的是想清楚，第2部分讲的是想的太多。
想清楚和想的太多，肯定是有一个区别的，但是如何界定就很难了。
一般来说, 一个新项目的开始意味着一群人磨合的开始。即使有些人已经合作过一些项目了，因为新的项目工作设计和理念的不同，新的思想碰撞是不可避免的，那么磨合也就必不可少了。
磨合是一个比较中性的词语，是指工作中或者思想中有一些冲突，但是最终还会取得一致的结果。
好，下面我们就假设一个具体的项目来分析一下一般的项目组是如何走入困境的。
这个项目的理念和工作目标就是饲养宠物狗。
我来看看一般大型的软件开发团队是如何做的。
一种常见的模式，我称之为通用模块开发模式，就是大而全。这种模式一般发生在传统的大型软件开发团队。
项目负责人开始的时候会要求整个项目组开发出一个放之四海而皆准的程序模块。比如说你的目标是饲养宠物狗。不能上来就写饲养宠物狗。要写通用的模块，这个模块中要配置大量的参数，这些参数来决定饲养的是什么，你除了可以饲养宠物狗以外，还可以饲养宠物鸭，宠物鹅，宠物猫等等。
这样做的目的呢，就是为了一次开发多处扩展使用。比如说你今天开发了一个模块，是饲养动物，通过模块的参数来配置饲养什么样的动物。
今天的客户要求的是饲养宠物狗，那明天的有的客户就会饲养别的宠物。
这样我们就不需要再花额外的时间开发了。
乍一看这样的开发理念是正确的。尤其是在跟一些不懂项目开发的管理层人员来说会非常有说服力。这些管理人员关心的是开发的成本问题，而人是有惰性的，很少有人去通过学习技术来理解整个开发的各个环节，都希望尽快的减少自己的风险，最懒的一个做法就是一次投入多次使用。
实际上在是现实的生活中，当你跟一些人讨论软件开发的时候，他们会首先声明自己不懂技术，然后呢会对项目开发提出这样那样的要求。其中还自然的他们会提到希望开发一次就可以很轻松的应用到别的项目上。这样可以为以后的项目开发节省时间和成本。
你看，这个好像是一个通用的问题。
那问题就是说项目开发中要不要首先去开发通用的模块。
我接触过一些后端开发的高级程序员，他们在做一个项目的时候，创建了13个工程，而实现的功能就是一个用户的注册和读取，里面没有其他的任何内容了。我问为什么这么做？回答是通过创建多个工程，以后扩展的时候，可以节省时间，方便管理。
我们先来看一下这个功能的内容。用户的注册和读取需要如下几个部分，一个是数据库，一个是controller，两者之间需要有一个过渡，我们暂称之repository。加上数据模型。也就是三四个文件就可以了。
如此简单的一个功能，我很难想象能够写出13个工程来。后来我明白了，这就是想清楚和想的太多之间的本质区别。
一些程序员，尤其是一些资深程序员，因为长期以来从事一些部分开发的工作，就像工厂车间里的螺丝钉一样，只负责一个小小的部分。很难整体把握整个项目的走向，往往就过分的强调了程序的规模，忽略了程序循序渐进开发的必要性，往往就生搬硬套的创建出多个工程来。
这样的做法带来一个非常严重的后果就是程序的复杂度非常之高。
我相信大多数程序员对于程序复杂度并不陌生。程序复杂度，会带来很多严重的后果。首先是会带来很多bug。其次是修改bug非常困难。再次就是添加功能会继续增加复杂度。最后直至复杂度超出人力的极限。
好，这里是丁哥开讲。感谢关注，请留言，我们可以继续深入讨论。
网友评论