下一步要做的

不做软件不知道：软件工程还真不是盖的。

软件工程提了几十年了，可是到现在我们仍然和野蛮人狩猎一般拿着最朴素的工具和大自然搏斗，我说中国的计算机技术落后国外几十年，可能有些人还不相信，但是血淋淋的事实就摆在眼前，我们在软件工程上达到的是国外60年代的水平。

我们在软件工程当中急需要解决的问题是需求分析和系统设计（包括数据库设计和对象设计），当然要一步一步来。我现在感觉编码上很难再有跨越式的进步了，我们在使用一个所谓的MVC框架，尽管这个框架漏洞百出，我每天都必须绞尽脑汁的去解决他们在开发中遇到的问题和困难，但是至少我们在努力的尝试去进步。

可是需求分析和系统设计不同，我们对软件工程的认识不够，导致了我们没有把太多的精力放在需求分析和系统设计上，一个完整的项目计划中，需求和系统设计应该占到50%以上的比例，可是我们现在连基本的需求分析文档都不存在，我一直想要买一套系统设计的软件都不能实现，我们把编码当做项目的全部去实现，至少占到了80%以上，尽管我们可能不承认，说我们有详细设计，我们有讨论，可是我们是在没有详细需求的情况下去讨论的，到后来你会发现我们必须为了适应新的需求而去无休止的修改代码，从而导致了我们的编码阶段一拖再拖，久久无法交付使用。

我们在讨论如何进行编码，这个问题是国外50年代以前在讨论的问题，自从出现软件工程之后，国外软件研究者的精力用在了如何尽最大可能的减少编码，而不是如何写出更好的代码，如果我们有一个中间件，只要我们画出类图，所有的代码就自动生成了，那我们的任务就是动动鼠标，拖几个图案就行了，当然这是最理想的状态，我相信随着更多人的努力，我们的编码会越来越少，更多的是对需求的分析和对系统的设计。而我们现在是怎么做的呢：需求分析口口相传，没有人知道真正的有价值的需求到底是什么，我们甚至连规范的需求分析文档都没有见到过，我们曾经写过的需求分析竟然都是为了让别人知道我们能实现什么功能而不是去在乎用户是不是真正的需要，于是我们草草的开始编码，早到提前到调研以前就开始了，也就是基本在不知道任何需求的情况下就要拿出一个已经“基本实现”了的系统，这其中浪费的人力物力劳动力，我很难去计算。

我还记得让我很痛心的济南的那个项目，事实证明我们根本就没有弄清楚那是个什么公司我们就开始为他们“量身定做”一个系统了，当我们拿着做了很长时间做的很帅的东西拿去给他们演示的时候，他们都听傻了，因为他们根本不知道我们在说什么。问题的严重性在于，我们还是没有认识到需求的重要性，如果不是那天晚上我留在济南，第二天早起和曲总闲聊（注意不是讨论需求）的时候，可能我们永远也不会得知这到底是个什么公司，这件事情给我的最大的讽刺就是：我发现我们竟然从来没有好好坐下来讨论一下需求，我们甚至从来都没有了解过他们到底想干什么，我们手头唯一能够依靠的，竟然是几个Excel表格！于是我在回来的火车上开始写我得到的最新的需求，写到最后我不想再写了，因为我发现如果我再写下去我要把以前做的系统几乎全部推翻才行，后来这个项目因为我没有时间而搁浅，我很难想象如果我真正的要做下去的话我需要多大的勇气放弃曾经写的东西重新开始。

再来说说系统设计，我们现在设计数据库使用的还是Sql Server自带的设计工具，更有甚者，有的队友甚至连关系图都不用，直接建表，我们对数据库的理解竟然还没有上升到ER图！我们还是习惯于是用表来描述生活中的实体，而不是数据库设计中提到的Entity，而另一个困扰我的问题是，我甚至都不知道我需要多长的时间才能让大家都习惯于ER图而不是关系图。

如果说数据库设计我们受困于单一的数据库系统，那么系统的设计呢？我们也可以高喊我们是在使用面向对象编程，可是我们现在连类图都不会画，我们连UML中都包括哪些图都闹不清楚，更可怕的是，我们甚至从来都没有意识到这样做有多危险，或者说：我们似乎从来都没有想过要进步，要改变。我现在连使用版本仓库都要告诉他们有什么好处，为什么要用，这不是一个发展的良好的状态。项目管理软件？那就更不要提了。有一次老大问我说：你们都使用什么工具进行项目管理和开发？我很汗颜的告诉他我们其实什么都没有用，在他看来很正常的东西在我看来有些高不可攀了。

我曾经很想买一套数据库和系统设计的工具，我知道其实用不了太多的钱，估计也就是一顿饭钱，可惜，我这个要求也难以实现，好吧，全国一盘棋我也就只能听之任之了。

我下一步的目标就是要规范需求分析，我希望从这个方面对项目进行进一步的规范，我想我需要一个规范的需求调研文档，每次出去调研都必须有调研者和被调研者的签字，最后融合成一个需求分析文档，当需求完成后，进行最后的调研和修改，为的是尽可能少的做出调整。

这个问题我现在只是有了一些想法，我还需要好好思考，进一步完善。如果你有什么好的想法，可以给我留言。