加入公司快乙個半月了, 對這裡的系統整體印象還是不錯的: 首先」她」規模大, 應用多, 應用職責劃分較明確, 應用間契約也比較清晰. 但是深入到各個應用的**級就會發現很多的問題. 這些問題總結為一句話就是: 結構不太清晰. 我深知這個問題的產生是有很多原因的.
記得剛剛從師兄手裡接管tbc開發的時候, tbc的結構很好. 但是由於當時對系統缺乏乙個整體的把握, tbc在我手裡經過兩次較大變化後(由功能需求和效能需求驅動), 開始變得臃腫, 脆弱. 更可怕的是, 這種狀況對我工作態度的影響----我開始懼怕變化. 這是我最不能容忍的! 於是我開始進行重構, 花了將近兩天的時間讓tbc具有合理的結構, 並且在以後的演進過程中, 保持其結構的合理性, 而不是保持其結構, 這點很重要. 這讓我由懼怕變化轉變為渴望變化. 因為每一次的變化都是對tbc適用性的一次提公升, 對其結構的一次檢驗, 而且還有合理的結構所特有的----良好的可擴充套件性做支援, 使得做改變的體驗很美妙.
總結起來, 結構不清晰的原因有三條:
1. 開發者對系統不了解, 時間緊.
比如我上面的例子. 可以使用重構的方式來彌補.
2. 開發者不具備一定的架構分析和設計的能力.
可以通過多種途徑, 主動學習相關知識.
3. 開發者對結構不重視.
目前階段公司業務發展過快, 使用者量激增造成戰略上更重視系統的功能及其效能, 而不是結構. 而且由於結構自身難以量化的特性, 也決定了管理層難以進行相應的考核, 進而無法推動開發者對結構方面給予足夠的重視. 但是作為開發者如果對《結構》與《功能, 效能》之間的關係有深刻的體會, 這個問題就迎刃而解了.
《結構》與《功能, 效能》間的關係本質上講, 就是形式和內容的辯證關係:
1. 內容決定形式, 有什麼樣的內容，就有什麼樣的形式.
軟體有什麼樣的功能和效能, 就應該有什麼樣的結構, 可稱其為合理的結構. 合理的結構不是只有乙個, 是乙個集合. 我們要做的是找到他們, 並且從中挑選出適合目前以及將來的系統演進的結構. 判斷結構是否合理的原則很簡單: 合理的結構一定是簡單的, 樸素的. ----這是我的觀點, 證明其正確性超出我能力範圍. 簡單性源於深入的分析, 清晰的思路以及豐富的經驗. 正是這種簡單性構成了軟體結構的優雅.
2. 形式必須適合內容, 凡是適合內容的形式, 對內容的發展起積極的推動作用; 反之, 就起消極的阻礙作用.
很明顯, 擁有合理結構的系統更容易被擴充套件, 被理解, 以及被改變----這個永恆的話題, 使其能夠更快的響應功能和效能需求的變化. 合理的結構會讓事情變得簡單, 讓開發者心情愉悅, 能夠欣然的接受系統功能和效能變化的需求, 以達到」擁抱變化」的境界.
綜上所訴, 作為開發者一定要時刻保持警惕, 當系統出現結構不合理時, 要在合適的時間及時的進行彌補. 同時要多多的學習結構設計方面的知識. 最重要是要知道」磨刀不費砍材功」, 要在思想上給予結構足夠的重視.
軟體功能與效能的關係
首先，軟體的效能和功能的源頭都是來自於使用者的需求。功能指的是在一般條件下軟體系統能夠為使用者做什麼，能夠滿足使用者什麼樣的需求。拿乙個電子郵件系統來講，使用者期望這個軟體系統能夠提供收發電子郵件 儲存草稿 設定偏好等功能，只有這些功能實現了，使用者才認為這是他想要的軟體。但是隨著軟體市場競爭的激烈...
EditText的功能與用法
edittext與textview 非常相似，它甚至與textview 共用了絕大部分xml屬性與方法。edittext 與 textview的最大區別在於 edittext 可以接受使用者輸入。edittext元件最重要的屬性是inputtype，該屬性相當於html的元素的type屬性，用於將e...
git diff 的功能與用法
在git提交環節，存在三大部分 working tree,index file,commit 這三大部分中 working tree 就是你所工作在的目錄，每當你在 中進行了修改，working tree的狀態就改變了。index file 是索引檔案，它是連線working tree和commit...