开发一套系统的目的不是要来『让程式设计师写程式』,开发一套系统的目的是要来『解决一个问题』(转)
2007-04-24 18:48
477 查看
VS2005已经正式推出,很多人都看过ASP.NET 2.0的华丽外表!那些可以自由在页面上拖曳的WebPart,可以套用版型的MasterPage,可以为页面穿戴炫华丽衣裳的Theme和skin...。不只如此,大幅节省程式码的登入控制项群组(包含完整的Forms认证机制、MemberShip和Role类别),把过去UI(使用者介面)和资料库存取机制彻底简化的资料存取控制项(DataSource、和xxxxView字尾的超强控制项),这些东西让页面上的表单维护(master-Detail或电子表单)机制变的几乎不用写程式。
再加上VS2005对开发环境的大幅改善(SmartTag、程式码片段、到处都出现的精灵...),总之,开发人员需要作的事情相对的减少,很多朋友看到之后,第一个问题都是,那...以后程式设计师要做什麼???会不会一堆初学者,做出来的网站,都要比累积了很多年的开发老手来的好?难道,很多人就这样要失业了吗?或者,又得要放弃才刚学好的ASP.NET 1.1,重新投入2.0的怀抱?(知道吗?很多公司才刚拟定从ASP转换到ASP.NET的计划...)
现在台湾市场上,还有为数不少的产品都以ASP来开发,过去在笔者很『热心的推广』ASP.NET 1.1的那个时代,已经讨论过这个问题。当您(ASP开发人员),看到其他刚毕业的年轻小夥子,随手写出的系统,都比自己用ASP开发了三天三夜的功能还强,这时候情何以堪?这个问题,到了ASP.NET 2.0将会更加明显。过去ASP.NET 1.1要开发很久(甚至做不出来)的功能,现在到了ASP.NET 2.0很可能已经是基本功能了!相较之下,ASP与ASP.NET 2.0之间的差异则是月来越大,因此对於在业界开发的朋友们,相信很多人早已经自动归入转换的跑道了...
另外则是采用ASP.NET 1.1作为专案开发的人员(类似笔者这种)。过去我们花了很多心思从ASP转换到ASP.NET 1.1,没想到在ASP.NET 1.1才辛苦开发完成的函式库,到了ASP.NET 2.0后,某些变成基本功能,我要说,心里除了很X之外,实在也有点佩服微软,毕竟这是一种进步,过去ASP.NET 1.1上要花长时间才能完成的东西,现在微软则帮你做好摆在眼前等你享用...
有人会说,ASP.NET 2.0这样的改版,让很多开发人员越来越不知道系统内部的运作...,我要说的则是,现在很多开发人员,其实从很早以前就已经不知道系统内部的运作了,现在的问题是,开发人员目前所扮演的角色以及他究竟该不该知道系统内部的运作?
从不知道什麼时代开始,很多从事软体开发的社会新鲜人,早已经不知道(也不需要知道)DOS的存在(和它辉煌历史),也不知道0与1的意义,但是他们开始会物件导向,开始知道SOA架构,可是却从没写过Client-Server的程式,他们生来系统就已经是那个样子,程式在Web上面跑的很自然,至於浏览器怎麼处理HTML,IIS怎麼处理CodeBehind程式码,他都觉得这应该不是他的问题...
如果你对照ASP.NET 2.0的很多功能,你会发现这个现象异常明显,从很多角度来看ASP.NET 2.0+VS2005这样的组合,已经有点像『整合了程式产生器的程式语言』,而新增的很多炫丽套件,则根本有点像是网路上的网站样板或是模组...,不知道这个现象是否是微软冲著网路上越来越多的免费资源而来,但是不可否认的,这样的组合,确实会为很多初阶开发人员节省不少时间。
回到前面的那个问题,当我们讨论到这样的改变对於程式设计师来说,究竟好不好?笔者除了建议采用其他开发工具(ASP、JSP、PHP...)程式设计师,一定要花点时间来了解ASP.NET 2.0之外(根据笔者的经验,同时会去涉猎两种以上开发工具的人真的不多...),也建议从ASP或是ASP.NET 1.1转换到ASP.NET 2.0的开发人员必须深思一个问题:『你认为自己未来的角色是什麼?』(是写程式的人?还是开发系统的人?)
根据不知道哪里的DM,据称ASP.NET 2.0开发一套系统,比ASP.NET 1.1约减少70%的程式码,有没有很夸张?笔者要说,根据我自己测试的结果,虽然不敢说到70%,但是节省的时间绝对超过一半!
一半!一半的意思是什麼?一半的意思是,过去老板要请两个人,现在只需要请一个!那理论上,ASP.NET 2.0的开发人员应该要比ASP.NET 1.1或ASP要值钱一点,但是,以后当大家都使用这个开发工具,那还玩什麼?我要说的是,程式设计师要注意自己的『Value』!
我们回忆一下,当开发一套系统的时候,开发人员花了多少的时间在做商业核心的部分?我们所谓的核心,不是资料库的基本存取、不是画面的调整与呈现、不是那些写过一次之后,另外一只程式只需要小改一下就可以用了的部分。而是这套系统的核心,例如MRP的物料相关运算,例如CRM的客户评等运算...等。一套系统里面,一定有一些商业逻辑,是这个系统里面最重要的部分,是这个系统要达成的『目的』,其他的环节则都是配合著这个『目的』而来的。资料库,只是为了存放资料,UI,只是为了让使用者有个操作环境...,这些其他的东西不是不重要,而是因为模式固定,所以开发的成本越低越好(也就是花的时间和钱越少越好)!
从ASP到ASP.NET 2.0的转变就是这样(事实上所有开发工具的改版目的都是这样,从Windows到Java亦是,从VB到VB.NET又何尝不是!),请不要忘记,开发一套系统的目的不是要来『让程式设计师写程式』,开发一套系统的目的是要来『解决一个问题』。因此系统的重点是能否解决问题,而不是这套系统宣称花了几万个工时,内含几千只程式,包含上百个模组...。一个CRM系统画面做的再漂亮,记忆体使用再精简,资料库运算再迅速,找出的目标客户永远无效(不购买)那要系统又有何用?
时至今日,开发工具已经可以为我们节省绝大部分的时间(特别是花在与程式核心运算无关的开发时间),因此我们回顾从ASP到ASP.NET 2.0,我们越来越不需要花时间在调整UI、在写前端JavaScript、版型和版面可以透过MasterPage和Theme快速完成,资料库存取可以利用DataSource大幅减少程式码,WebPart可以帮助我们迅速做出一个炫丽的Portal,Login控制项可以让我们使用现成的会员管理机制...这一切的一切,都只有一个目的,缩短开发人员花在系统『非核心程式码』的开发时间。
整个物件导向程式设计的目的也是,希望程式码『可重用』,缩短开发时程,让开发人员专注在开发系统的核心,最理想的状况或许是,开发人员不要管与系统核心无关的程式,而多花点时间在核心的运算逻辑。回顾一些专案,您会发现,很多时候我们花在『主要目的』的时间远低於『次要目的』 。举例来说,一套薪资处理系统,计算薪资的程式码数量(核心功能),远低於系统内『产生报表、资料库存取、使用者介面的调整和控制』(次要功能)的程式码数量。当然,这些附属或次要功能不是不重要(当产品的主要功能没啥特色,人人都可以开发的时候,就会开始比较次要功能,例如我比其他竞争对手多了两支报表~~哪怕这两支报表一年只用一次,也会变成产品『特色』),但是别忘记,从过去的例子我们可以发现,一套系统能构脱颖而出,绝大部分的原因都不是因为次要功能特别强,而是主要功能与众不同。
也因此,开发工具一直在致力做一件事情(事实上,整个软体工程也一直在做这件事情),就是让开发人员花少一点时间在次要功能上,而能够把省下来的时间,多开发(或研发)一些具有真正价值或与众不同的主要功能!可能是更强的运算逻辑、更抢眼的创意、更体贴的设计...等。至於只需要花苦工就可以完成的部分,还是交给开发工具(或程式产生器)吧。ASP.NET 2.0所有的新功能,几乎都是针对这些部分而来,我们期待开发人员,能够把省下来的时间,投资在更有创意和价值的事情上。
甚至,哪怕是把省下来的时间花在多陪陪家人都好~老实说,在台湾写程式其实真的挺辛苦的,赚的钱不多,工时却很长,又不受重视,也因此开发人员自我价值的提升和成长,是很重要的,如果新开发工具的出现,能够有效的节省我们的时间,那是令人兴奋的,但若开发工具的出现,却取代了你的价值,则是令人感到遗憾的,学习和成长,加上一点点的创意,依旧是奠定自己不变价值的基础。
再加上VS2005对开发环境的大幅改善(SmartTag、程式码片段、到处都出现的精灵...),总之,开发人员需要作的事情相对的减少,很多朋友看到之后,第一个问题都是,那...以后程式设计师要做什麼???会不会一堆初学者,做出来的网站,都要比累积了很多年的开发老手来的好?难道,很多人就这样要失业了吗?或者,又得要放弃才刚学好的ASP.NET 1.1,重新投入2.0的怀抱?(知道吗?很多公司才刚拟定从ASP转换到ASP.NET的计划...)
现在台湾市场上,还有为数不少的产品都以ASP来开发,过去在笔者很『热心的推广』ASP.NET 1.1的那个时代,已经讨论过这个问题。当您(ASP开发人员),看到其他刚毕业的年轻小夥子,随手写出的系统,都比自己用ASP开发了三天三夜的功能还强,这时候情何以堪?这个问题,到了ASP.NET 2.0将会更加明显。过去ASP.NET 1.1要开发很久(甚至做不出来)的功能,现在到了ASP.NET 2.0很可能已经是基本功能了!相较之下,ASP与ASP.NET 2.0之间的差异则是月来越大,因此对於在业界开发的朋友们,相信很多人早已经自动归入转换的跑道了...
另外则是采用ASP.NET 1.1作为专案开发的人员(类似笔者这种)。过去我们花了很多心思从ASP转换到ASP.NET 1.1,没想到在ASP.NET 1.1才辛苦开发完成的函式库,到了ASP.NET 2.0后,某些变成基本功能,我要说,心里除了很X之外,实在也有点佩服微软,毕竟这是一种进步,过去ASP.NET 1.1上要花长时间才能完成的东西,现在微软则帮你做好摆在眼前等你享用...
有人会说,ASP.NET 2.0这样的改版,让很多开发人员越来越不知道系统内部的运作...,我要说的则是,现在很多开发人员,其实从很早以前就已经不知道系统内部的运作了,现在的问题是,开发人员目前所扮演的角色以及他究竟该不该知道系统内部的运作?
从不知道什麼时代开始,很多从事软体开发的社会新鲜人,早已经不知道(也不需要知道)DOS的存在(和它辉煌历史),也不知道0与1的意义,但是他们开始会物件导向,开始知道SOA架构,可是却从没写过Client-Server的程式,他们生来系统就已经是那个样子,程式在Web上面跑的很自然,至於浏览器怎麼处理HTML,IIS怎麼处理CodeBehind程式码,他都觉得这应该不是他的问题...
如果你对照ASP.NET 2.0的很多功能,你会发现这个现象异常明显,从很多角度来看ASP.NET 2.0+VS2005这样的组合,已经有点像『整合了程式产生器的程式语言』,而新增的很多炫丽套件,则根本有点像是网路上的网站样板或是模组...,不知道这个现象是否是微软冲著网路上越来越多的免费资源而来,但是不可否认的,这样的组合,确实会为很多初阶开发人员节省不少时间。
回到前面的那个问题,当我们讨论到这样的改变对於程式设计师来说,究竟好不好?笔者除了建议采用其他开发工具(ASP、JSP、PHP...)程式设计师,一定要花点时间来了解ASP.NET 2.0之外(根据笔者的经验,同时会去涉猎两种以上开发工具的人真的不多...),也建议从ASP或是ASP.NET 1.1转换到ASP.NET 2.0的开发人员必须深思一个问题:『你认为自己未来的角色是什麼?』(是写程式的人?还是开发系统的人?)
根据不知道哪里的DM,据称ASP.NET 2.0开发一套系统,比ASP.NET 1.1约减少70%的程式码,有没有很夸张?笔者要说,根据我自己测试的结果,虽然不敢说到70%,但是节省的时间绝对超过一半!
一半!一半的意思是什麼?一半的意思是,过去老板要请两个人,现在只需要请一个!那理论上,ASP.NET 2.0的开发人员应该要比ASP.NET 1.1或ASP要值钱一点,但是,以后当大家都使用这个开发工具,那还玩什麼?我要说的是,程式设计师要注意自己的『Value』!
我们回忆一下,当开发一套系统的时候,开发人员花了多少的时间在做商业核心的部分?我们所谓的核心,不是资料库的基本存取、不是画面的调整与呈现、不是那些写过一次之后,另外一只程式只需要小改一下就可以用了的部分。而是这套系统的核心,例如MRP的物料相关运算,例如CRM的客户评等运算...等。一套系统里面,一定有一些商业逻辑,是这个系统里面最重要的部分,是这个系统要达成的『目的』,其他的环节则都是配合著这个『目的』而来的。资料库,只是为了存放资料,UI,只是为了让使用者有个操作环境...,这些其他的东西不是不重要,而是因为模式固定,所以开发的成本越低越好(也就是花的时间和钱越少越好)!
从ASP到ASP.NET 2.0的转变就是这样(事实上所有开发工具的改版目的都是这样,从Windows到Java亦是,从VB到VB.NET又何尝不是!),请不要忘记,开发一套系统的目的不是要来『让程式设计师写程式』,开发一套系统的目的是要来『解决一个问题』。因此系统的重点是能否解决问题,而不是这套系统宣称花了几万个工时,内含几千只程式,包含上百个模组...。一个CRM系统画面做的再漂亮,记忆体使用再精简,资料库运算再迅速,找出的目标客户永远无效(不购买)那要系统又有何用?
时至今日,开发工具已经可以为我们节省绝大部分的时间(特别是花在与程式核心运算无关的开发时间),因此我们回顾从ASP到ASP.NET 2.0,我们越来越不需要花时间在调整UI、在写前端JavaScript、版型和版面可以透过MasterPage和Theme快速完成,资料库存取可以利用DataSource大幅减少程式码,WebPart可以帮助我们迅速做出一个炫丽的Portal,Login控制项可以让我们使用现成的会员管理机制...这一切的一切,都只有一个目的,缩短开发人员花在系统『非核心程式码』的开发时间。
整个物件导向程式设计的目的也是,希望程式码『可重用』,缩短开发时程,让开发人员专注在开发系统的核心,最理想的状况或许是,开发人员不要管与系统核心无关的程式,而多花点时间在核心的运算逻辑。回顾一些专案,您会发现,很多时候我们花在『主要目的』的时间远低於『次要目的』 。举例来说,一套薪资处理系统,计算薪资的程式码数量(核心功能),远低於系统内『产生报表、资料库存取、使用者介面的调整和控制』(次要功能)的程式码数量。当然,这些附属或次要功能不是不重要(当产品的主要功能没啥特色,人人都可以开发的时候,就会开始比较次要功能,例如我比其他竞争对手多了两支报表~~哪怕这两支报表一年只用一次,也会变成产品『特色』),但是别忘记,从过去的例子我们可以发现,一套系统能构脱颖而出,绝大部分的原因都不是因为次要功能特别强,而是主要功能与众不同。
也因此,开发工具一直在致力做一件事情(事实上,整个软体工程也一直在做这件事情),就是让开发人员花少一点时间在次要功能上,而能够把省下来的时间,多开发(或研发)一些具有真正价值或与众不同的主要功能!可能是更强的运算逻辑、更抢眼的创意、更体贴的设计...等。至於只需要花苦工就可以完成的部分,还是交给开发工具(或程式产生器)吧。ASP.NET 2.0所有的新功能,几乎都是针对这些部分而来,我们期待开发人员,能够把省下来的时间,投资在更有创意和价值的事情上。
甚至,哪怕是把省下来的时间花在多陪陪家人都好~老实说,在台湾写程式其实真的挺辛苦的,赚的钱不多,工时却很长,又不受重视,也因此开发人员自我价值的提升和成长,是很重要的,如果新开发工具的出现,能够有效的节省我们的时间,那是令人兴奋的,但若开发工具的出现,却取代了你的价值,则是令人感到遗憾的,学习和成长,加上一点点的创意,依旧是奠定自己不变价值的基础。
相关文章推荐
- 解决安装微信开发工具显示 ‘当前系统不是安全代理’问题
- 面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了;面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为(转)
- Android开发 调用系统相机相册图片功能,解决小米手机拍照或者图片横竖相反问题,及小米手机相册图片路径问题
- 图书管理系统开发--问题解决
- 解决当把系统自带的UIImagePickerController 作为一个uiviewcontroller时有20像素间隙的问题
- 今天终于解决了一个头痛了两天的地图开发问题
- 解决MAC系统在做微信开发时候tomcat无法使用80端口问题
- 【技术文档】开发一个人力资源管理系统遇到的问题及解决的方法
- 最近做的一个linux下的聊天系统,遇到的一些问题及解决办法
- spring,springMVC的优点和区别 spring 是是一个开源框架,是为了解决企业应用程序开发,功能如下 ◆目的:解决企业应用开发的复杂性 ◆功能:使用基本的JavaBean代替EJB,并
- 一个想法:成立草根技术联盟对开发人员进行技术定级解决企业员工招聘难问题!
- “在系统启动时至少有一个服务或驱动程序产生错误”,终于解决这个其实很简单又很烦人的问题
- MOSS 2010 Content Type(内容类型)开发中的一个问题及其解决方法
- 督导系统项目开发过程的问题及解决
- 用友nc65 uap开发中系统出现卡,慢等问题解决思路一(临时合同节点处理)
- 九度奥运排序问题,本周博客系统开发遇到一些问题的解决
- 解决克隆系统网卡名字不是默认eth0的问题
- 开发Struts 2项目遇到的一个问题,就是在struts-tags标签库下没有了s:datetimepicker标签的解决办法
- C++开发一个数组类——解决原生数组的安全性问题