※ 引述《b122771 (四川钵钵鸡)》之铭言：
: 产线的部份就先跳过
: 一句老话
: 爱惜生命、远离产线
在下靠写Labview维生 讨生活已经十几年了
我算运气好的那一个 完全不用碰产线
但每年也是好几支 自动化测试程式 等着我开发
主要的应用范围为
仪器控制 马达控制 资料撷取 远端监控 数据库 影像辨识等
十几年下来累积功力程度 也算上升到另一个档次
相关的技能树 也是点了一大堆
光是摸过的相关仪器种类 少说有上百种
Labview 号称易学难精
对于没有程式基础的人 它界面算是相当友善
但要完整掌控它 也是要花一辈子时间
人家说 一名优秀的工程师/研究员
手边至少要学会一种程式语言当成工具
来协助处理平常各种问题
例如 作实验 收集数据 资料分析等
Labview 正如其名 确实是实验室的一项利器
如果程式是写给自己用 只要结果正确 其他因素不用考虑
万一程式是写给别人用 那就是痛苦的开始
最基本的要求 就是该功能一定要出来
最后的要求才是使用稳定性
至于写程式的三大基本要求
维护性 弹性 可读性 往往就放一边去
我的目前的程式功力 只能用"快狠准" 来形容
右手点鼠标拉线 左手按键盘的快捷键
必要时 还把常用的功能写成脚本 放个绝招
把以前要写很久的功能 瞬间完成
也因为我写Labview的速度太猛了
造成内部主管/使用者有一种错觉
觉得Labview 是一种"应用程式" 而不是一套"程式语言"
因为只要把别人的VI 呼叫出来 线拉一拉 立秒完成
再来讲程式架构的问题
Labview 写小程式 没有问题 许多人处于这个境界
万一程式功能较复杂时 或者使用者不断追加新功能
这时问题就来 往往改到 一个头二个大
这时候需要更进阶的程式技巧
对于各种Design Pattern 要懂得如何运用
其他如 FGV 伫列 通知器 动态事件 异步呼叫 物件导向等用法
也要有非常清楚的认识
我曾遇过写Labview 多年的人 上面的功能居然一个都不熟
对于多人合作写同一支程式 最好方式是使用框架(Framework)
目前主流的框架有二个 分别AF 和DQMH
不过以台湾的工作环境
我相信大部分的用Labview的工程师都是单打独斗
或者是继承前人的烂程式 改的要死
我写Labview的头十年 整个部门就我一个人
所以从来不会有人来Review我的程式
程式码怎么写 我自己看懂就行
今年初 终于多了一名新同事 来从事和我相同的工作
他是从产线转调过来的 已经写了二年的产测程式
先前也在其他公司待过 工作经验也不算菜鸟
不过 我还是很故意给他一个震撼教育
我要求review 他前单位所写的程式 进行建检
然后立下我这边写Labview的一些规则rule
(1) 每个VI 都要在尽量在1024x768分辨率看完
(2) 每个VI 的架构不得超过三层
(3) 尽可能避免使用任何区域变量及全域变量
光是前三条，他先前写的程式 完全不及格
不过我还是对他进行约二周的教育训练
产线的测试程式 原则上 只要不出包就行
你怎么写 OP就乖乖怎么用
但我这边的客制化程式 是给我公司内部实验室的工程师使用
以节省他们的测试时间或人力 或节省经费等目的
所以对功能细节的部分 工程师们会要求特别多
光是一个汇出EXCEL报表 从字体、排列方式、就有众多细节要考虑
经过我十年的努力，同事已经习惯用我的程式了
每年也想出一大堆题目 请我帮忙设计规划撰写
每当完成一支新的程式
常听到同事说的一句话是 "公司不能没有你"
我都是笑笑地回:
"没那种事情，没有人是不可取代的
我不做 公司会捉交替 自然会有人顶上"
写到这里 下面的推文一定有人想问薪水
我中字辈电机系毕业 69年次 30岁之后开始学Labview
不跟别人比 只跟自己比
现在年薪是刚出社会那年的3.5倍