#工作心得 我以前覺得這種 PLC 寫法很強，直到我變成接手的人
以前我很嚮往 PLC 程式可以寫得精簡乾淨。
所以剛開始看一些比較複雜的 PLC 程式時，會覺得能把程式寫得很短、很抽象、很多東西共用，是一件很厲害的事。
後來我接手整個架構全是用迴圈跟轉址寫出來的程式
因為同一顆 PLC 要同時控制 6 個同類型系統，所以前人的想法是：
既然 6 個系統的邏輯很像，那就不要寫 6 份。
用一套邏輯，搭配不同的 address offset 去跑。
老實說，這個想法本身不差。
程式看起來確實很精簡，
同樣的邏輯也不用複製 6 次。
但在接手維護之後，痛苦才開始出現。
你要查某一個點位時，不能很直覺地只看 Ladder 上哪個接點亮、哪個條件沒成立。
很多時候一定要打開 Watch Window，然後去算現在 offset 是多少，實際對應到哪一段 address。
有時候只是想確認一個狀態，腦袋就要先做一輪轉址換算。
更麻煩的是加功能。
一般加一個狀態或一段條件，可能就是找空的 bit 或 word 放進去。
但這種架構不行。
因為 address 不能隨便擺。
要符合原本迴圈轉址的規則，要預先規劃每個系統的區塊，還要確保 offset 算出來後，每一區都要對得上。
不然你以為自己只是加一個小功能，實際上可能是埋下一個以後很難查的坑。
那時候我才慢慢理解一件事：
PLC 程式不是越短就越好。
也不是看起來越高級就越好。
尤其在設備現場，程式最後不是只給原作者看的。
它會被交接、會被維護，也會在半夜出問題時被打開。
所以後來我對寫程式的觀念有點改變了
以前會覺得，能把重複邏輯包起來，用很少的程式做到很多事，很強。
現在會覺得，如果一段程式可以讓接手的人快速看懂、快速定位、快速修改，而且不需要每次都先在旁邊算 address，那也很強。
簡單來說就是：
醜一點沒關係，至少要容易懂。
迴圈跟轉址不是不能用。
在某些重複功能上，我自己也覺得很好用。
但它需要看情境使用，而不是整套程式一股腦全部都用迴圈加轉址。
如果只是為了讓程式看起來很精簡，結果把後面的維護成本全部丟給接手的人，那這種精簡其實不一定划算。
程式寫得聰明不難。
難的是在它出事的時候，
下一個人還看得懂。
畢竟現場出事時，
沒有人會欣賞你的程式多漂亮。
大家只會想知道，
現在到底是哪裡卡住了？
