0613 【萬泉河】程序代碼哪有什么標準和標準化
包括PLC程序。
我發現，有一些工程師對編程的標準化有一些誤區。 誤以為可以有一套標準的程序代碼，或者標準的程序架構。
所以就會產生一些不切實際的妄念，在學會了寫程序三五年，或者干過了三五個項目或者幾十臺小設備之后， 就開始目光高遠要搞所謂的標準化了。而其實也就才剛剛掌握基本的編程技能，也僅僅達到能完成設計任務，就覺得自己有身份也有責任為行業或者公司，創造一部編程憲法文件，規定別人寫代碼的規范，或者程序框架，即所謂的標準化程序。
更有一些人， 拿自己或者別人，或者官方機構所出的一套程序案例，就當成了標準化的模板來兜售，代碼有可能是免費的， 那么就兜售學習掌握這套代碼的教程。 即稱之為標準化教程。 而且還經常冠以天花板，第一，終極目標等抬頭。
我就實在不能忍，于是在某一篇類似的鏈接之后評論回復道：
真服了，從來只字不提做庫和庫的使用，卻總敢吹什么完美，最高水平，終點。不理解這都哪來的勇氣
庫的應用在你們眼里是屬于早就過了這個階段的小兒科呢，還是還沒進化到這一階段呢？
任何成熟的技能，那就封裝為庫，然后就可以無限次重復應用，減少工作量，提高效率��！
而除此之外，做標準化還有什么意義！
然后就引來了眾人紛紛評論。 其中有最典型的，模擬魯迅的語氣說話：“世上本沒有標準，用的人多了，就成了標準”。
這是典型的胡話，然而卻代表了一大堆人的認知。同時也代表了這些只字不提庫卻兜售標準架構方法的機構團體的思維模式：
賣標準化程序啦！你們都來用我的程序方法，用的多了，我的程序就成了標準了。
然而這里面就出現了一個是先有雞還是先有蛋的悖論：需要足夠多的人采用你這套程序框架， 以擁護抬舉它成為標準，然而在無人使用之前，它咋就成為標準，并以標準為旗號宣傳和兜售的呢？
所以，所有的所謂的標準化程序代碼，都存在造假宣傳的問題。 你都不需要看他吹噓第一完美天花板， 就看他用標準化的標題，就已經是了。
我們從來認為，程序代碼是沒有標準的。 不存在一個標準的寫程序的方法，必須按照某位大神的寫程序的方法，嚴格遵守了，程序就標準。 只要稍微違反，就是不標準。
然后就一定會有讀者笑了：你萬老師這是自己打自己臉嗎？你自己兜售的煙臺方法的標準化程序，怎么就敢厚臉皮稱之為標準的？
有這種認知的不在少數。 有很多人理解成我在推廣編程標準或者標準程序，私下都標定了價碼，我得給他多少好處，至少多少贊美或拉攏的話，他才會給我點面子，支持我，投我一票，祝我的方法成為行業標準。
然而殊不知我誰的賬都不買。 反而需要人掏出真金白銀來才能獲得我做的標準化架構下的樣板程序。簡直讓很多人的價值觀碎了一地， 甚至不少人徹底黑化成為了噴子。
我們所指的標準化，從來就不是程序代碼的標準化，而是設計目標的非標自動化設備可以用標準化的流程設計生產，即生產流程的標準化SOP。如果不了解這個概念的，可以去搜索了解一下SOP的概念。 我在專著《PLC標準化編程原理與方法》的最后一個章節《標準化設計工作的未來》中詳盡做了描述。 另外我也在多篇公眾號文章中做過闡述。
當然，非標自動化設備來說，其實現SOP的最大的難點在于軟件，很多自動化設備公司，其采購、生產、管理，以及市場營銷，銷售，甚至機械設計電氣設計，都可以實現標準化設計流程，用設計的標準的OA流程進行管理。而唯獨自動化軟件部分，遲遲不能實現SOP，反而要獨立于OA系統之外。
這有些相當滑稽，每一個公司，推行辦公自動化系統，部署的軟件系統，最接近的專業是自動化軟件。 如果公司人手不夠，往往部署這些系統的過程中還需要自動化工程師的協助。 然而偏偏，給整個公司的SOP流程都搭建起來了，公司的產品中的軟件部分卻實現不了SOP。
而另一個吊詭之處還在于， 機械裝備，電氣元件這些硬性的東西，都能實現自動化柔性制造按訂單生產，然而自動化軟件作為軟件產品，反而卻一直不能實現自動化。 老板們問起來的時候，我不知道自動化工程師們是理直氣壯呢還是會感覺到一些理虧。
經常遇到一些自動化工程師，強調公司的非標項目或者設備訂單，每臺設備都不一樣， 每臺都不一樣，每臺都不一樣。 然而有沒有想過，所謂的每臺都不一樣的控制程序，相同之處有多少，差異又有多少，需要相同到多少程度的時候，才會認為是一樣。 是百分百嗎？如果設備程序百分百相同，比如家用空調機，洗衣機等設備，百分百相同的控制程序，那都不需要太多自動化工程師做設計了。 固定的程序無窮復制即可。
而如果不同設備訂單的控制程序，90%甚至95%或99%是相同的，其中只有個位數的差異， 那豈不正是要推行SOP的意義所在的嘛！通過SOP的流程標準化， 實現軟件生成過程的自動化，既降低了勞動強度，提高了效率，還保證了工程師的位置一直有存在價值。-------也更為電氣工程師的優雅工作生活提供了可能性。
而我們在軟件設計方面為SOP能做到的貢獻便是程序設計模塊化，這種模塊化可不是簡單把程序分成幾個FC模塊那么簡單。真正的模塊化必須是可以重復使用的庫模塊。在實現模塊的標準庫之后，可以實現高內聚和低耦合。 即在設備程序設計過程中僅僅需要對庫模塊的簡單實例化調用即可完成。
這其中對庫模塊的要求就比較高了。 除了需要基礎的通用庫模版，也包括行業專用庫以及工藝庫模塊。煙臺方法實現的便是制作和使用這些庫的方法。 其中會有一些已有的通用庫， 主要是西門子公司免費提供，可以供我們借鑒使用，甚至也可以遷移到其他的PLC平臺。而在此基礎上，可以再次封裝而成為行業專用庫，并通過對這些基礎庫的調度調用而形成工藝庫模塊。
所以重中之重的還是對這些基礎通用庫的消化吸收和利用，而且這部分工作的技術含量并不高，主要還是工作量。比如要將PLC中的庫函數移植到其它各品牌的PLC，將HMI/SCADA的畫面庫移植到其它各品牌的HMI/SCADA，都是不小的工作量。 這是我一直在身體力行做的，也是一直在宣傳呼吁的，同時也一直作為對同行的觀察指標。
每當看到一些同行長時間宣傳標準化的思想而對庫模塊的開發應用只字不提的時候，不免就替他們替行業感到心焦，你們倒是盡快進化升級到對庫的開發應用來呀！
有朝一日只要聚焦于對庫模塊的開發之后，就會發現什么所謂的代碼是否規范，是否標準，是否最優，是否最簡潔，系統負載最小，注釋是否詳盡，全都無足輕重。 因為你整個程序都是高度模塊化封裝的，因而某一個模塊單元都是可以隨時升級替換的。 即便其中的某一個模塊，暫時使用的不是最優的方法，但只要其功能完整，只要獨立封裝，就無所謂。 你只要有對它持續改進的計劃，只要有空暇，有機會，就隨時可以做，做好了替換原有的模塊，替換之后無縫切換，如此持續迭代，所有的模塊單元都可以最終實現終極的完美。
而這個完美的評價標準由你自己掌握。
滬公網安備31010802001143號
