这个跟先有鸡还是先有蛋的的问题一样无聊。。。。。
什么叫程序的可读性??程序的可读性是对自己而言的,不是对别人,对外人。。要是为了让别人读,那还要N级加密干什么??
程序可不可读,在于我而不在于你,比如你到我家说:“你的酱油瓶子应该摆在那里,醋瓶子应该摆在这里,你摆错地方,我就找不着了。".....呵呵呵。。我摆在哪里关你屁事啊??醋放在哪里,酱油放在哪里,我自己心知肚明,对我来说就是“可读的”,关你屁事啊??你能不能“读”到,能不能“读”懂,关我屁事啊??
你也许说。。。要合作。。是,要合作。。可是,谁跟你合作啊??。。。呵呵呵。。连个小项目都没做过,谁跟你合作大项目啊??
引用<不知道楼主接触过上千万的项目没有,不知道楼主接触过上百万的项目没有?
如果只做过价值数万,不超过100点的系统,并且还是……>
我希望不要用钱方面和点数方面压我。程序好坏跟这个应该没有关系。这两方面只能说明这堆东西比较多。
我家旁边的垃圾站比我家大,楼层又超高,我想住那儿。
可读性是必然的,我不否定可读性。但是我要排位的话,我一定让用户排第一,因为密切接触的是操作人员。
我接触过一个程序,一个手动动作时间需要40秒的动作,这个编程人员竟然真的编个点动程序。操作人员就撒比一样站着40秒什么都不能做。我相信这个动作跟1000点和10点的控制没有任何关系吧?我们可不可以设计成维修模式和操作模式让用户自己选择呢?我承认工艺上这个点动程序是可以用的。
我强调,我出发点是客户。
回复内容:
对: 芳季 引用<不知道楼主接触过上千万的项目没有,不知道楼主接触... 内容
程序的功能性都达不到,是不合格的程序,是不可能交互给客户的。
一个不合格的程序,没有评判是好是坏的资格。
至于我拿大系统来举例的目的在于,小系统往往是封闭的,程序对客户是也不大可能开放,所以程序可读性的问题对客户而言无所谓。为了保护程序,对一些项目往往还会使用不可读的编程方法,故意把程序搞得难懂,但这个是目的性的,不作为讨论。
数千上万点的系统如果程序没有可读性,不管对于谁,都是灾难。即使是核心工艺功能块需要加密,至少大结构对用户是开放的。
系统的大小当然不是评判程序好坏的标准,但对于不注重程序可读性,带汇编风格的程序员,编写大系统时,不管是自己还是客户,都是灾难!
其实,很多问题编过程序的就知道了。。。计算机的发展,最早,要求实效性,要求存储空间小。。。我们在上学的时候就要求过我们甚至学过一门如何简化程序,给程序瘦身的课程。比如,把一些赋值语句放到循环外边,这样就可以减少循环时间。。。
但随着计算机硬件速度的不断提高,存储器容量不断扩大。。以上两项要求已经不再要求了。。。
可读性,是软件发展第二阶段的要求。。。说为什么会出现高级语言,VB,VC等,就是因为以前的汇编可读性不好,可操作性不好。。只有专业人员才可以掌握。。。有了高级语言后,一些中学生,甚至小学生也可以编写些小程序了。。。
软件发展的最新要求,是模块化,可移植性要求。。。。比如让你编一个十六位乘法子程序,并不要求你的程序可读性如何,只要求你的接口标准,比如,被乘数放在R4R5,乘数放在R6R7,结果放在R4R5R6R7中,占用资源越少越好,比如只占用A,B,R0。且子程序,没有溢出。溢出有指示。可以移植,没有固定跳转。放在主程序的任何位置都可以。。等等。。并不要求你可读,读不读的通都没关系,全班30个人,每个人编的都不尽相同,没有关系,测试一下,谁的运算速度最快,就是谁的模块做的最好。没必要看懂程序。即没必要可读。
比如西门子的某些特殊功能模块是加密的,比如MODBUS模块,PID模块是单独加密的,接口是公开的,你可以使用,但是内部你是看不到的。
有人动不动说大工程如何如何,其实大工程跟小工程一样,大工程是由一个个小工程组合的。。。就像盖楼,你盖两层,钢筋,水泥,混凝土,你盖100层还是钢筋水泥混凝土。。。
就像--芯片是什么??芯片是别人做好的“线路板”供你使用。。。让你做一个更大的线路板。同时,你这线路板又是什么?你这个线路板又是另外一个更大工程的“芯片”。。
程序也是一样,现在模块化的程序,都是给别人当“芯片”,别人又是在给更高级别的组合“当芯片。”
以最常见的污水处理系统为例,国内常用的S7300或S7400组成的DCS为例,点数从数百到上千点,对于这样的系统如果不对用户开放程序,用户如果读不懂程序,用户如何运行和维护这个系统?这样的系统不可能停机等待厂家技术支持,所以往往还是冗余的系统,来提高可靠性,并且厂家或第三方自动化公司会定期到现场做巡检。现在软件上的维护往往可以远程,但很多事情还得到现场才能完成。
再比如水泥厂的DCS系统,不管是基于ABB的还是基于西门子的,这个系统从数千到上万点,这些系统难度通常不大,但复杂性没有人会觉得能秒杀它。这样的系统在重工业环境中运行,如果脱离程序的开放性,这个系统不可能运行!这样的系统当然不可能要求客户自动化部门的所以人员看懂,但客户必须要懂,至少在厂家的远程技术支持下必须要懂,这些系统用不了多长时间,客户就能对整个系统了如指掌。
这样的系统,如果程序可读性不强,让客户如何维护它呀!总不可能让厂家天天往现场跑吧!
小系统与之最大的区别我认为就是具有封闭性,一台或一套设备运行数年,客户都不需要知道程序,往往也不可能让你知道。即使是故障的排查,也可以做到良好的人机互动,让用户轻松搞定。
大系统做完了,或在做的过程客户就会参与其中,最终还会给客户详细的讲解整个流程,目的就是让客户了解全部。
小系统通常是在厂家全部做完,到现场安装。细节不可能让客户知道,谁让客户知道,谁就死得快。
回复内容:
对: 第五纪冰川 以最常见的污水处理系统为例,国内常用的S7300或S7... 内容的回复!
这位仁兄的观点一直是我提倡的!
只有真正做过大系统,思考过系统架构的人才会有这种想法的。
我常常把日本人编写程序和德国人编写程序来做比较,他们是两种不同的风格,打个比方如果做第一个项目,日本人可能需要5天,但德国人需要10天,而从第二个类似项目开始,德国人只需要2天,而日本始终是5天,为什么,这就是德国人讲究的代码可重用性,思考的是架构,思考的是编程效率,他们其实是站在不同层面在做事。
我想中国大部分人只是处在日本人的做事态度上,以功能实现为目标(当然德国人也绝对不会忽略功能的,这是基本要求),从来不考虑以后程序的扩充性,以后在其他项目上的可重用性,以及程序内部代码的重复使用问题,以及工作过两三年的同事能否接手你的程序继续编写,如果没思考过这些问题,谈论PLC程序是否优秀没任何意义。
而当你了解了计算机编程的一些优秀架构思想,反过来再来看PLC的程序,你会感慨为什么PLC的编程框架不能更强大?