关于软件的核心,莫被算法和使用技术完全忽悠了_JAVA_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > JAVA > 关于软件的核心,莫被算法和使用技术完全忽悠了

关于软件的核心,莫被算法和使用技术完全忽悠了

 2011/9/19 20:59:59  redhat  http://redhat.iteye.com  我要评论(0)
  • 摘要:关于软件的核心,莫被算法和技术完全忽悠了很多人开发多年,对技术一腔热忱,甚至一些企业,居心叵测的企业,打着“招”最聪明的程序员进行“欺骗”和“误导”,在网络上和乃至社会形成了一种风气,这种风气已经严重影响到软件的开发。计算机自诞生以来,经历了语言上的成熟,我们逐渐把眼光转向了解决实际问题的问题空间,特别是面向对象的语言诞生以来,因为对象的粒度十分恰当好处,一方面我们很容易把一些语言上的技术添加到面向对象,例如多态,继承等等,另外一方面,也极大地方便我们模块化问题模型(封装和抽象我们的问题)
  • 标签:使用 忽悠 技术 软件 算法
关于软件的核心,莫被算法和技术完全忽悠
很多人开发多年,对技术一腔热忱,甚至一些企业,居心叵测的企业,打着“招”最聪明的程序员进行“欺骗”和“误导”,在网络上和乃至社会形成了一种风气,这种风气已经严重影响到软件的开发。

计算机自诞生以来,经历了语言上的成熟,我们逐渐把眼光转向了解决实际问题的问题空间,特别是面向对象的语言诞生以来,因为对象的粒度十分恰当好处,一方面我们很容易把一些语言上的技术添加到面向对象,例如多态,继承等等,另外一方面,也极大地方便我们模块化问题模型(封装和抽象我们的问题),我们越来越认识到,软件的核心是模型,特别是复杂的问题域(Problem Domain)更需要精炼的模型。

在现实的世界,我们知道,对数据的管理能力尤为重要,而算法并非是其中很重要的因素,懂得一些基础算法是对编程有帮助,但是往往非常有限,为了达到软件高可靠性,可重用,易于扩展,易于维护,我们发现,往往不是运算的逻辑实现比较复杂,而是运算逻辑要封装在哪里,放在哪里成了重要的问题。同样的逻辑,放在不同的逻辑水平层次和不同的封装实体(Software Entity)给扩展性,维护性,可测试性产生了巨大的影响,如果做的不好,一起的结果就是带来软件稳定性差,软件成本急剧增加,甚至导致项目失败,公司破产。这就需要我们合理的切分我们的问题,垂直和水平上(参见SoC和AOP),最总归纳出良好的模型,以解决我们所遇见的问题。

关于软件使用到得技术,非常重要,但是不是全部,我们经常看见很多人什么软件都是用过,Hibernate,Spring,Struts,但是往往发现会用和懂技术完全是两回事情,因为他们只知道怎么使用,而不知道为什么使用,导致使用这些技术软件并未给他们带来太多变化。

记得前段时间,一位朋友让我给他们团队的软件做顾问,我看到,他们使用了Spring ORM,每个service方法的代码却都大致如下:

public Result serviceName(…){
    SessionFactory sf = new Configuration().configure().buildSessionFactory();
		//…
}


使用Spring ORM却没有带来一点好处,而且,每调用一次service方法,都会buildSessionFactory(),创建一个新的连接,而他们对Spring ORM的例子却头头是道。这种事严重的只会使用技术框架,却不懂得技术的一个经典例子。

不管是你在开发一款分布式缓存的软件,还是开发一个购物网站,只要你想开发出易于维护,易于扩展,可靠性高的软件,那你就得好好为你的问题域建模。

使用面向对象的语言来开发面向对象的系统,十分不容易,GoF汇总了23个面向对象常用的模式来避免重复的解决类似的问题,但最终还是希望大家自己会使用OO的眼光分析问题,建立模型,因为你遇见的问题和23个经典的问题总是类似有出入的,完全的使用而不加以变化往往引起不好的开发,但如果你学会使用OO眼光抽象和归纳问题,建立合理的模型,那时候,模式还重要吗?

对于模式的学习,请勿流于表面,也请勿认为模式有多神奇,有的人一直使用工厂模式,但是却说不清楚为什么要使用,结果在不应该的场合使用,影响了系统。模式就是对一个常见的问题提出的一个通用的解决方案,常见的问题不至于23个。

别沉浸在百花齐放的使用技术和简单的基础算法中,软件远远不至于如此!
发表评论
用户名: 匿名