? ? ? 這個(gè)話題要從最近工作中接觸到的一些問(wèn)題說(shuō)起：大概情況是這樣的，公司年前收購(gòu)了一家公司（以下簡(jiǎn)稱Y公司），雖然行業(yè)領(lǐng)域相同，但從業(yè)務(wù)模式到技術(shù)框架都是截然不同的。我們?cè)胁捎玫氖荂#、.Net架構(gòu)，Y公司全棧采用Java，Dubbo微服務(wù)架構(gòu)，本人剛好在公司主導(dǎo)了幾個(gè)Java項(xiàng)目實(shí)踐，被分配到接手Y公司的部分項(xiàng)目。幾個(gè)月下來(lái)，感觸頗多，簡(jiǎn)記如下：

• 項(xiàng)目模塊缺乏整體規(guī)劃，同一功能出現(xiàn)在項(xiàng)目的多個(gè)模塊中，重復(fù)代碼比比皆是；

• 與第三方平臺(tái)接口不規(guī)范，比如與X團(tuán)的API接口中需要獲取Token及加密，這樣的接口本可以在一個(gè)地方統(tǒng)一實(shí)現(xiàn)，但卻散落在各個(gè)地方，且用法不一；最奇葩的是明明對(duì)方的結(jié)果有返回代碼（returnCode）和響應(yīng)消息（message），卻偏偏要自己定義一個(gè)枚舉類來(lái)解釋返回代碼，最要命的是這個(gè)枚舉是不完整的，結(jié)果就是有些代碼找不到就拋出了一個(gè)異?！闭也坏綄?duì)應(yīng)的代碼“云云，在調(diào)試過(guò)程中一頭霧水—難道不能直接用人家的代碼和消息嗎？

• 對(duì)于底層協(xié)議調(diào)用沒(méi)有統(tǒng)一封裝，最典型的比如HTTP協(xié)議，幾乎所有的十幾個(gè)項(xiàng)目中都有HttpUtil，從Header到PUT/GET/POST都要層層處理，不知道有OkHttp，更有上層封裝Retrofit可以直接用嗎？還有Json處理，甚至String處理都要寫一堆，還各個(gè)項(xiàng)目各自為政，結(jié)果是出現(xiàn)了一堆無(wú)用的代碼，臃腫還不能保證效率和正確性；

? ? 上面的問(wèn)題都可以歸結(jié)為代碼的規(guī)范性，如果大家是一個(gè)團(tuán)隊(duì)，就應(yīng)該互通有無(wú)，有所分工，不要重復(fù)造輪子，首先要利用已經(jīng)有的開(kāi)源框架，其次要有統(tǒng)一的底層框架；這樣既能提高整體效率，也保障了代碼的穩(wěn)定性和可維護(hù)性。試想，如果一個(gè)地方出了問(wèn)題，比如第三方接口做了變化，那么上述的編碼方式豈不是要改幾十個(gè)地方？

? ? ? ?其實(shí)規(guī)范性的重要性不言而喻，大家都懂，特別是對(duì)于團(tuán)隊(duì)開(kāi)發(fā)而言，更是如此。那為什么實(shí)際執(zhí)行下來(lái)就這么難呢？其實(shí)是一個(gè)團(tuán)隊(duì)領(lǐng)導(dǎo)力的問(wèn)題，當(dāng)今互聯(lián)網(wǎng)行業(yè)，許多是賺快錢，只求快速上線，不出bug就行，至于怎么實(shí)現(xiàn)的，什么規(guī)范性、復(fù)用性，不值一提。但是仔細(xì)想想，日積月累，這些東西就變得了“負(fù)”能量，時(shí)刻在影響著你的產(chǎn)品質(zhì)量，當(dāng)然也包括成本。到最后，大家都改不動(dòng)了，習(xí)慣了差，沒(méi)有了改的動(dòng)力，到這時(shí)候就是整個(gè)團(tuán)隊(duì)的悲哀了。說(shuō)到底是一種文化和精神，如果一個(gè)公司只求眼前利益，沒(méi)有對(duì)細(xì)節(jié)和質(zhì)量的追求，那么永遠(yuǎn)也成為不了一家偉大的公司，為之工作的員工也只能渾渾噩噩，打更混日子了！