none
如何让别人认同新技术 RRS feed

  • 问题

  • 本人构造出一种全新的模式,但这种模式的推广为何如此之难(已实现b/s模型),模型如下:
     1.目地
           将程序开发和项目开发分开
           如果工具已开发完全,那以后做任何系统就不会再需要编程人员 
           在项目开发过程中,让开发人员不需要了解数据结构编程语言等逻辑性很高知识,将数据结构,算法,编程语言将一个特定的团队来完成 
           在系统中最重要的权限中.此工具给出一个模型,它可以处理一般的权限可以变成处理类似审批的复杂权限或更复杂的权限,而完成这些需要数据库的触发器来完成,权限这块是一点也不需要去编写程序语言的

    2.结构
           一个基本库,一个核心库以及若干个应用库完成
         在工具开发过程中,只需要少数人了解核心库,而其它开发人员做应用库,而所有的开发人员之间是相互独立。
         应用库分数据库类型,字段定义,以及界面功能定义三大类,这些都要求从基本库派生
         核心库一当完成就基本不需要在修改
    3.和传统模式下的分别
          1)   传统项目开发过程中每个项目都需要程序员,
                而新的模式下,项目开发团队中不需要程序员,而程序员被集中于一个工具开发团队中
          2) 传统开发过程中应和项目联系度很高,需要每个开发人员都需要有一定的程序语言能力和较高的逻辑能力
              新的模式下开发过程中和程序和项目联系度很低,基本上不需要使用程序语言,所有开发人员都可以不需要懂程序语言,而逻辑能力只需要项目经理有就可以
          3)传统需要在开发过程中不断需要程序员进行开发过程中测试,要常和用户交流,而交流和写代码是必须分开的。所以需要时间很长
             新模式下应在程序是已完成的,在用户要求修改时能很快在系统中反应出来,可以说是一边用户交流一边马上做出来。所以需要时间很短
    4.已实现模型 
          1)如何扩展应用
             因工具未开发完全,所以会有一些需要扩展,但应是基于算法,所以扩展上会要求少部,如已做好一个输入应用,那不管是用户信息或输审批信息等都不需要再扩展,只是需要一般的表达一下,所有的html,javascript,后台处理去会自动完成
            (1)数据库扩展
                因有不同的数据库如sqlserver,mysql等,所以要给每个的数据库建一个扩展,在应用时只要通知工具是那个数据库就可以
            (2)字段扩展           
            从字段定义类派生出来,定义系统还没有定义类型,每扩展一个需要在描述文件中通知工具,让工具能识别新的字段类型,同时在管理数据库中加上,让在管理时可以通过界面就可以使用
            (3)界面和功能扩展
               从界面功能定义派生,增加界面管理和功能实现过程,不需要对所有的界面进行派生,所有的界面都是算法而出,界面的结果已由描述自动生成.如输入界面,系统已做好,就不需要再制作.
    2010年1月27日 4:12

全部回复

  • 从软件工程就为了能重用而诞生的,可惜的是这么多年了,虽然有很多进步,也达不到你说的不用程序员。
    你说的模式不是什么新东西,如果不是这样,你现在应该还在用搭建电路或者给纸带打孔的方式编写程序。
    需求的膨胀和新技术的出现,使得那些已经做好的东西需要重构甚至完全不能使用,所以……
    it is just a dream!
    2010年1月27日 8:26
  • 可能是我说的不明白,事实是这种模型我在上一家公司时我为其做啦一个c/s版本,虽然那个版本有很大的问题(是因我用啦内部使用IE做输入界面,会很容易弹出IE的脚本出错,和IE界面在自绘列表穿插无法实现,后来IE出错我用一个不断去设定事件来完成,这样的IE会很少出错,但很耗系统资源),那家公司用这个版本的做啦,移动基站监控,设备跟踪,KPI预警,工程管理(有些还包括后台处理,但所有的处理都是使用此思想来完成),上面的程序都是同一个程序,分别就是不同的描述,我只主要负责KPI的描述(程序是我一个人做),而其它的项目都是由原来是招进测试员和文员来完成.来联通的一个语音返档系统也是用这种思想,但因是和省公司要通信,所以将通信这块单独拿出来让另一个人开发完成,我只做整个思想的实现,结果是我们为其做好他们好的几个语音返档外,后来他们又增加返档流程,都是他们自已修改一个描述来完成.而我出来后,为啦不和公司的东西有冲突,所以创造出b/s版本,并修改原有版本上一些思想不成熟的地方
    因这个世界的开发人员太多,每个人都会有一个标准,所以在需要做很多的接口来统一化.而需求的膨胀是可以用上面模型中的界面和功能类的派生因所有的界面都是要求有算法自动生成,所以需求的膨胀相对程序的编写来比会觉的很慢.这样的结果是程序员的空闲的时间会越来越多
    为更让人理解,我以已做好的输入界面为例
     
    <html ><head></head><BODY>
    <form action="ACTIVE.FG?FUN=7" method="post"  name=form1 id=form1 enctype="multipart/form-data" >
    <table><tr><td>
    102::2
    103::3
    104::5
    </td></tr><tr><td>
    101::10,1
    102::5
    103::3
    104::5
    </td></tr></table></form><iframe src="Form1.html" frameborder="0px" width="0%" height="0%" id="codeForm" name='codeForm'></iframe>
    </BODY></html>
    在这里是一个文件中的描述或叫一个页面的描述
    里面的
    102::2
    103::3
    104::5
    是生成输入框的html和所要用到的javascript,在这里没有指名有那些表单和排列方式,它们用104::5中5来说明是要生成5号表的表单和排列,而5号表的,只需要去自定一些字段名,中文名,所在表,类型,此字段的描述和一些其它参数
    101::10,1
    102::5
    103::3
    104::5
    这里是生成一组代号为1的和5号表相关的一组按钮,
    当然在这里面生成所有代码时,是会自动根据你的权限来生成
    上面有关表和字段的定义是在页面上完成(数据是在数据库中,这些管理过程本身就是用这个工具来自动生成)


    2010年1月27日 10:23
  • 需求的膨胀这个问题,我忘记说明一个,如果是输入的问题,如我未做对年月输入的操作,只需要去字段定义派生一个,然后写好这个类型的算法,然后通知工具已增加一个类型,在数据库库中加上一条记录,就可以在所有的地方使用,至少是从字段定义派生还是从界面和功能派生是要根据情况决定
    2010年1月27日 11:01
  • 有点像列维*斯特劳斯的结构主义


    你的脚步流浪在天涯,我的思念随你到远方.....
    2010年4月12日 7:01
  • 最新的下载位置,http://www.onlinedown.net/soft/90128.htm,原有的只有程序没有书写具体的描述过程,现在下载中两个PPT,都有描述时的图片+一点点中文解释完成(部分描述,完全描述的还没有完成,包括二次开发解释都没有放进去),
    2010年4月20日 0:34
  • 大致看了下你的介绍和所提供的软件。不得不指出的是,你的文案还是比较晦涩。在你的整个方案中,试图解决很多问题,包括流程定义的问题;用户界面组态的问题;程序扩展的问题;程序结构性的问题;代码复用的问题等等,你给出了你的思路,很多想法还是很不错的。但是就目前而言,方案显得还是比较粗糙,一些问题的解决还存在多多少少的问题,目前的系统代码质量还不高,存在技术上的硬伤。也许有些问题对于你来说并无法立刻解决,但是作为一个我认为客观的判断,如果让我认同你的技术,你遇到最大的困难是程序本身的技术水平和代码质量。尤其是这些代码本身被作为基础结构,直接关系到上层结构的可靠性。

    坦率地谈谈我的观点:

    (1)系统首要的目标人群是什么?到底是面向软件公司还是软件作坊。如果是软件公司,项目经理、程序员、测试人员、美工的分工是否典型。个人认为,你所描述的情况,一些代表了一些软件维护作坊,一些则来自软件公司。软件维护作坊的定义为,没有真正意义上的程序员,更没有架构师,他们的工作是,根据用户的需要,去修改一个已经有的软件,而这种软件本身也是缺乏设计的。有可能如你所说,他们修改的软件来自同行,或者phpcms这样的系统,你的很多需求,似乎也来自这里。但是现在的问题是:你的系统本身是一个半成品,固然容易修改一些(一些配置被独立出来),但是需要先搭建,再修改。而这些公司往往倾向于去修改一个已经差不多的系统,他们完全没有开发能力。如果是软件公司,你的方案在建构系统方面存在这么几个问题:团队任务的耦合性到底增加了还是减少了?对于某一类已经开发完成,并且原先维护基本靠复制粘贴和查找替换的软件,你的软件的确适用。但是如果软件本身在开发中,存在问题,配置文件是谁来定义?修改程序中变动的部分,的确不需要程序员介入了,可是修改程序,则必须同步配置文件,否则必然出现程序或者配置项一方的冗余。另外将程序中一部分内容转移到配置中,使得程序的易读性下降,面对一个“模版”,或者“配置”,不查找对应的部分,能看懂程序么,更使得软件调试开发和运行环境的状况可能不同,增加了调试、测试的难度。配置文件本身的维护也存在困难,虽然编程语法被简单的行列分割取代,但是没有意义的编号却又成为一个问题。

    (2)系统究竟追求通用性还是适用性。通用性并非是优点,这一点似乎被你强调,但是个人不这么认为。我们知道,用户最终还是需要具体的软件。和主流开发框架相比,你的软件舍弃了极大的灵活性,除了配置以外,基本已经硬编码好了,程序的结构基本定型。可是具体功能却没有实现多少。这样,那些从头开发的软件,采用你的方案无异于做茧自缚,而那些不需要从头开发的项目,可资利用的又太少。

    (3)系统究竟是考虑功能搭建还是流程组态。功能搭建,提供给用户什么粒度的模块,偏重界面,还是基本的可用的功能,如果是前者,那么又对用户帮助有限。如果是后者,即便你有一个完善的架构,你需要做的仍然很多,否则你可以声称如何如何扩展,但是扩展本身是独特的开发方式,而且还需要用户亲力亲为,这个无疑降低了用户的接受度。

    (4)有没有必要自己设计web服务器,一款自己设计的web服务器,姑且不问性能、伸缩性这些问题,安全性就存在很大风险。无论是内存泄漏还是缓冲区溢出漏洞,这些问题在系统大规模使用的时候就会暴露出来。另外自己的web服务器存在软件集成和兼容性问题——是否可以多服务器实例共存,如果客户已经拥有了针对IIS的过滤软件、网络统计软件、日志软件等等,它的这些软件可以挂接在你的系统上么?

    (5)和同类方案的对比:a)方案,软件基本定型,提供各种模块,自定义工作流,扩展字段,界面设计,系统运营由上游厂商完全负责;软件作坊公司只负责配置系统和推广销售,彻底不需要开发。每一种类型的软件均设计到位(业务已经开发好,比如cms,可以重新组态为某个行业的cms,但是就是cms了),比如一些有实力的SaaS软件商。b)方案,允许用户建模业务模型,自动生成代码。成为搭建工具,特点是将精力由提供用户一种编程风格转而直接提供可视化的软件工具,目前市面上也有很多这样的软件,针对个人和直接用户。虽然功能简单但是效率更高。c)方案,也就是下一代软件开发工具和框架的实现,适合标准的软件企业开发应用方案。包括了标记和脚本语言,模板引擎,MVC框架,实体类和数据库的自动映射、从软件管理层次说的建模工具、测试工具、源代码管理、进度跟踪、需求管理等等。

    你的技术与其说是一个产品,不如说是一种可以借鉴的思路。你的几个案例可以说是运用了这种思路的系统,但是本身无法从你的代码本身获得太多的帮助,尤其是业务差别很大的软件。最好配套出开发编辑工具或者软件构件库。另外希望lz多了解一些主流的开发平台/技术以及软件开发的理论知识,一些东西貌似已经有了现成的解决方案,不需要从头设计了。

    呵呵,只是随便谈谈个人的观点,毕竟我对你的系统也是初步了解,可能很多我的出发点都未必正确,只是探讨下而已。对于所有的可能的简化软件开发的尝试,我都很感兴趣。我认为ls的朋友也不要特别悲观。

    2010年4月25日 20:12