今天应需尝试改进一个已经存在好多年的程序,当我打开源代码后,瞬间石化,一时语塞。
我们常用的一个非常高级的工业测控软件Labview,是一个易学难精的神奇语言,更是一个能够体现路路通理念的另类工具。哪怕作为一个初学者,三两下你或许就能控制一台仪表,分析一段曲线,而不像其他文本语言一样,三两下只能在屏幕上打出个“hello world”;哪怕作为一个经验丰富的专家,你也未必完全精通这个语言的精髓,编写出最优化的框架,更多的可能往往是,在编写大型测控软件时,总是感觉捉襟见肘,一时沉迷自身经验的缘由,还会发出“这个语言不如C#”之类的侃侃,其实任何语言都有自身的局限性已经毋庸置疑,如果你非坚持认为必须要有种语言具有统一最大化,那是否也需要考虑下多样性不是更精彩么?现实情况是,真正优秀的工程师,总是习惯性采百家之长,毕竟你要去你的理想之地,该坐车坐车,该坐船坐船,车不擅长在水里跑,船也不习惯在天上飞,反过来也是。
我是Labview忠实的拥趸,有16年不间断的使用经历,感情很深以至于必然产生偏见的褒奖。当你急于表明有些事情不可行时,极有可能是可行的,只是你缺少点把所谓的不可行变可行的经验,这好像也是个很普适的道理,长期的使用经历并不代表你拥有相同时长的经验积累,更可能的是对你早期形成的习惯的延申和加固,当拥有越久的使用经历,往往做事越是畏手畏脚,显得很不自信,其实是很自知,如果嘴上说“不知道,不清楚”也未必是谦虚,而是实话。毕竟谁也不希望自己打自己的脸,如果说别人打自己的脸,那是没有办法避免的应对办法,而自己打自己是可控的,可避免的。可怕的不是偶尔打一次,而是经常打。所以用到老学到老,是自我解困的金言良策。
Labview是美帝NI公司发明的。众所周知他们所谓的是一种通用语言,只是表达一种宣传噱头而已,这个只是侧重于工厂应用的专用语言,务必与各种仪表,传感器,执行机构配合起来,才衬托出它的更加伟大。这个语言的编程方式是图形拖拽,这种设计毫无疑问代表了一种编程理念,发明人的思维应该非常独特,客观上创造出了一种极有可能代表各种语言未来的一种发展趋势。功能模块的封装,微可视化,逻辑的流程化,实在更接近人对自身本能的行使,如果说其他文本语言基于说话逻辑,那这个图形语言或许基于娱乐逻辑。你跟玩积木式的搭几个块块,就赋予了计算机某种灵魂,这肯定是一种天才般的神作。
编程的初衷肯定是实现预计的应用,使用者更多的关注应用的方便,界面的可观化,如果开发者也仅仅限于这两种导向,对于源码及文件的操作不太讲究规范,Labview的包容性这种优点可能会加速你陷入一种麻烦,换句话说,如果你的程序仅仅可以使用,只要不触碰计算机和程序的错误诊断的底线,你的积木其实可以胡乱堆积。但是,如果这样,你确定的给自己或别人挖了陷阱,优秀的程序必然需要具有方便快捷的可维修,可扩展性,而这两个需求点,在使用中大概率会遇到。有同感的工程师一定会发出类似的嚎叫“宁可重新,不愿修改”。更可怕的是,当你开发一个有规模的程序时,还具有很大概率走投无路,自己的逻辑坑了自己,此时唯有花时间重来,而项目经理也来了,你陷入了困境。
好像做任何事情都需要讲究规范,规则,或叫套路,碰壁会导致掉头或思考,遇到过上述麻烦的工程师一定已经注意到规范的重要性,但往往有一个认知偏激,就是单纯的把规整定义为规范。只能说,前者属于后者的一部分,而真正深度的规范是逻辑和界面的框架化,你也可以称为模板化,我是称为软件开发图纸。
当看到这个程序时,我也开始嚎叫了。然后又深深钦佩开发者,虽然我对这个界面保留个人看法,但终归对代码,控件的规整非常欣赏,甚至有一个技巧我还迫不及待地去学习一下。但深究源码,发现看上去挺利索的模块之间,太多的牵扯,上层逻辑清晰的背后,底层已经把我转晕了。应该看一个人的程序可以猜测到开发者的做事风格,这人应该做事利索,讲究效率,应该具有轻度的强迫,对规整有深刻的追求。但对深层细节上,如果不是有意为之,那就是可能缺乏点章法。这算不算是对他人的一种偷窥?肯定是的。
我所谓的一时语塞,却说了那么的废话,算不算自我打脸?习惯了。。。