软件设计的迭代法则

说起软件设计,不得不头痛.

曾有朋友说过,设计好麻烦,想来想去没有结果.

我也曾经经历过这样一个困境.

难就难在没有多少经验.

因为你只想需求,再数据库,再逻辑,再界面.这样一步一步来的话,确实在实现的时候,觉得自己当时的想法,设计全乱套了.

这个是正常的.

一,是你的技术问题,因为你想那东西的时候,很少会考虑你的技术问题,但是设计时,也应该不考虑技术问题,因为一考虑的话,你设计的产品,可能就是自己的暇想,不是别人想要的东西,而由于你的技术问题,或者是页面效果处理,或者是逻辑较乱,就会造成出来的产品,都是一些基本的增删查改.我也问过一些老师,他们说,有些学员开始做项目时,想得很好,但到头来,就只是一些很基础的增删查改,这是因为他们的逻辑越想越乱,又为了应付项目,不得不放弃原先的想法.

二,界面与需求有出入,这个也很正常,计算机的界面,可以说来来去去都差不多,因为来来去去都是那样的控件,就WEB而言,来来去去都是些html表单,所谓的富集控件之类的东西,都是用最基本的div p html表单等拼出来的,虽然可以千变万化,但是拼出来的东西,总会跳不出一个规则,所以这样就会与你的需求有出入

三,你的需求分析没有到位.这个很正常.一谈到需求,很多时候就是你有你说,我有我想,根本就不会怎样互位思考,也很难换位思考.因为你做惯了技术,想时很自然往技术方向钻,这个按我以往经验,应该是搞一个表格,这样统计出来的.而有家的想法就是,我只需要显示统计的信息就足够了.就差一句确认的说话,就很容易存在这样的差异,所以与别人谈话时,如果什么都不会,你就不用谈了,问他拿好基本资料,基本流程,然后就开始着手设计,搞原型开发得了.如果他是老手,那就要什么都谈好,这里是要这样显示,用什么实现,多点确认,也不要过渡承诺,因为这样的人,会坑你的,实现这个很好很好的效果,你答应了,他很高兴,如果你完成不了,那后果可想而之,等,如果又不是菜鸟又不是老手,那这样的人就比较好对付.尽量谈好条件就是了.谈需求的时候,我与我一个朋友都有共适,就是要录音,因为一个人跟他谈完后,再复述一遍后,什么东西都已经变样了,这样出来的产品可想而之,所以录下来,给技术人员去分析,或者给设计者去分析.如果不行,就带一位记性好点的技术人员去吧.这个我也不知为什么,代码想多了,一天要处理那么多东西,要想那么多逻辑,很容易就会健忘了.

 

所以,要这样的话.

设计的时候,就采用选代法则

从需求到实现到界面.然后把想法草图都画出来,最好用图来辅助

然后到了界面后,就想清楚流程,然后反过来想清楚软件的逻辑,想清楚数据库的查法.确认一下,再重头来过.

这样反复几次后,最后一次出来的结果,肯定与第一次出来的结果有很大出入.除非你大脑内存不足,想一个忘一个,那我就没说话可说了.

在确认逻辑方面,你是想用数据型的逻辑还是程序型的逻辑.

就是把所有代表性的东西,都存放在数据库,用增删查改来组合.

还是在程序,用OO的思想,用枚举,用设计模式等组合起来?

不过现在的程序员,都习惯了数据型的逻辑,所以用前者会好点.再说前者的话,也不用考虑太多设计模式.再大型的软件,只不过是用了一些MVC,策略,工厂这几个模式而己.很多框架都有很多工厂方法,那个人家都帮你想好了,所以基本上设计模式方面都不用考虑.

 

这个,我觉得很好用.所以迭代法则,不失为初学者或者经验少者的首选.