看程序源码有感

今天应需尝试改进一个已经存在好多年的程序，当我打开源代码后，瞬间石化，一时语塞。

我们常用的一个非常高级的工业测控软件Labview，是一个易学难精的神奇语言，更是一个能够体现路路通理念的另类工具。哪怕作为一个初学者，三两下你或许就能控制一台仪表，分析一段曲线，而不像其他文本语言一样，三两下只能在屏幕上打出个“hello world”；哪怕作为一个经验丰富的专家，你也未必完全精通这个语言的精髓，编写出最优化的框架，更多的可能往往是，在编写大型测控软件时，总是感觉捉襟见肘，一时沉迷自身经验的缘由，还会发出“这个语言不如C#”之类的侃侃，其实任何语言都有自身的局限性已经毋庸置疑，如果你非坚持认为必须要有种语言具有统一最大化，那是否也需要考虑下多样性不是更精彩么？现实情况是，真正优秀的工程师，总是习惯性采百家之长，毕竟你要去你的理想之地，该坐车坐车，该坐船坐船，车不擅长在水里跑，船也不习惯在天上飞，反过来也是。

我是Labview忠实的拥趸，有16年不间断的使用经历，感情很深以至于必然产生偏见的褒奖。当你急于表明有些事情不可行时，极有可能是可行的，只是你缺少点把所谓的不可行变可行的经验，这好像也是个很普适的道理，长期的使用经历并不代表你拥有相同时长的经验积累，更可能的是对你早期形成的习惯的延申和加固，当拥有越久的使用经历，往往做事越是畏手畏脚，显得很不自信，其实是很自知，如果嘴上说“不知道，不清楚”也未必是谦虚，而是实话。毕竟谁也不希望自己打自己的脸，如果说别人打自己的脸，那是没有办法避免的应对办法，而自己打自己是可控的，可避免的。可怕的不是偶尔打一次，而是经常打。所以用到老学到老，是自我解困的金言良策。

Labview是美帝NI公司发明的。众所周知他们所谓的是一种通用语言，只是表达一种宣传噱头而已，这个只是侧重于工厂应用的专用语言，务必与各种仪表，传感器，执行机构配合起来，才衬托出它的更加伟大。这个语言的编程方式是图形拖拽，这种设计毫无疑问代表了一种编程理念，发明人的思维应该非常独特，客观上创造出了一种极有可能代表各种语言未来的一种发展趋势。功能模块的封装，微可视化，逻辑的流程化，实在更接近人对自身本能的行使，如果说其他文本语言基于说话逻辑，那这个图形语言或许基于娱乐逻辑。你跟玩积木式的搭几个块块，就赋予了计算机某种灵魂，这肯定是一种天才般的神作。

编程的初衷肯定是实现预计的应用，使用者更多的关注应用的方便，界面的可观化，如果开发者也仅仅限于这两种导向，对于源码及文件的操作不太讲究规范，Labview的包容性这种优点可能会加速你陷入一种麻烦，换句话说，如果你的程序仅仅可以使用，只要不触碰计算机和程序的错误诊断的底线，你的积木其实可以胡乱堆积。但是，如果这样，你确定的给自己或别人挖了陷阱，优秀的程序必然需要具有方便快捷的可维修，可扩展性，而这两个需求点，在使用中大概率会遇到。有同感的工程师一定会发出类似的嚎叫“宁可重新，不愿修改”。更可怕的是，当你开发一个有规模的程序时，还具有很大概率走投无路，自己的逻辑坑了自己，此时唯有花时间重来，而项目经理也来了，你陷入了困境。

好像做任何事情都需要讲究规范，规则，或叫套路，碰壁会导致掉头或思考，遇到过上述麻烦的工程师一定已经注意到规范的重要性，但往往有一个认知偏激，就是单纯的把规整定义为规范。只能说，前者属于后者的一部分，而真正深度的规范是逻辑和界面的框架化，你也可以称为模板化，我是称为软件开发图纸。

当看到这个程序时，我也开始嚎叫了。然后又深深钦佩开发者，虽然我对这个界面保留个人看法，但终归对代码，控件的规整非常欣赏，甚至有一个技巧我还迫不及待地去学习一下。但深究源码，发现看上去挺利索的模块之间，太多的牵扯，上层逻辑清晰的背后，底层已经把我转晕了。应该看一个人的程序可以猜测到开发者的做事风格，这人应该做事利索，讲究效率，应该具有轻度的强迫，对规整有深刻的追求。但对深层细节上，如果不是有意为之，那就是可能缺乏点章法。这算不算是对他人的一种偷窥？肯定是的。

我所谓的一时语塞，却说了那么的废话，算不算自我打脸？习惯了。。。