本人希望能夠在此引出乙個話題，就是關於專案開發和維護需要注意的問題！事實上這不是乙個什麼新穎的話題，只能說是乙個沒有引起足夠重視，培養作為程式設計師的一種基礎素養的話題。
為什麼這麼說呢？筆者一直認為it行業的發展趨勢是服務高於一切，服務是盈利模式，服務是最終競爭力！
本人曾經做過幾個專案，有很多感觸。乙個是耦合性、這是乙個非常基本的問題！只要稍微研究一下有關it方**，就很明顯可以看到，從過程到oo，從aop到soa，總是試圖以最簡單的方式解決問題，從耦合非常緊密的架構到鬆散耦合的架構。主要是架構師是否能夠考慮到擴充套件的可能和具有鬆散耦合的素養，有非常多的書籍討論這些問題，在這裡就不多說了。
一般專案都會有乙個免費的維護期！或者免費的服務期！有必要先區分一下維護和服務的概念，維護的物件是已有的系統，要保證已有系統的正常運轉；服務的範圍比較廣，是在系統之上的企業業務，使實際業務通過系統得以有效實現！企業的業務很少有一成不變，當企業業務變化時如何能夠通過已有系統快速、有效的實現，是服務的重點！此時，已有系統已經開發定型，如何在已有系統中實現新的要求？已有系統可能是任意架構的系統！在此提出最佳解決方案不太現實！主要闡述一種思想「鬆散耦合」，這不是在構造已有系統時考慮的問題嗎？在做服務的時候為什麼也要提到！
當你準備做乙個服務的時候可能已經發現原有的系統耦合性非常強，要新增乙個新的功能難度比較大！那麼從現在開始，把你的新功能設計的鬆散一點吧！原有的介面盡量不變（對原有業務影響比較小的情況下，如果對原有業務需要修改，則最好是新增新的介面），因為你可能對原有系統比較熟悉，也可能根本不熟悉，此時修改原有介面需要在原有的文件基礎上反覆論證不會造成原有業務的非預期變化（實際上國內很多時候根本沒有完整的文件供參考），為了避免反覆論證，詳細研究原有系統的幾乎所有方面，快速提供新服務的實現，只要完全清楚新業務對原有業務的影響就足夠了！不需要研究原有系統的所有業務和**。
這裡說的只是雕蟲小技，重要的是在整個系統開發初期就要設計好合理的架構，符合業務可能的擴充套件需要。軟體工程的思想是否真的在你開發軟體整個生命週期體現，還是僅僅為了一期的交付！
iOS 實用的開源元件和服務
專案名稱 專案資訊 afnetworking 網路請求元件 fmdb 本地資料庫元件 sdwebimage 多個縮圖快取元件 uickeychainstore 存放使用者賬號密碼元件 reachability 監測網路狀態 datetools 友好化時間 mbprogresshud 一款提示框第三方...
Linux系統的安裝和服務控制
常見的linux發行廠商和linux特點 1 lniux的髮型廠商 red hat 企業linux 紅帽公司產品 收費系統 centos 社群版linux和red hat 企業linux功能一樣 ubuntu 社群版的linux，更新速度塊半年更新一次 2 linux系統的特點 開源精神 占用硬體資...
Hystrix服務熔斷和服務降級的簡單使用
服務熔斷機制是對應服務雪崩的一種微服務鏈路保護機制。在鏈路請求中，如果某個微服務節點不可用或者響應時間太長，可以熔斷該節點的微服務呼叫，快速的返回錯誤的響應資訊，當恢復正常後可正常呼叫。具體配置過程 配置在 服務端 被動觸發 1 依賴 org.springframework.cloudgroupid...