最近碰到一個這樣的問題，A節(jié)點向B節(jié)點發(fā)送消息残炮，A和B屬于不同的子節(jié)序畏铆。A在發(fā)送之前將消息轉換為另一種子節(jié)序，A收到B發(fā)送過來的消息時吉殃，也需要先轉換為自己的子節(jié)序辞居。在這樣的“約定”下，軟件工作的不錯蛋勺。
但是隨著時間的推移瓦灶，問題出現了。由于硬件更新的原因抱完，B節(jié)點更換了另外一種CPU贼陶，子節(jié)序也跟之前不一樣了。A和B之間原本工作正常的軟件不工作了巧娱。
為了應對這個問題碉怔，有人想到的辦法是，在A上進行判斷禁添，如果是以前的CPU就轉換子節(jié)序撮胧，如果是新的CPU，就不轉換子節(jié)序老翘。
問題看上去解決了芹啥，這是一個好的方法嗎？
試想铺峭，如果不同類型的節(jié)點數繼續(xù)增長墓怀，軟件中會出現越來越多的分支，用來判斷不同的節(jié)點類型卫键，以及相應的CPU類型傀履。而且消息發(fā)送方的處理依賴于接受方的子節(jié)序類型，形成了不必要的耦合莉炉。
這不是一個好的設計钓账。
實際上碴犬，現有的技術實現中已經有很好的解決方案。在TCP/IP網絡中官扣，所有的消息都以一種子節(jié)序傳輸，即網絡子節(jié)序羞福。不管是哪種子節(jié)序的主機惕蹄，收到網絡中的消息后都能正確處理，發(fā)送方和接收方都不關心對方的子節(jié)序治专。所以卖陵，對于上面提出的問題，也可以采用這個方法解決张峰。
如果到這里結束也算圓滿了泪蔫，可是當我們提出這個建議時，有人的回答卻是這樣的：為了不影響性能喘批，不能這樣干撩荣。也就是說轉換子節(jié)序會影響軟件的性能。我想這才是子節(jié)序問題背后更加深層次的問題饶深，即軟件的性能問題餐曹。
對于這個問題有以下幾點值得我們思考：
什么會影響軟件的性能？
在上面提到的這個案例中敌厘，收發(fā)消息的過程中台猴，多調用幾個子節(jié)序轉換的函數會影響性能嗎？
順便插播一個幾年前的故事俱两。我們在交流代碼重構的過程中饱狂，在聽到建議將現有的大函數重構成小函數時，一個資深的工程師馬上反駁道宪彩，這樣會增加函數調用的堆椥莼洌空間，降低性能尿孔。
還有很多我們認為會降低軟件性能的因素衍腥，在此不一一列舉。這些觀點的對與錯纳猫，先不下定論婆咸，但可以提出幾個問題供大家參考。首先芜辕，軟件的性能是否經過量化尚骄，是否有具體的profiling數據？
其次侵续，是否基于具體的數據倔丈，分析性能的瓶頸在哪里憨闰？
最后，是否針對性能的問題對癥下藥需五，有的放矢鹉动？
軟件設計的合理性是否更有價值？
隨著硬件的性能提升宏邮，有些軟件代碼對性能的影響越來越微乎其微泽示，軟件設計本身的簡單性對于項目的成功具有更加有意義。
一個設計良好蜜氨、能夠有效應對變化的軟件械筛，會成為項目遺留的正資產，為軟件的重用飒炎、擴展提供更多的可能埋哟。
