程序員對上位機的態度∶能用就行？我不同意！

一個優秀的上位機軟件的標準是什么？很多人認為上位機軟件只要功能沒問題，哪怕軟件界面編得再丑，只要使用者習慣了，那就可以了。就這么一個簡單的“共識”，讓現在很多上位機程序員寫出來的東西，僅僅就是“能用而已”！

我對于軟件設計是有“潔癖”的，我在寫一套上位機軟件的時候，我會考慮很多東西，比如說界面配色舒適度、操作難度、理解難度等等，在時間充足的情況下，我還會考慮如何增加上位機軟件的科技感，因為從某種角度來說，甲方也有甲方，一個純素上位機軟件和一個科技氛圍十足的上位機軟件，可以讓我的甲方在他的甲方那里更加自信！因為大多數人都是“外貌協會”的，即使他們看不懂這個上位機軟件的操作流程，但是從外貌上也可以看出這家公司的審美、品味和技術含量！

你想，在給你的甲方介紹園區布局的時候，你是拿一張平面圖紙介紹會讓客戶眼前一亮還是直接搞個數字孿生系統給客戶介紹有“逼格”呢？

但是，我們公司另外一個上位機軟件程序員則不同！

之前，我倆共同開發一條產線上的上位機，上位機軟件框架是我搭的，我幾乎已經封裝好了他可以用的任何組件，他只需要拼接頁面，然后寫好業務邏輯就可以了。

但是，我以為我已經幫他鋪墊好了一切，可他寫出來的東西不光被客戶拒收，連我們公司總部的研發總監都看不下去了。可就在此之前，我還苦口婆心地勸他，讓他把他寫的軟件界面好好整理整理，我甚至把我寫好的給他看，已經教他怎么做了，但是他還是認為他寫的東西沒有毛病，堅持不改！

其實，當時我倆開發的功能是差不多的，都是涂膠機，區別在于，他開發的涂膠機是通過機械手控制的，而我開發的涂膠機是通過電機+龍門軸控制的，其他的，在功能上并沒有明顯的區別。

在業務邏輯上，我是這么設計的：

通過CAD導入涂膠軌跡，涂膠軌跡有兩種顯示模式，第一種就是純表格形式的軌跡坐標列表，第二種是圖形化的形式，相當于把CAD里面的涂膠軌跡信息復刻在了上位機上。

然后，可以通過選擇某個點，給某個點添加各種事件，比如打開膠閥、關閉膠閥、軸抬起、軸停止、等待、暫停（可以換膠后續走）等等。

這樣做的好處就是整個涂膠過程控制非常靈活，可以應對各種場景。

其實這種設計在后來的甲方工藝評審中也起到了一定的作用，因為甲方在驗收時，發現開膠太慢了，導致涂膠軌跡前面將近10mm的地方有無膠和少膠的情況，而軌跡最后收膠也收慢了，導致最后會產生堆膠的情況。

這些其實是設計缺陷，因為我們公司的供膠系統在底層邏輯上會有大約100毫秒的延遲。

當時甲方看到這個情況其實已經有些生氣了，覺得我做的這套上位機系統還有些缺陷，當場就要求我們整改。

我見狀立馬跟他解釋，其實軟件很靈活地，之所以開頭少膠，末尾堆膠，其實是涂膠軌跡的點位事件沒設置好。

緊接著，我在軌跡的第一個點增加了一些延遲時間，然后在軌跡的倒數第一個點后面隔了一定的距離，提前關膠，最后成功解決了這個問題。

客戶看完我的操作，態度立馬就變了，然后問我除了可以等待和提前關膠，我這套系統還能不能更加靈活。

于是，我跟他詳細解釋了這個涂膠事件的邏輯，并且告知他，我已經把我盡可能想到的可以靈活配置的場景全部寫進事件里面去了，他們在使用的時候，只需要選指定的涂膠軌跡點并且將需要的事件綁定進去即可。

客戶聽完以后，非常滿意的點點頭，而且我并沒有見好收，我繼續跟他介紹，告訴他，軟件在涂膠的時候會以圖形的形式展示實時涂膠軌跡，以及每個軌跡點綁定的事件，因為我們的涂膠設備是半封閉式的，中間只留了一扇可以開合的棕色亞克力板，因此，在軟件設計之初我就想到了觀察涂膠進度這件事情，因此，我將軸軌跡和事件以圖形的方式實時顯示在軟件主界面上，離老遠都能看清楚涂膠進度。

客戶聽完更加滿意了，還連夸我的這種方式看起來還挺有科技感的！

可能是我這邊給的太多了，到了我另外一個同事那里，客戶在那愣了半天，指著主頁面，問：“這堆東西是啥？”

其實，客戶問的東西就是我同事寫的涂膠軌跡點，純列表形式的，幾百上千個點，沒有任何圖形界面。

客戶剛開始也沒說什么，但是在我那發生的事情，在這里同樣也發生了！其實就是開膠慢了，以及關膠堆膠這個常見問題。

客戶以為我同事寫的東西也可以綁定事件，因為上位機框架是我寫的，從主界面上看，除了我是圖形，他是列表，其他別無二致。

于是，就讓我同事在開膠后等待一段時間再執行機械手運動，結果我同事還沒意識到危機已然來臨，想都沒想就回答：“這個得在代碼里加！”

“那提前關膠呢？”

同事回：“也得在代碼里重新定位置！”

“那如果中途膠水沒了，我需要先暫停，然后換完膠繼續走呢？你這邊怎么處理？”

同事回：“這個處理不了，只能重新走！”

結果客戶一刷臉，直接走，順便丟了一句：“什么東西！”

最后同事寫的上位機被客戶要求整改，此時同事還不服氣，仍然覺得他寫的沒問題，因為驗收沒過，公司總部研發總監聞訊趕來，看了看他寫的軟件也直搖頭，也勸他改成我這樣的，并且我已經告訴他了，各種控件我都封裝好了，包括圖形界面和事件綁定。

但是，怎么說，他都雷打不動，我雖然沒仔細看他的代碼，但是我知道，即使控件什么的我給他封裝好了，但是想要達到我寫的那種效果，他的業務邏輯改動不會太小！

所以，無論研發總監怎么說，他都不想改，我們公司總部的研發總監其實脾氣很好的，但是就是這么一個人，也被他給搞毛了，當場就對他發了火！

最后，他只得乖乖地去改成我的那種效果！

我承認，他的項目被拒收，有我的一部分因素在里面，如果我寫的東西沒有給客戶太多的驚喜，在他那里可能就沒有更多的期望值，這種落差感，可能是客戶拒收他寫的上位機的原因之一。

但是，作為軟件編寫者，尤其是上位機軟件，在大多數公司里面都缺少軟件原型設計的情況下，上位機軟件寫出來好不好看、好不好用其實早就成了一個上位機軟件程序員水平高低的、除代碼水平外的另一個標準。

所以，“能用就行”只不過是過去相關人才稀有，客戶和公司對上位機軟件的妥協而已，但是，現在我國相關從業者已經有一定規模了，再拿過去那種老思想去寫上位機，就不合適了！

最后補充一句：現在很多上位機程序員，連最基本的布局排版都不注意，處在同一行的按鈕可能都不對齊！這種上位機程序員，你們見過嗎？