问题描述
在实际项目中我们应该注重什么?举个简单的例子,如果要做个图书管理系统,我想这个例子开发人员都不陌生。我们选择的方式方法很多,可以用桌面程序实现、可以用WEB实现,也可以用WPF实现。首先,我们应该考虑应用环境,似不同的应用特点和要求,选择适当的架构;其次,是实现过程中使用的方式方法,可以ORM,可以C/S架构,可以B/S架构,可以用很多可选择的模式,例如工厂模式或看起来很先进的模式等。不同架构或模式的优缺点这里不讨论。以上选择很多种,有的很先进,但反而不适用、复杂化了,设计难度加大,对开发人员的技术素质要求较高,后期不方便维护。牛刀是杀牛用的,用牛刀杀鸡就笨重了。我认为在实际的项目中应该注重考虑实用(工具、方式方法的实用)、快速、稳定、易维护。快速、稳定看起来是相互矛盾,要做到尽量加快项目进度可能在质量保障上会有所欠缺,虽然他们矛盾,但还是能做到尽量弥补快速所带来的不足,项目中还是有章可循的。数据库中字段长度往往是固定的,例如,某个表里有“姓名”字段,假设长度是6,如果姓名长度超过6保存的时候就会出错。在保持之前,我们需要对数据的有效性进行验证,具体的方法很多,你可以在数据层验证,在业务逻辑层验证,也可以在表示层验证,或者在输入时直接控制最大字符长度为6,即只能输入规定数量的字符。这些虽然琐碎、简单,却是任何一个系统必须考虑的,必不可少的。不然数据就可能不规范,超出长度,系统就会出故障,小到一般错误,大到系统灾难。然而,这些简单而琐碎的细节往往有百密一疏的时候,很容易被忽视或遗漏掉其中某一个细节。要找出里面的遗漏需要大量的测试或长时间的使用过程才能发现。到那时可能会影响到客户对软件质量认可、可能会影响到客户对软件的态度、可能会影响到客户对公司的信任、可能会影响到项目的收款,……,现在就不是一个细节那么简单了,你不可能不顾公司质量管理体系声誉而给客户说,Sorry,我们在开发过程中细节出了点差错,有时小细节导致大失败,公司付出的代价是很大的!遗憾的是在很多项目中,我带过的很多开发人员有的认识不到,有的虽然知道应该怎么做但体会不到重要性,还是常犯错,也不能怪他们没站到更高的高度看问题。毕竟各司其职。项目的风险也因此而时时存在。无论是谁开发数据库应用程序的时候都需要用SQL语句存取数据,有人敢说Select语句太简单而不用吗?有人敢说我是高手,不做老板交给我的数据库应用项目吗?应用程序开发都离不开数据存取、桌面窗体或WEB,即使以后流行WPF也一样。这些都是与业务、项目本身无关的,这就是开发易发展的理论基础,是开发易存在的必然。今天跟一个朋友讨论有感而发,我的开发易就是在众多项目实践中产生的,顺便介绍一下开发易能干什么^-^,如果你认为开发中不会犯我上面提到的错误,节约你的时间,可以不用继续看完。开发易更可能帮企业实现其通用业务关系,完成项目的快速开发,开发易定位如此,当然开发易也不是万能的,我从来不吹嘘开发易能带给你技术上的愉悦和体验,但开发易能帮助你完成很多必不可少的工作。减少你的工作量、快速、高效完成常见开发。一个简单的例子说了那么多,开发易能干什么呢?以桌面程序为例,开发易能帮你快速生成桌面上的控件元素,很多细致的工作,小到焦点顺序都帮你完成,你无需自己来回拖拽控件,命名控件、对应数据字段长短有效性验证、排列顺序等琐碎的工作而疲劳不堪。开发易在设计生成窗体的过程中,都为你考虑到了,这样的工具产出来的代码看似简单,但包含了众多成熟的应用,很有用。如果你有相似的体会,我想你会认可。关注开发易http://www.kaifayi.cn/
解决方案
解决方案二:
哦
解决方案三:
-_-
解决方案四:
##关注
解决方案五:
这东西像某人说了一样,真的会毁了下一代程序员了。看似很方便,但只能起到辅助作用。LZ,想必你也是从头一步一步学过来的。如果当初就有这个东西而你用的话,现在的你还会是这个水平吗?按你介绍的一样,琐碎的工作都是开发易来做。那么,即使哪里有错,对于刚入门的初学者来说根本不知道错误在那里。简单的说,从小到大所谓琐碎的事情都是由父母来做而孩子长大了就什么也不会做,就算会做也会不知从哪做起。LZ,起初想法是对的。能方便程序员带来很多方便。但最终我想,用个东西的人不是高级程序员,恰恰相反都是些刚入门的初学者。
解决方案六:
怎么说的跟工业革命一样,不过确实能带来好处还是会被认可的。我们不能抱怨社会在前进,应该让自己也前进来跟上时代的发展。
解决方案七:
引用5楼powercoder的回复:
怎么说的跟工业革命一样,不过确实能带来好处还是会被认可的。我们不能抱怨社会在前进,应该让自己也前进来跟上时代的发展。
確實如此啊,毀掉程序員說的也太邪乎了,照這麼說的話ms就不應該開發vs平台