架構平台在專案開發中並非是必須的，從軟體專案的整體角度來看，其實質僅為在開發工具的平台之上根據軟體專案的業務特點抽象地提取一些基礎類或實現一些基本功能，輔以開發規則的約定和約束，通過系統地組織以構成乙個整體，以達到輔助專案和開發人員進行開發的目的。在物件導向開發方法過程中，從程式設計的技術角度來看，其實際為繼承、過載、多型技術的具體應用。系統架構在一些較大的開發專案中又是非常重要的。這並非是自相矛盾，之所有這樣說的原因是，在一些小型或單一的程式或專案中，我並不推薦使用架構技術，這可能是一件得不償失的事情；而在一些中型或大型的開發專案，架構平台就顯的很重要了，撇開系統的業務流程不談，採用或搭建的架構平台的好壞與完善與否，直接影響著我們的具體開發工作，甚至整個專案開發的成功與否及後期的維護。試想一下，在乙個中型的開發專案中，如果存在著三百個操作窗體，在未採用架構平台的情況下，在開發過程中，大部分時候都得重複相同的編碼工作，複製、貼上將會成為主要工作，如果在專案完成後，需要對其進行修改，如更改窗體的外觀顏色方案或修改其中的乙個基本操作bug，那工作量將是龐大和複雜的。
架構的搭建一般都是針對具體專案的行業特點來設計的，它的存在就是為整個專案而提供服務的。在整個專案中，架構平台一般位於開發工具與最終使用者程式之間，是對整個開發專案的一次抽象提取和昇華，架構平台本身並不包含一些具體的業務功能，其本身在脫離專案單獨執行時是沒有具體意義的。一般來說，架構平台一般在設計時會包含以下功能：
制定統一的介面和操作風格；
抽象提取公共操作功能或邏輯功能；
提供統一的程式設計介面功能；
封裝、繼承、**重用；
可擴充，利於以後的開發和維護工作；
實現系統的一些基本通用功能；
制定約束與規則(包含資源標識的分配及編碼規則等)；
架構的搭建是對架構設計師的程式設計能力及對專案所在行業務了解程度的一種考驗。架構師的程式設計經驗和能力，直接關係到設計的框架能否實現，以及實現的好壞，如穩定性和可擴充套件性等等；而對業務的了解將有助於架構師對所設計的架構平台的把握，使之更能符合專案的實際開發需求，從而最大程度上方便和輔助程式設計師對具體功能的編碼工作。架構平台應該為專案的開發帶來以下優點：
提高系統的穩定性；
減少開發人員的工作量和開發難度及風險；
使協作式的開發和管理變的更加容易；
良好的擴充套件性；
完成一些瑣碎的、重複的基本功能，使開發人員能更專注於具體業務功能的開發；
**重用；
保證專案的整體風格統一；
系統的維護將變的更加容易和簡單；
技術保密性；
gradle在專案中的應用
compilesdkversion 代表是使用的sdk版本buildtoolsversion 代表構建工具的版本,一般都是sdk相配套的。在專案建立的時候就會自動生成signingconfigs 簽名配置,主要有 develop,release develop 開發時候的配置keyalias apk...
Kibana在專案中的應用
雖然本文主要闡釋kibana 在專案中的應用 但是我們需要了解乙個常識，那就是一般情況下elk都是組合應用的，在我們的專案中我們也是一起使用的，但是由於對kibana 的頗具熱情，所以本文是對kibana的初始 先說下專案背景，我是datawarehouse 的 免不了會對些個datastage j...
排隊論與里特定律在專案中應用的思考
最近小孩老生病，經常跑醫院，經歷了無數次的排隊，即心煩又無可奈何，不自覺對排隊理論做了一些思考，對看板方法中的限制在製品有一些新的感觸。排隊規則分為等待制 損失制和混合制三種。服務機構可以是乙個或多個服務台。多個服務台可以是平行排列的，也可以是串連排列的。服務時間一般也分成確定型和隨機型兩種。排隊論...