久久久免费精品,日韩射吧,亚洲作爱视频

工控人家園 西門子工控論壇 1218 【萬泉河】誰有資格評價PLC程序對錯

萬泉河

WX:ZHO6371995，歡迎+

級別: 略有小成

發送短信
加為好友

精華主題: 0
發帖數量: 161 個
工控威望: 292 點
下載積分: 940 分
在線時間: 13(小時)
注冊時間: 2021-06-11
最后登錄: 2025-10-04
查看萬泉河的主題 / 回貼

樓主發表于: 2022-12-19 09:59

全看 | 小中大

1218 【萬泉河】誰有資格評價PLC程序對錯

誰有資格，答案當然是從事CODE REVIEW的同事咯！
然而眾所周知，在PLC行業，絕大部分的公司，是沒有CR機制的。從來都是誰寫的程序誰自個兒調試自個兒維護，一桿子負責到底。沒有另外的人幫你CR的。我曾經寫文章探討過關于CR的可行性，以及期待行業中最終能發展出可以通行的CR的標準。但至少現在，還沒有。所以即便有個別公司和同行同事之間有那么零星的符合CR機制的流程，但在還沒有見諸紙面的可分享的CR標準之前，我們只能認為不存在。

那么，除此之外，還有誰擁有這樣的資格呢？

讓我們把疑問暫時放在一邊，來看一張圖，其實是一段程序。

是我在前面一篇文章《1209 【萬泉河】江湖又現萬線圈》中引用過的一段程序。原始程序是一名網友貼出的。而后面的紅線部分是被我修改之后的，修正了原程序中的bug。

文章發表以及這個圖片的程序被轉發之后，在同行之間引發了不少爭議。我粗略估計下，支持的和反對的大概各有一半。有一半同行支持這樣的程序寫法，甚至其中的錯誤也是這些朋友們幫忙發現的。我原本只看了一眼程序的寫法，對具體的邏輯根本沒關心，有錯誤去改正即可，不算什么大事。而反對的同行中則理由各不一致，根據自身預設的立場高低不同，分成了幾派，后面逐類分析。

不過在分析之前，先對一種反對聲音做出反駁。有那么幾個零星的聲音，觀點是：這么簡單的程序還用得著討論嗎？

這部分的觀點表達時語氣基本相同，都是用反問質問的語氣，然而同時，你又看不出他是在表達支持還是反對。其實叫我說，這樣的語焉不詳的表達觀點的習慣，恰恰證明了這些人的思考能力和水平。

答案多簡單！同行們對這個問題的觀點分歧都基本達到旗鼓相當了，還認為不值得討論。那么請問，什么樣的問題值得討論呢？有分歧當然需要討論了，通過充分討論，每個人認識到自身認知的差距，然后整個行業的認知水平才可以提高。那些認為這種小事的分歧不重要，無所謂，沒必要投入太多的精力在這方面的，足以見其基本功是沒有的。做事情都是在那兒摸著石頭過河，走到哪兒算哪兒的。當然啦，咱也不是非要堅持自己的觀點正確，你如果認為沒必要討論，自己不感興趣，那你就視而不見不參加討論即可。沒必要阻止別人討論探討。否則就需要好好解釋下你用心何在了。

回來看反對派陣營，觀點中從高到低主要有三類。

1，斥責：這是典型的腳踩西瓜皮貼狗皮膏藥！
然后甚至不管三七二十一以他自己的習慣方法直接對程序方法做了修改。
2，表示：如果我的團隊中有這樣寫程序的成員，我會勸其離職。
3，抱怨：不按常規寫別人不容易讀懂的程序，將來別人無法維護。非常討厭。

我對這些觀點自下而上逐個回復和探討：

關于維護的概念有兩種理解，可以是甲方的維護工程師，要么是自己公司后來的繼承者或者叫做接班人。

如果指的是甲方，那確實沒有辦法。收人錢財替人辦事，人家作為甲方既然對寫程序的姿勢有具體的要求，你當然要全盤滿足。這個時候，其實你也不是什么設計師工程師，就是個嚴格的執行者而已。甲方單位既然有完整的解決方案，甚至有模版給你抄，你就老老實實照著抄，也不需要有什么不一樣創新想法在里面。遇到這樣強大且強勢的甲方，做一個溫順聽話的執行者也不錯。如果對此有些不滿，覺得這種行規限制了自己的自由發展空間，也不要抱怨，要抱怨只抱怨自己命不好，去錯了行業。你只要還在這個行業謀生，就遵守他們的行規。比如整個汽車行業盛行的SICAR標準，就是如此。

而如果指的是后來的繼承者，這個指責和抱怨就非常沒有道理了。等于是后來者給先行者下了緊箍咒。而且有可能先行者在開發設備程序邏輯的時候，這個后來者還不存在，還沒有來到公司。卻要求先行者提前預料到后來者的智商和理解力水平，需要包容他們有可能看不懂學不會，所以在系統設計中要避免。那么這樣的話，設計中想要應用什么新功能新技術都要好好掂量下了。如果未來的接班人是個笨蛋，學不會咋整呢？

總之，后來的學習者給先行的導師提要求設框框，是不可理喻的。

而第二檔的以團隊頭目出現的，對與自己的習慣不同的同事而容不下的，我的評價是：這不是典型的武大郎開店嘛！容不下比自己個頭高的。

如果這個新同事，設計方法完全錯誤，一團糟，根本不能運行，而又不聽話，如我在上篇文章中所講述的，最后還需要你這個老大來主導所有設計從頭再來，導致非但沒能給與幫助，反而幫了倒忙，那么這個助手在這個團隊中確實沒啥必要存在了。可以在給予幾次機會后酌情考慮請其另謀高就了。

但現在的情況是，程序設計方法明明是可行的，設備是可以正常運行的，甚至有可能最終的設計比你遵從傳統方法的更有優勢。但現在僅僅是因為不符合你的習慣，甚至可能是因為做出了你看不懂的更高級的設計，你就容不下，就要千方百計排擠下屬出局，那說明你這個團隊小頭領是不稱職的，公司領導把團隊交到你手里，讓你來帶，是需要你不斷挖掘培養創新人才，提高團隊創新水平的。而不是任人唯親，以己度人，把團隊帶到武大郎的燒餅店一般越來越窩囊。

所以，真正需要卷鋪蓋走人的，或者把位置讓出來的，應該是你自己。

對上述所有觀點的綜合看法，我的評價是：

我非常驚訝的是這個行業的普遍現象，不善于吸取別人的長處。明明是自己看不懂的設計，卻不肯承認，然后能按自己的價值觀給出各種各樣奇談怪論的評論。
表達一下自己的謙卑和學習欣賞態度就那么難嗎？

討論中，倒是有一位群友的態度非常坦誠：憑直覺覺得這段程序是錯的，然而研究下來它偏偏能正確運行。不懂怎么回事。

這位群友以前搞過技術，現在已經放棄技術去搞市場銷售了。對于這樣的開放心態的人，我就十分欣賞。說明他并不是技術搞不好而轉行去做銷售，而恰恰是技術搞得好之后，才有能力從事更富有挑戰性的工作。

我曾經寫過好多篇關于評價程序好壞的標準，當然，那些標準都是基于效率的，評價一個好的程序和壞的程序的標準是有利于效率的提高。

那個時候，總有一些人冒出來總結到：能夠正確運行的程序就是好程序，這回，有一個能正確運行的程序出來了，先不論它是否夠效率高，按這些人的觀點，首先應該接受，而不是否定，更不是不加分析直接要消滅它呀！所以在沒有CR之前，除了程序的設計者自己，無人有資格評價程序。檢驗程序對錯（注意不是好壞）的唯一標準是機器。程序只要在機器上能運行正確，就無人有資格說錯。

最后分析下這個程序的缺點。

從常理來講，大家通常建議編寫程序的風格方法要有一致性。這個程序，前面手動部分用的是SR，而后面的自動部分用的啟保停。風格極其相悖，也難怪導致眾多老工程師勃然大怒。

我曾經嘗試過要把它們風格統一，要么全都SR，要么全都啟保停。然而反而有些困難。把前段改為啟保停實現難度相當大，改完以后的邏輯反而不如現在容易閱讀。

而把后段改為SR，難度稍低了一些，也比原來容易閱讀，出錯的機會也低多了。至少，自動狀態不再干擾手動模式的邏輯了

原本T37的條件中隱含了自動模式的條件，現在重復使用一下，邏輯就比較通順了。

如果程序最初的作者，用這樣的方式寫程序，或許就不會引來那么多反對聲音，甚至一不小心得罪老大丟掉飯碗的風險了。

然而，兩種程序寫法是等價的，能實現的功能是一樣的。

工控人家園 西門子工控論壇 1218 【萬泉河】誰有資格評價PLC程序對錯

http://m.jt-zhenqiu.com
訪問內容超出本站范圍，不能確定是否安全
繼續訪問	取消訪問