软件开发中的思维僵化

在J2EE领域来说,SSH/SSI是好东西,是大师们呕心沥血的结晶。但,他也是坏东西。

好的一面,相信不用多说,大量的设计模式运用,极大的降低程序员入门门槛,规范企业应用开发,提高生产效率等等。无论从企业成本抑或个人技术发展方面,都堪称精华之作。

What: SSH/SSI的坏处是什么

现在,我们讨论它坏的一面:

1.降低程序员入门门槛

  你只需要一本《xx天学会xx》,就可以参加工作,赢取其他行业羡慕的薪水。但,这真的好吗?!我们不讲程序是算法和数据结构的结合,不讲高大上的理论和技术,我们都是平凡人。从急需就业的角度讲,能让你快速学会一门技术,这是很好的。但是,当很多平凡人尝到了这个急功近利的甜头后,就觉得技术就是这样,我什么时候用到了再临时抱下佛脚,于是不思进取,混吃等死。越来越多的企业应用开发人员进入了这种状态中。有的人知道这是不对的,可是看到别人是这样,自己随大流,也不去改变。

2.规范企业应用开发

  从企业生产角度看,能够把本来无法规范的事情,形成规范化的流程化的生产过程,这是非常好的事情,可以大大降低生产成本,提高产品质量。但是,流程的副产物就是僵化!

  前面说到,由于入门门槛降低,鱼龙混杂,人员水平参差不齐。对于这种规范,有的人理解他是规范,是参照物,有的人理解他是规定,是必须遵守的准则,再加上不思进取,知其然而不知其所以然,导致这种僵化现象更加严重。

3.大量的设计模式运用

  部分开发人员看到框架这么用设计模式,于是看见什么都像钉子,这个与本篇主题关联不大,这里不多讨论。

Why: 为什么这是他的坏处

道理讲完,我们来看具体的例子。

相信很多人在开发SSH/SSI应用时,都要写jsp,action,service,dao这几个典型模块。那么,我为什么开发一个功能需要写这些模块,我为什么不可以用其他的方式来实现?

有人说,因为这是遵循MVC模式,是针对业务的分层模型,更便于开发维护,及与其他开发人员交流。

那么,我们就从MVC入手,看看为什么要这么做开发。

V:View 视图层,也就是直接和用户交互的那一层,是数据展示层

C: Controller 调度层,指将view层的请求转发给服务层,组合调度服务层实现view层的请求,并将服务层的数据返回view层

M: Model 数据模型,指服务层+数据层,也就是常说的 Service+Dao,主要用来实现业务逻辑,并返回业务数据

上面的理论相信每一个J2EE的开发人员都有看过相关介绍。对于View层,我们不多讨论,无论使用哪种View技术,它的目的比较单一,相对比较容易理解。

这里主要说C和M。

常规的做法是,新建Action,新建Service接口,新建Dao接口,新建ServiceImpl实现Service接口,新建DaoImpl实现Dao接口。

这里就回到主题了,为什么一定要这样建这么多类和接口?

很多初级开发人员不管三七二十一,上级这么要求,就这么写,不懂变通,久而久之,就认为web就应该是这样的.....

或者,混淆C和M的职责,造成业务逻辑混乱,代码大量冗余。

How: 正确的做法

那么正确的做法是什么?

一、职责单一,专注

小到一个方法,一个类,大到一个模块,再大到一个系统,它所做的事情应该是单一的,它只应该专注一件事,一个领域。

Controller调度器,既然称为调度器,就不应该存在复杂的业务逻辑,它的职责应该是单一的,就是负责吧下层的服务模块组合排列,实现view层的数据请求。

Service服务层,既然称为服务层,就应该专注于服务,实现所有的业务逻辑,调用并组合Dao层查询方法,不应该存在调度和直接DB请求。

Dao,Database access Object,数据库访问层,专注数据库访问,不应该存在业务逻辑。

二、模块化

前面说到Controller负责调度,那假如我把所有的业务都写到一个service方法里面,action就调了一个方法,别的什么事情也没做,那这个调度是不是就没用的?(service也一样,如果没有业务逻辑,单纯调用Dao方法)。

需求就像一个奇形怪状的建筑物,你有两个选择:

1.直接造一个这样形状的建筑物,满足需求,下一次在直接造。

2.切分,将这个奇形怪状的建筑物切分成规则形状的积木,然后拼接粘合起来。下一次继续切分,慢慢的你手里的规则积木越来越多,你的代码也会越来越好写,每个新需求,你只要利用现有积木加上一点胶水粘起来即可。这时候action,service的真正功能才能体现出来。

这里说的积木就是模块,这个模块可以是一个方法,一个类,一个封装完整的功能。

相信都能看出来那种方法是好的,但是为什么大多数人都要采用第一种方法来写代码呢?

三、大而化之

在职责和模块讨论清楚后,我们来考虑,view/action/service/dao到底是什么,可否换一种写法,当我们在分层的角度,在来看他们,其实他们只是一种层次的划分,上层依赖下层,下层为上层提供服务,框架定义了我们要这样分N层来写。那我也完全可以自己定义分四层,五层...只要业务需要,于是这就形成了一种属于你自己的编程思想。

上面三步需要一步步走扎实,当然,刚开始肯定是比较困难的,也许比你平常写代码还要困难,也更慢,这时候你需要一种品质:处女座(追求极致)! :)

Then: 终言

我们都知道java世界的工具框架很多,对于工程化开发来说,专注业务,不用造轮子,不错!但是对于开发人员自己来说,就很容易造成思维僵化,入门容易,基础差,提升困难!

这也应该是C程序员转java容易,java程序员转C困难的一部分原因吧!毕竟很多老C程序员是自己维护自己的工具库,而这工具库是自己一个个码出来的。宝剑锋从磨砺出,外部环境的优沃常常造成基础的不牢固。

常常说懒是一个程序员的优秀品质,因为计算机本身就是懒的产物。但是,在夯实基础时,必须苦功夫,笨功夫,追求极致,凡事多问多想几个为什么,你才能有懒的资本。

任何事情都有两面,过犹不及,中庸不等于平庸!

时间: 2024-10-16 14:39:38

软件开发中的思维僵化的相关文章

软件开发中的工作事务与微技能分级评估

工作三四年后,是否感觉自己开始做一些没有提升的事情?是否在做一些低水平重复建设的事情呢? 通过对软件开发中的工作事务与微技能进行评估和分级,可以清晰地理解自己的工作构成.评估自己的当前水平.定位下一步发展的方向和思路. 难度系数 *** 1 1.  完成初级的页面测试: 2.  编写简单非专业的文档: 3.  能够理解基本业务: 4.  日常普通的交流: 难度系数 *** 2 1.  完成一个简单的脚本实现临时需求, 15-20 min: 2.  完成一个函数或方法的单测, 5-15 min ;

彼之蜜糖,吾之砒霜——聊聊软件开发中的最佳实践

"描述一个事物,唯有一个名词定义它的概念,唯有一个动词揭露它的行为,唯有一个形容词表现它的特征.要做的,就是用心去寻找那个名词.那个动词.那个形容词--" -- 福楼拜 (Gustave Flaubert) 我想讲个故事. 很久很久以前(一般讲故事都是这样开头吧), 两个老工程师在一起聊天,谈各自生涯中最自豪的工程.其中一个先讲述了他的杰作: " 我们建造的桥,横跨一个峡谷,峡谷很宽很深.我们花了两年时间研究地质,选择材料.聘请了最好的工程师团队来设计方案,而这又花了五年时间

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

软件开发中几个基本概念

软件开发中几个基本概念 Peixu.Zhu 自己真的深切理解那些经常挂在嘴边的概念么? 抽象 Abstract 抽象的特点是仅存在于思想和理论之中,而非物理或者具体的存在.(不是指C++中的抽象类) 抽象是永存的,不会随着时空而发生变化. 具体 Concrete 具体的特点是物化的或者是具备物理形态,是真实存在的. 具体不是永存的,是随着时空而发生变化的,仅存于具体的时空之中. 具体和抽象的最大区别是是否随着时空而发生变化,即是否存在于我们的四维空间. 实体 Entity 实体是单独的个体事物(

软件开发中,什么是模块化开发?

软件产品可以被看作是由一系列具有特定功能的组件组成,作为一个完整的系统也可以被分解成一系列功能模块,这些模块之间的相互作用就形成了系统的所有功能. 所谓模块是指可组成系统的.具有某种确定独立功能的半自律性的子系统,可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统.每个模块的研发和改进都独立于其他模块的研发和改进,每个模块所特有的信息处理过程都被包含在模块的内部,如同一个"黑箱",但是有一个或数个通用的标准界面与系统或其他模块相互连接. 在软件的模块化开发

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的

软件开发中的流程图

在软件开发中必须经历五个阶段,当然这仅是我个人的看法,我只是个初学者,步骤如下: 1.需求分析 2.算法设计极其分析 3.编写代码 4.测试代码 5.软件维护 对于初学者来说,第5步,可以暂时不用管,当然我们的需要任务就是学好第一步,需求分析,有时候一个软件的开发花费的大量时间并不在于编写代码上,而真正花费时间的是第一步,我们软件开发人员开发的软件并不是为了我们,而是为了客户,因此我们要想开发一个成功的软件,了解客户的需求是非常必须的,客户并不是真正的开发人员,他们的要求没有编程人员的想法严密,