各位前輩日安~
小弟最近在寫code時，發現雖有規劃流程圖寫出各步驟需要哪個功能，
然後串接起來，但真正開始寫時，總發現流程圖的規劃少了點什麼，
比方說：功能_3需要再吐個T/F，以利後續的功能作業，然後接續功能_3的接點又都要跟著改，
所以就東補補西補補，
小專案還行，做大專案時我覺得一定會炸掉，
請問各位前輩大概是怎麼走過這時期的?
多寫就會啦，東補補西補補後下次你就知道要避免，通常類似專案做3次以上，就會找出懶人方法了
郭台銘曾說：「計畫永遠趕不上變化，變化抵不上客戶一通電話。」 這世界變化的速度永遠比我們想像得還要快，無論我們做了多詳細的計畫，過了幾天以後，可能發現又需要調整，因此，永遠沒有完美的計畫，但卻有可以時時改進的計畫。
(貓大) LabVIEW物件導向程式設計
看過貓大的影片 就不再東補補西補補了~
你需要的是能夠彈性擴充的設計結構或框架
資料結構與傳遞的問題 ~通常我會建置一個包含執行期間所需變數的cluster 並將它以strict type def定義成自定型別 ，在所有主要步驟VI的輸入/出端點都使用這個自定型別，在因為功能需求變更資料元素需要增加時只要變更此自定型別，所有參照到的VI都能取得這個資料元素
1個讚
恩恩 感謝各位前輩
後來我遇到一個很有趣的問題，
最近看到一支code，分成UI/底層這種寫法，
大致上就是把人機介面的Ref打包好，丟給底層去做事，
底層完全聽令於UI做事，要他停就停…等之類的指令，
好端端的，為什麼要做這樣的分類呢?
為了大型應用開發的解耦設計
可以快速換皮或者抽換底層邏輯
又或者當成積木去和其它功能組合