上海
30歲的程序員和50歲的程序員編程思路和編程想法會有什么不同呢？我，30來歲，我們公司另外一個程序員老陳，50來歲，公司有一臺設備，有兩個上位機，分別主控上位機和視覺上位機，這兩個上位機之前需要進行通訊，主控上位機需要向視覺上位機發送命令，視覺上位機進行拍照和視覺運算，我們定的是使用TcpIp進行通訊，也就是一個TcpIp的通訊，我和他在想法上產生了小小的分歧。
我和老陳最開始商量，又視覺上位機作為TcpIp的服務端，主控上位機作為TcpIp的客戶端，因為視覺檢測的項目比較多，由主控上位機發送不同的視覺檢測命令，然后視覺上位機根據主控上位機發送的命令來執行不同的視覺檢測接口，然后反饋檢測結果給主控上位機。
因為老陳只負責發送命令，具體要檢測哪些東西老陳最開始是不知道的，所以通訊規則只能由我來定，所以我就對整體TcpIp的通訊邏輯進行了封裝。
首先，我定義了一個消息類型的枚舉（MeassageTypeEnum），目的就是定義不同的檢測項，然后又定義了一個消息頭（MessageHeader）的結構體，消息頭的主要內容分別是檢測類型、ClientKey、Guid。
這個ClientKey是由服務端分配給每一個客戶端的，這樣可以防止非授權的客戶端連接視覺上位機。
在主控上位機，也就是客戶端（TcpClient）第一次連接視覺上位機，也就是服務端（TcpService）的時候，服務端會根據ClientKey生成一個Guid，返回給客戶端。
在客戶端正式發送檢測命令的時候，需要在消息頭（MessageHeader）中寫入消息類型、ClientKey，并將第一次連接服務端時服務端返回的Guid一并帶入消息頭。
服務端在收到客戶端發送的消息時，首先會檢測ClientKey和Guid是否是對應的，若不不對應，則不處理該消息。
我這么做本身目的也不復雜，主要還是以前寫WebApi寫多了，簡單對每一個客戶端進行了類似Auth2.0的密鑰驗證，如果做復雜一些的話，可能還可以做Sign驗證。使用Guid來驗證客戶端本身的安全性并不高，但是可以在一定程度上防止非授權連接！
當我將封裝好的TcpIp通訊邏輯代碼發給老陳后，老陳看了下，覺得我搞了個ClientKey和Guid有點多余。
在他看來，目前跟視覺上位機通訊的，只有主控上位機，想要保證連接安全，我只需要在服務端做個設定，就是只允許一個客戶端連接即可，沒必要搞那么多東西。
但是，我跟老陳說，我給他的封裝好的客戶端接口都已經封裝好了，老陳這邊什么都不需要做，只需要實例化一個客戶端，然后連接就成了，后續的各種命令其實也只需要調用函數即可。
但是，老陳有點聽不進去，還是覺得我這么做有點多余，我為了說服老陳，跟他說，如果只限制一個客戶端的調用，如果以后視覺檢測結果需要通過TcpIp發送給其他機器，這時候代碼還得改。
說了一通，老陳還是覺得，到時候只要將客戶端的連接數量改為2即可，也沒那么麻煩。
于是我跟老陳說，現在我所有接口都已經封裝好了，再按照老陳的方法去做，我還得刪一堆代碼。
老陳似乎覺得我怕麻煩，于是就說：“你代碼不是給我了嘛，我來給你改！”
最后，拗不過老陳，我只能說：“那你改吧，按照你說的做就行了，改好了把代碼上傳即可，我再改我這邊的代碼！”
結語
其實，我也不是說不過老陳，只是，如果我堅持我的想法，老陳最后肯定會上頭，加上這件事情本身就并不復雜，我覺得按誰的想法來都沒有問題，因此最后我在這個問題上選擇了妥協。
但是，雖然我妥協了，可我其實對于老陳的做法還是持保留意見的，老陳的做法過于簡單粗暴了，且拓展性也不強，安全性基本上也等于沒有，萬一連接被占用，那主控上位機就只能報錯了！
最后我要說的是，這件事情里面，沒有誰是誰非，純簡單得想法碰撞！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
