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