0531【萬泉河】PLC工程師該有多痛恨垃圾程序？
前天看了一篇公眾號文章，在聲討一套PLC程序
文章的題目：《說PLC標準化編程不重要的，這個程序你接手嗎？》
而我一看， 這只不過是一份比較潦草的垃圾程序，根本與標準化扯不上任何關系呀！這個程序現在看起來使用的變量亂飛，變量的符號名以及程序塊的命名都比較隨性。
然后后面還有人大罵：這是防御性編程，故意為了讓別人看不懂嗎！
說起垃圾程序，我還是比較有經驗的，有一定的發(fā)言權。本文就對這個問題分析一下。
不過在開始之前先對垃圾程序的概念做個定義。 與垃圾程序對應的是垃圾食品。很多人對垃圾食品的定義也不清楚。 以為人們丟棄到垃圾桶和下水道里的食物殘渣是垃圾食品。 那些只是垃圾，根本算不上食品。所以也更不是什么垃圾食品了。
通常講的垃圾食品，是那些可以食用，甚至方便可口，令人上癮，偶爾食用也無礙，然而長時間單一食用，會引發(fā)身體健康問題的，才是垃圾食品。
現在的大型商超里的餐館，通常會有一些不限量無限次取用的小零食，爆米花，鍋巴，廉價水果，冰淇淋等等，放眼一看，全部都是垃圾食品。
而垃圾程序，首先是可以正常運行的程序。有許多同行經常用好貓壞貓論推導的結論：能讓設備正常運行的程序，就是好程序。 這些僅僅滿足于設備能運行的程序，就是垃圾程序。 可想而知，持有這種觀點的程序員，他們自己的作品，無一例外都是垃圾程序。 即裝載在設備內部的時候，看起來可以設備運行正常。 然而一旦拿出來公開到陽光下，就暴露了原來都是垃圾程序。 如文首截圖的程序一樣。
不過一上來，我先要發(fā)表一些觀點來維護垃圾程序。 借用一個為人處世的雞湯邏輯，所有的垃圾程序，無非兩種情況：不在乎和不得已。
先說不在乎。
我們最早玩的PLC都是絕對地址編程，即便有注釋也主要靠變量后面的注釋文本，且不說一些用手操器編程的小型PLC如LOGO等壓根連符號表和注釋都沒有，就靠絕對地址搭出來的梯形圖邏輯，你能非要判定是垃圾程序？人家，或者你自己，分明是不在乎的嘛！
比如我經常用SMART 200演示一段起保停邏輯：
我不相信誰接手不了這樣的垃圾程序，拿到手里或者換自己來做的時候還要另起爐灶自己再做一遍。
有的人會認為，你這樣一臺設備的簡單邏輯這樣做當然正常，但如果一個更復雜的系統(tǒng)，設備數量多了以后還這樣做，是不是就不夠規(guī)范了，就太垃圾了？
就憑PLC系統(tǒng)的復雜度，就那么點邏輯，你非要說1套設備與5套設備與80套設備有啥不同？大部分不過是簡單的數量的疊加而已。難度并沒有增加，怎么就接受不了了呢？
比如，一個溫室大棚，用一個小型PLC可以如上簡單控制，如果有1000個大棚，控制方案有可能是同樣型號的PLC用1000臺，也有可能換個方案，用一臺大型PLC實現，然后還有必要用不同的編程規(guī)范實現？
分明是不必要的嘛！
而這個大型PLC如果是S7-1500，那么PORTAL中編程的時候，所有的變量都必須有符號名。 即便你不去專門整理符號名，系統(tǒng)也會自動分配一個。 管你用不用看不看，都會有。 那么如果在調試程序過程中根本用不到符號，管它分配的名字是啥樣的呢，只需要關注絕對地址自己就夠用了，那就會出現上面的程序的情況。
所以，從我換位思考的經驗，這種做法完全可以理解。
然后再講不得已。
咱們每個人入門的時候，做的項目，所編制的程序，特別是一些小型項目，都是這樣的做法做出來的。 所有人之間并沒有明顯的區(qū)別。 然后你如果看到這樣的程序就痛恨， 那我想問一下每個人自己，當你入行10年后，翻看自己10年前的作品的時候，會對自己痛恨不已嗎？如果覺得自己那個時候剛入門，做事情還沒學會規(guī)范，覺得可以諒解。 那么憑什么換個人，自己帶的學生，后輩，做出來與自己水平幾乎相當的程序，就痛恨到咬牙切齒呢？水平所限，能力所限，只能做到這個樣子了嘛！
當然， 如果每個人都有這樣的上進心，都能日三省自己，發(fā)現自己技能上的不足，有羞恥心，然后每天學習提高，最終士別三日當刮目相待，自己今日的程序可以比三日前的做法有明顯的提高，自己也有勇氣批判反對自己曾經的做法，那這樣的人，絕對前途無量。
然而怕就怕的是，世間的很多人在這件事上是持有雙重標準的。 罵別人的時候起勁，而對待自己則無比寬容。 別人的程序因為自己讀不懂，就罵是垃圾程序，總能從中挑出來不符合自己習慣的做法，然后就判定對方垃圾。 而如果是自己做的，哪怕是十幾年前做的，因為符合自己一貫的習慣，各種處理方法自己都特別熟悉， 甚至其實十幾年來都沒改進過，都仍然一個套路，但因為對自己要寬容，就能接受。而雙方的程序放到一起， 還不見得誰比誰更優(yōu)秀，誰比誰更垃圾呢！很有可能是兩個作者交換一下作品，都判對方垃圾。而換個第三者來看，你們倆做的都是垃圾。
所以， 所有痛罵垃圾程序的，通常是因為自己看不懂。 而且，有可能是，通過痛罵對方程序垃圾，而掩蓋自己看不懂對方程序的尷尬。
PLC行業(yè)不同于軟件行業(yè)，通常一套PLC系統(tǒng)的軟件設計，整個生命周期內，都是一個人足以完成。即從設計到調試到維護，都不需要多人協作。也就是說，通常情況下，不管是符號名還是注釋，都是寫給自己看的。 用自己看得懂的語言，自己習慣的表達方式，只要自己看了曉得怎么回事都足夠了。你沒必要像軟件行業(yè)一樣要求自己，所有符號和注釋都要規(guī)范英文表達，因為整個項目可能是幾十上百個軟件工程師協作完成，自己所做的只是龐大項目中的一個小模塊，只實現其中的一小點功能，而且實施過程也要經過多道流程，不同的人CODEREVIEW，測試等等。
而PLC系統(tǒng)不管是規(guī)模還是復雜度，都差的遠得很，完全不在一個量級。
就像，每個人的內褲都是穿給自己看的，目標對象并不是外人。
而偶爾，一些特殊的原因，比如中途換人，或者設備運行多年之后維護的需要，換了個人接手來解讀原始的程序， 那也只是相當于一不小心看到了別人的隱私部位。別人大或者小，丑或者嫩，你頂多是嘗試理解并適應，然后解決現有的問題。而斷沒有指責的理由。 就像別人扒開了你的內褲，也斷然沒理由罵你小一樣。
叫我說，越是水平高的工程師，對于越低水平的程序，就該有越高的包容度。就好比書法課的老師，那些書法大師們， 在審視剛剛入門的小學生，或者書法水平遠不如自己的新手的作品的時候，斷沒有開罵的理由的。 你頂多是可以在比較中獲取一些內心的優(yōu)越感。
站的境界越高，俯視的視角看下來，對方的一些幼稚的蹩腳的處理方法你縱然有可能會心一笑，但更應該是諒解他這樣做的原因。 而不是陰謀論的以為對方這樣做的做法是為了背刺自己。想想看，對方做程序的時候，以及現場調試的時候，針對的是現場出現的問題，目的是能讓設備盡早運轉，自己好盡早結束出差回家。連設備能否運轉正常都還搞不定呢！哪有額外的心思對付你。
何況，那個時候你還不存在呢！你接手到這個程序，通常都是很長時間以后了， 甚至5年10年20年，先預設了一個自己的位置，然后猜測對方某些做法是針對你的，這個陰謀論的回路是不是也太長了點？所以，通常不管是罵對方垃圾程序還是罵對方預設陰謀，其實都是等同于在承認自己的水平不如對方。
建議同行們以后少罵別人的垃圾程序，即便真的垃圾程序， 也不要罵。
有人會說了， 你萬老師不也經常指責這個那個程序是垃圾程序嗎？沒錯，但我只是客觀評價，我絕不痛恨，絕不會對對方恨鐵不成鋼，也絕不會動輒懷疑對方是故意埋坑。 我更多的是理解對方的做法，那是他當時的技能水平所決定的，即，要么是不在乎，要么就是不得已。
也包括我自己10多年前做的程序做法，我現在也都深知那里面有多垃圾。 但我不會對自己有多痛恨。我只是原諒自己當時的技能水平不夠而已。同時也慶幸自己一直在學習，一直在進步，慶幸自己找到了不再寫垃圾程序的技能方法，而且還可以傳授給更多的其他人。
原文作者質問的這樣的程序誰愿意接的問題，其實答案很顯然。 你只要從事這個行業(yè)，只要接手別人的遺留工作或者是維護項目， 就不可避免要遇到自己不習慣的垃圾程序。 接不接的原因只在于自己有能力搞懂或者沒能力搞懂。除此之外沒有別的選擇了。 你斷沒有可能站在自己的立場上，要求原始設計者，在10年前就按照你的審美觀和規(guī)范，來完成整個項目，以適應今天的你來接手。這有點時空穿越。
很多煙臺方法的學員，自從學習了煙臺方法之后，眼光變刁鉆了，放眼看去包括自己曾經做過的程序，全都是垃圾程序。 然后很多同行也以為我非常痛恨垃圾程序。 其實遠非如此。相反的是，我反而更愿意挑戰(zhàn)垃圾程序。經常有一些改造項目或者修復漏洞的項目需求，對方會希望我給全盤否定，用煙臺方法重寫。而我主張的是，如果要用煙臺方法重寫，就要關注這個設備還有多少后續(xù)同樣的類型，即我做下來的代碼庫，還有多少重復使用的機會。 如果根本沒有，根本就是當下這一條產線要恢復運行或者增加功能的需求，我是不會同意整體重寫的，我情愿去理解原有程序基礎上修復漏洞和增加功能。
我曾經有寫過一篇文章，【萬泉河】PLC垃圾程序解讀賞析(一)
https://mp.weixin.qq.com/s/hKVMzzr8YbQZ3AXxEkyUNg這篇文章是5年前寫的了， 未發(fā)在這個公眾號，也未統(tǒng)計在338篇技術文章目錄里。 肯定還有很多這樣的文章被遺漏了。 歡迎大家發(fā)現并提醒我。
在那篇文章里，我批評了西門子官方幫助文件中的例子程序。 而其實我一直想分享的是一套我曾經經手的一套昆騰PLC的程序。那是我心目中的NO2的垃圾程序，NO1的更早，更找不到了。 而這套NO2今天終于找到了。 是用CONCEPT 2.6寫的，有興趣的讀者可以對本文打賞10元后跟我私信索取。
那個程序有多垃圾，我只講述一個槽點讓大家感受一下，里面有整數的比較，要判斷千位的數字相等，然而作者不會使用整數相等指令，活生生用8421碼做了逐位比較，而且程序中多處比較，就這部分的代碼就有好幾百句。 沒有子程序，全部都是代碼平鋪的。
讀那套程序，我掙了6萬元。 真的只是讀。 原本項目改造后系統(tǒng)不能正常運行了。以為需要修改程序的，但我通讀了之后，找到了方法，在其上位機組態(tài)王的界面中做了些參數設定就搞定了。那個昆騰的CPU叫一個討厭，雖然有3個通訊口，但只有一個RS232口可用，組態(tài)王和編程電腦只能有一個在線。而程序功能必須通過組態(tài)王來控制，所以我先是讀了10天搞不定，后來回家后找朋友借了套有以太網口的PLC，監(jiān)控配合，很快找到了原因。
那套系統(tǒng)時間久遠，原本應該用16DI和16DO模塊分別7-8塊，就可以實現的，但為了省卡件，柜內用了復雜的繼電器邏輯，最終只用了1塊16DI和1塊16DO。卡件上面省了些錢，但給后來的維護帶來了無窮的后患。 那個電廠后來又有一次改造，還有人又再次聯系到我，希望這部分我能幫忙處理，我直接建議他們，把柜子全毀了重新做吧！十多萬就能搞定。而如果非要我再來解讀這套程序，即便不包含任何硬件，我開價至少要30萬，因為實在太頭疼了。這電廠為啥又來找到我，可能他們這個系統(tǒng)上線十多年，遇到的設備商工程師無數，也就我一個人真的給讀懂了。
前天，有人咨詢要購買煙臺方法的培訓項目， 其實是一套標準架構開發(fā)的樣板示范項目，對方問，如果不滿意是否可以退貨？
我直接拒絕：那不行。 軟件產品，不能以買家主觀的滿意為標準。 否則任何人只要鐵定不滿意，那豈不是就可以白嫖了？
你可以來評判，我給的樣例項目有多少垃圾的地方，有多少地方的處理方法，不如你掌握的方法或者你所見過的別人的處理方法更高效更簡潔，我自己寫文章所講述的不用M和T，不用UDT， 不用交叉索引等各種技能，有沒有真的實現。
如果我所言為虛，直接收集證據法庭上告我好了。 6000元已經值得立案了。
曾經在工控論壇，有一個嘴硬的家伙不服， 我給他開出的條件，他所熟悉日系的不管三菱還是OMRON的PLC, 5萬塊的賭注，他給我一套PLC程序，我給翻譯移植到不用MT，后來那家伙慫了，不敢再應戰(zhàn)了。
總的來說，煙臺方法的程序，就有這個底氣評價為最不垃圾的程序。 不管誰來評判， 你，我，或者任何第三方。 所以才敢賣出這樣的行業(yè)第一高價。
https://mp.weixin.qq.com/s/pLWMc5LgEkY1dAFoQ44YRw
滬公網安備31010802001143號
