軟件開發就找中魯世紀，一站式服務，為企業提供軟件開發，軟件定制服務。
面向對象設計之更流行，是因為這種思想更符合人對事物的認知和定義，在思想表達和傳遞中更容易。
    隨著平臺建設的推進，開發過程會遇到各種問題和挑戰，如果能有這個認識，在處理可改可不改或者較小細節時，會對是否做調整也有幫助。
  日常在做系統設計和方案選擇時，有些開發可能會考慮代碼量。
代碼量不應該成為設計好壞的標準。
如果代碼量小而引入如下的問題，反而增加了系統復雜度和維護成本，系統的穩定性和開發效率也會受很大影響。
  一個好的架構設計能規避掉日常容易遇到的問題，也能更好容納突發劇增的系統訪問，對臨時的故障恢復也有很大幫助。
這些設計的優化，都是日常開發中應該注意的細節問題，只要在開發時稍微思考下很容易識別和做出選擇，也不會增加開發難度。
【常識五：對接的外部系統是不可信的】   在一些業務規則相對固定、場景清晰的系統中，我們經常能看到比較老的系統，這些系統經歷的長時間運行，且使用者習慣也固定了，當初開發該系統的人員有些可能都離職甚至退休了。
隨著業務微小變動擾動原有的設計，特例越來越多，技術框架也在不斷更新進步、團隊成員變動等等，這一切都會使得系統慢慢的走向衰敗，這和汽車保養是一樣的。
如果在可見的未來兩年、五年內，系統依然會服務于業務，研發就應該勇于做出系統重構，短期看不到價值體現，優化的意義和價值卻是長期存在的，這也促使了系統能夠更長久的走下去。
【常識七：工程化是解決開發效率的**工具】   當擁有基于這樣的認知時，在系統設計會有不同，比如創建一個新表時就會主動評估業務查詢需求建立合適的索引、在設計系統容量時會考慮容量及達到容量后的循環覆蓋策略、對于流量洪峰的削峰和控制都會在最初設計時考慮，等等。
如果系統必須依賴研發工程師不間斷地維護和扶持才能運轉，那就意味著隱藏著巨大的風險隱患。
【常識九：產品模型設計的好壞直接影響軟件系統質量和效率】   測試是系統建設的重要組成部分，是系統的質量、安全等的重要保障，但當線上出現異常或故障時，測試卻不應該成為責任人。
一個的系統建設，離不開良好的產品設計、健壯的系統架構、規范的代碼等，這些是前提和基礎。
故而研發應重視代碼變更部分的邏輯和邊界測試，而非依賴于測試人員。
【常識十一：偏業務的系統應具備完整獨立的運營能力】