行業與架構

架構，是一種相對不變的代碼架構，在市面上已經存在好多架構，比如BBS論壇代碼架構、網路遊戲代碼架構等等。

 

項目代碼架構的作用是提高項目的開發速度，能輕易滿足各個項目的需求，並且針對多種裝置，能輕易實現功能。這是一個美好的願望，這種願望不單是由技術來支援，而且還需要行業的支援。

 

地鐵終端裝置這個行業的現狀可以說比較混亂，各個項目有其地區的特點，每個地方的業主都有其獨特的見解，從外觀到硬體選購，到軟體流程（前台流程，後台流程等）都需要特別定製，SC不一樣，票卡業務不一樣，大量的資料都不一樣。。。這樣導致設計軟體架構的難度非常大，因為一個軟體的功能都不確定，那我們的架構就要靈活到。。。像代碼一樣，也就是說基本沒有架構之說了。。。

 

這個估計也是"多頭效應"（每個地方的地鐵業主都是一個頭頭）導致的結果。再看看鐵路方面的終端軟體，由於鐵路方面有最大的頭頭--鐵道部，所以對裝置軟體的功能定製比較統一，去到每個地方的裝置都是相同的外觀、相同的硬體、軟體、流程等等。這樣就能有個架構出來了，因為架構實際就是相對穩定的代碼。

 

再想想別的行業，例如電視機行業。電視就那幾個功能，功能固定，拼的就是品質和價格，每個人都可以到市場上購買，那這樣就有了電視機的架構了--電路板，接收器等等。。。不同的只是一些外觀之類的地方。這樣的一個規範統一的行業所導致的結果就是生產越來越快，品質越來越高，成本越來越低。如果每個人對電視都有特定的要求，我相信沒幾個人能買得起電視了。。。

 

那我們針對這種大環境的困難，是不是要放棄呢？當然不是，現在的解決方案至少能想到兩點。

 

首先是積極領導行業發展，因為行業不會一下子變得規範的，需要廠商和客戶的共同努力，其實客戶也不想提那麼多的要求，誰買東西還想費腦筋阿，只不過他不太瞭解我們一些功能制定的原因，他覺得這些功能不適合他使用，所以他才提出一些比較特殊的需求。如果我們能對這些需求都有個深入的認識，告訴客戶，他提的這些要求能通過我們現有的某些功能或者某些功能的組合來實現。或者他們的問題能用我們現有的流程來解決，而且告訴他們，這個流程是我們對多個客戶的需求調研後所得到的一個比較好的流程，然後一步步去說服他們。這樣相信業主也會信服我們，對我們越來越有信心，也能樹立我們在行業裡的形象。

 

第二個是從技術角度來想的辦法，既然問題的根源是多頭效應，那我們就針對每一頭都做一套比較穩定的代碼，比如廣州的項目就有個廣州的代碼架構，北京的就有個北京的架構。。。因為雖然各個地方的功能流程會比較大不同，但每個地方的功能流程應該是大致不變的，有了廣州的代碼架構之後，以後凡是做廣州的項目就在這個代碼上改，北京的也一樣。但這樣的前提是，我們這個代碼架構必須要非常穩定。

 

如果想要更統一，那我們就在每一套架構下面，提供一個統一的平台，這個平台提供這些架構要調用的介面，比如介面介面、硬體介面等。。。就類似於現在的Ｈ３。如所示：

 

 

希望真到哪天，終端裝置能像電視機行業一樣，規範統一。