关于软件项目开发的思考

摘要: 关于软件项目开发的思考

写在前面：

在说之前，先想想，在做之前，先想想。关于软件项目开发和管理。

1.增量式开发和时刻运行时系统

人月神话的作者,IBM系统之父比较推崇这种开发模式。主要是因为他的可维护性和可拓展性。

增量式开发是指在每个开发阶段，都有一个运行时系统。第一阶段开发的系统只具备最基础的功能，并且并不考虑太多的细节。在完成第一个阶段的开发之后，完成阶段的系统就可以作为一个独立的系统运行，并可以提供给用户使用，这样用户可以体验系统并提出改进意见。

- - - 在开发方面

- - - 可以保证开发团队最快的交付产品

- - - 开发没有太多的顾虑

- - - 不需要开太多的会议去揣测用户

- - - 没有太多的业务烦恼

- - - 在用户方面

- - - 掌握了软件产品方向的主动权

- - - 真正的用户愿意参与进来

- - - 当建议被采纳时如果有奖励等，会主动参与

在第二阶段，根据第一期的系统的用户反馈来进行改进，并推进系统的第三阶段开发。修改第一阶段问题，并向第三阶段扩展。但是，在修改和扩展的过程中，有这么一个原则，对修改关闭，对扩展开放。

现在比较流行的SSM框架，MVC设计模式。我们在工作中一直在用它，大家都会使用它。但是却并不是每个人都能够说出来为什么要这么做，以及这样做有什么好处。在面试的时候，如果面试官问你，你觉得Java语言体现在业务上的最核心的特性是什么。可能有不少人要回答说，继承，封装。继承复用了对象，封装使类更易于使用。当初你觉得SSM框架帮助你封装了好多东西，你可以很方便的使用它来完成你的工作。MVC设计帮助你隔离了视图层，业务分发，逻辑处理，数据持久化，让他们尽可能的降低耦合。但是，可能到后面你会发现，原来你错了。框架的核心不是易用和易学，而是维护和扩展。你会发现，你所做的一切，都是为了业务。而业务最大的特性就是多变，增量式。所以，框架最核心的本质其实维护性和扩展性。

你最大的敌人，不是BUG，BUG只是他的影子，而是你代码的扩展性和动态性。很多时候，我们都忽略了这一点。在进行增量式开发的过程中，随着业务不断的变更和增加，如果你的系统不具备较高的可维护性和可拓展性，他会让你的开发举步维艰，或者让你直接有想重做的想法，因为你已经不能保证它是一个时刻运行时系统了。

2.实践的勇气和失败的勇气

如果你明知道某个东西会失败，或者更乐观一点，你对这个项目并不抱有太大的希望。你还会去做它吗？

你也许会想，我为什么要去做，为什么？他能给我带来什么？反正是失败，做了也没用！

我们总是这样，所以我们难以成长。你要明白，突破是来自于失败，而并不是成功。如果一件事情能成功，那是因为你可以利用现有技术实现它。而现有技术或经验，来自于失败。尽管最终失败了，但是在做的过程中，他解决了一些问题。但是除此之外，还有一个更重要的问题，也许被你忽略了。那就是，你在做的过程中会发现问题并去解决它。你不去做，也就不会想会有什么问题，可能你常说这么一句话，明明是对的啊，怎么就出错了呢？项目会推翻你原有的认知，或者让你掌握更多细节。所以，让你成长。但是我并不是推崇一定要去做一个失败的项目，而是要说，应该多做，勇于实践，即使你认为他可能是错的，但是事实上很多情况下，并不是你想的那样。

3.直立式成长

什么是直立式成长，就是你只需要站起来，走两步就能够实现你的目标。

人的惰性是很大的，我们总以为自己是站起来的。所以给自己定了一个要跳起来才能够实现的目标。其实自己是躺着的，或者坐着的。人月神话中有提到一个团队，在没有时间，人才和金钱的压力下开发一个系统，本来应该只用1年时间开发的系统却用了5年，当系统开发完成后已经过时了。这中间有2个问题，第一个，程序员总是乐观主义者，总是认为我1个月就可以完成任务。但是在实际开发完成时，用了半年甚至一年。如果项目给的时间只有三个月，就需要面临长期的加班，在低效和抱怨中完成工作。第二个，系统开发过程中，完美主义者总是想要做到最好然后才能拿出来，把用户的各种情况都考虑到。到后面，用户广度很大，而你的系统用户深度很大，就这一点已经足够让你失败得无法挽回了。所以，不要太高估自己，不要去揣测用户，用户并不会按照你想象好的路走。因为，你只是躺在那里，并不能看清前方的人走向哪里，将要朝着哪个方向，请试着站起来就可以了，而不需要跳起来。

4.文档编写

不可否则，文档在项目开发过程中很有用。但是其实只是那一小部分重要的文档。

大多数时候，领导们让我们写文档，只是为了写文档而写文档。他所发挥的作用其实并没有我们想象中那么大。沟通成本作为软件行业常常被诟病的一个问题，如果是依靠文档能够解决的，那也就不会那样让人诟病了。更多的时候，我们是在开发完成之后才写文档记录一个接口或者一个逻辑的流程。但是这个文档真的有很大用吗？结果是并不见得。一份文档有用的必要条件首先是要有人看。但是你真的看了吗？大多数时候并没有吧。一份没有阅读的文档那就是一份垃圾文件。创造成本先不算，还容易打乱思绪和思维的延续性。所以，在写文档之前，这个文档是不是有必要写，他能发挥多大的作用。

5.软件项目的架构完整性和概念独裁

在软件开发过程中，我们经常遇到这样一个问题。领导们有一个新的想法。所以他们开会分享了这个想法，然后告诉其它人，大家都可以提提自己的意见。于是，需求确定花费了10天，但是到手的却还不是一个非常明确的需求，然后你开始开发，后面领导们讨论来讨论去，放弃了A领导的想法，改用B的想法。就形成了软件需求常常改，程序员天天加班，程序架构混乱的局面。首先问一下，我们为什么会这样？在结束了皇帝独裁制度后，群体主义和讨论制度渗透到了我们生活中的几乎每个角落。当然也包括开发过程和决策过程。我们总是不那么肯定自己，我们总是想参考一下别人的意见。但是这对于软件的架构设计来说，他是致命的，不是那种一刀致命的。而是那种潜伏期极长的毒药。让你根本无从发觉，就莫名其妙的死了。因此，在项目管理过程中，应该有一个核心决策者或者一个意见方向一致的小组来规划。他类似于概念独裁，但是他是保证软件架构完整性的基本条件。因为在太多时候，你会发现，在一群人的讨论所经历的头脑压榨后，你已经心力交瘁，确实是需要这么一个明确的概念来给你打一剂定心针。这个概念就是软件设计的统一概念模型。