写给所有软件公司和程序员的技术.doc_第1页
写给所有软件公司和程序员的技术.doc_第2页
写给所有软件公司和程序员的技术.doc_第3页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

写给所有软件公司的诡异技术我写这篇文章呢,有两个目的:第一, 拯救所有程序员第二, 提高几乎任何软件公司数倍的开发效率(如果效果明显的话也许是10倍的开发效率吧。在我被许多人认为是说大话之前请允许我详细分析一下软件项目实施中导致开发效率变低甚至于严重耽误或延误了项目交付的原因:1、 程序框架有问题,框架太过简单或不够简单。太过简单:有些公司没有用任何框架,什么都要靠“手动”编程,理由是快,结构简单,我不否认这种做法,但是得有个前提是项目足够小。不够简单:有些公司的框架忒多,什么都要配置。2、 程序员技术水平有问题,但是,技术水平其实不是程序员一个人的问题,公司有责任组织培训;也许有的公司会说,我的程序员技术没有问题,但是我也想说,你能遇见得到项目的复杂程度吗,你能保管你的程序员能处理无法遇见的复杂的程序而没有错误吗?也许你会说,那我怎么能预测得到呢,谁知道它要复杂到什么程度呢?OK,其实就是因为这些认知决定了一些项目的效率变低了。现在我站在一个客观的角度而非站在软件公司或程序员的角度来说明这个问题。在一个项目中业务的复杂程度,决定了程序的复杂度,这是个自然而然的事情,业务有多复杂程序有多复杂。业务的复杂程度原因很多,有业务本身就很复杂的,也就因为需求方内部矛盾导致业务模糊,而你摄于压力不得不做的复杂,这种复杂是最令人头疼的。还有的复杂是本来你很忙活,突然不断的需求更改,你的程序也不断地更改(你也摄于压力),导致你思绪本身而变得复杂的。还有一种情况,也决定了程序的复杂程度,尽管他并非直接的业务问题,那就是管理,一个项目经理把业务介绍给自己团队程序员的时候发生了变化,也许你不以为然,你是否还对您所在每个公司记忆犹新,你可曾记得那些经常挨骂的程序员;有些项目经理(TM)或TL(队长)脾气很古怪,注意哦,有能力的人脾气往往也都是很古怪的哦,而且往往是年青人;你也许会说,那还来做管理干什么?但是能力往往和脾气不能很好的组合在一起,即使组合在一起也会因为事情的烦躁程度而发生质变,甚至是因特定的对象而变质(性格冲突)。动物都是趋利的何况是一个公司,公司在权衡以后一定大都优先考虑能力,只有一些大的公司会考虑得很全面,因为他们富裕成熟。以上提到的两个原因是很客观的,它并非软件开发效率变低的全部原因,但它一定是比较重要的原因,不管它是什么原因,总之它催生了一种新的技术的产生,那就是“拖拽”。引用金庸小说里的一句话“天下武功皆可破,唯快不破”。但是“独孤九剑”就算快的吗,最快的那是枪(the gun),现代战争都用枪,即使来一群武林高手也会被打成马蜂窝,因为子弹比武功更快,快的重要性由此可见。于是“拖拽”技术就产生了,界面被直接拖过来,后台程序也能随之过来,多容易啊,程序开发由此变得极有效率了,更快了,比如金蝶的K3 BOS、EAS BOS系统。更快更简单的开发确实能使公司取得更大的利益,但技术人员也相应变少了,以前需要20个人来开发的项目,现在只需要10人了。其他人失业了。我是一个来自四川的软件工程师,在我的家乡人口稠密,相应人均土地面积就少,无法完全依靠农业来养活一家人,绝大部分的人都选择外出打工,且绝大部分人都选择了到广州,一个大量需要手工劳动力的城市。他们做的行业大都是服装行业,和软件比较起来是很真实的东西,是看的见摸得着的东西。工厂生产都讲究快,但却和软件不一样,他们的快是机械的,因为是工业制造,所以是机械的,需要一个东西-油,但是油这个东西是很可贵的,很紧缺的,为此很多国家之间发生着争夺。所以手动劳动就显得很吃香,人只需要食物,而食物都是直接或间接来自土壤的,是可再生资源,而且人的大脑远远比机器复杂。反观软件的快,软件的快并不需要油,例如上面提到的拖拽系统,因为程序开发是永远智能的是一劳永逸的,但是因为过度采用智能程序员职位也就永远的减少了,这是很可怕的一个事情;人们都说脑力劳动者是高级智慧的行业,但却因为太过智慧而失业,这让IT行业的程序员们情何以堪啊!拖拽程序的出现,看起来好像导致了生产力的变革和劳动者之间发生了必然的变化;但这种变化却发展到软件工程师要去到服装厂和手动劳动者抢饭碗,而放着脑力不用的可怕局面。虽然失业是生产力发展的必然趋势,但是这会导致人力资源分配不均衡的矛盾,而且不但是不均衡,而且是不合理的矛盾。所以说拖拽程序根本就不应该在这个时候出现,他的出现过快了。拖拽程序不该出现的另一个有力证明是程序本身就不够透明,程序员就业除了拿工资之外就是想获得技术,软件行业对程序员来说是很讲究技术提升的,试问一个程序员不能怎么写代码,像小孩子一样在拼凑积木,又怎么能提高自己的技术水平呢?写到这里的时候貌似看起来有些跑题了,明明题目是讲开发技术但却讲了这许多之外的东西。技术是必然要讲的,但是我是想附带讲一下更为重要的东西,以呼吁大家更为重要的认识到某种危机,特别是程序员本身。以下我将拿出我研究的一些技术来解决以上提到的各种矛盾。程序框架技术解决-采用零配置:我无法逐一介绍各种程序语言的框架,只能以一种语言为例,JAVA语言。JAVA语言最为通用开发方向是WEB开发,也是框架使用最多的地方。最常用的基本框架是Struts Spring 和 (Hibernate或ibatis),程序员需要配置Struts的Action等需要手工翻页等。但现在已经出现“0配置了”,不管是哪种项目开发0配置绝对能让程序员更轻松地完成它的项目,而不至于那么累。-SQL的培训:业务上不可预知的复杂导致了程序的复杂,程序的复杂导致了BUG的出现,BUG的出现不但导致了效率的低下,还会导致程序员心理压力的产生以及恐惧。在面对如此未知而可怕的战斗局面之前。你得分析前一次战斗过的地方那些地方,哪些局部的地方是最惨烈的,你会赫然发现,SQL查询越复杂的地方,包含的业务也就越复杂和越多,不过一般这地方事实上好像看起来不那么多BUG;可是你别忘了,是因为往往你能意识到那个地方的重要性,他的重要性太过明显使你更为注意那个地方,所以你往往呕心沥血,费尽心思地想要搞好那个地方;但是同时你身心疲惫了,甚至比出现了BUG还要憔悴,那种憔悴可取吗?我为什么说SQL查询越复杂的地方包含的业务逻辑就越多,因为程序无非就是一些个控制IF或ELSE 再加简单的loop或for循环就完了,甚至和底层的数据是没有多少关联的,是一些以中间值的流程性控制代码。但是SQL呢尤其是SQL查询呢?各种业务基础数据和实时数据构成了表,表和表之间的关系性已经明示了一大半业务逻辑。所以,即使一个再优秀的系统架构师,他最为关心和最为头疼的地方也还是基础数据和他们关系之间的搭建,其实业务逻辑设计的最精华的地方不是什么多么多么复杂地巧妙的构思一些实现方式,而是基础数据的构建。所以结构化查询语言SQL是多么地接近业务数据,由此而来的复杂逻辑检索就更直接而纯粹地体现业务的复杂性了,一系列的左右连接一张又一张的表一个又一个的分组统计和排序,一次又一次的嵌套。所以为了各位的身心健康以及有轻松做复杂程序的自豪敢,我这里提供了如下培训资料,以起到立竿见影,画龙点睛的作用,让你原来一直想学好但就是一直都走不通的地方,突然茅舍顿开;做软件是靠脑袋吃饭的,不能对身体造成太大的压力,学好SQL的复杂查询,能使你拥有一把绝对的利器斩断思维的荆棘,让自己飞得更轻松更远!请参考后续章节树上游龙之SQL查询,另外大部分公司的笔试题的最后几道题就是考查SQL的能力,别的什么都不考就考查查询,尤其是多表查询和分组统计。以上是开发之前的准备工作,那么接下来我将介绍开发进行中的诡异技术:第一个技术:“冰盾”,监控测试技术。第二个技术,“闪回”,二次开发分析技术。第三个技术,“万解”,是一让软件公司和程序员眼热的大招,拓展程序使程序源代码能够永久模块化的源代码工厂技术。我写这些技术旨在让程序员和公司开发效率加快,双方互益,从而摆脱“拖拽”。至少中小型公司一定得摆脱了。“冰盾”是能让程序员安心的技术,它十分简单,却几乎总是不被软件公司和程序员采用过。“闪回”是减轻二次开发难度的一种分析技术,其实也十分简单,但却也总是不被软件公司和程序员采用。“万解”是减少重复劳动COPY、Paste的一种技术,我的真正目的其实是想用这一技术来替代目前的“拖拽”技术,它是一种能够重复产生新的源代码的技术,因为产生的是源代码,所以足够透明,而源代码的产生模块也是程序员自定义的这一点很重要也进一步说明了他的透明性。这类似于JAVAWEB开发的从JSP转换

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论