最近看了一些文章，加上自己的一些經驗，總結一下軟體架構師 （有的稱之為解決方案架構師）最容易犯的一些錯誤。希望可以和架構師們共勉，個人觀點，難免偏頗。
1。範圍擴張
每個人都知道專案需要滿足需求，但是由於架構師都是技術出身，所以老是會沿用程式設計師的那種完美主義精神，總是想把自己的系統做到最好，無形中卻擴大了專案的範圍，也就是經常說的「scope creep」，誠然，專案發起人一定是希望我們可以將功能作的更多，範圍更多，但是，他們的前提是時間和資源不變。所以，我們在給系統增加範圍的時候，一定要在時間資源容許的前提下，而不是自己覺得什麼好就做什麼。
2。過分設計
設計模式，軟體的抽象，物件設計的精化都是好東西，他們可以讓我們的系統可以在將來的變化到來的時候盡可能少的修改**，也可以讓我們的**結構層次更加清晰，更加容易理解。但是，任何事情都有反作用。我們在做這些工作的時候，一定要同時考慮這麼兩個問題：一。是否有必要？有的地方業務可能變化很少或者基本不會變化，那也許我們就沒有必要這麼辛苦了；二。抽象越多，模式用的越多，以後的維護成本就越大，因為我們不能期望這個系統以後的維護，二次開發等等一定是用現在開發的這些人，人才會流失，也許專案開發完畢以後，大部分的開發人員都撤退了，這時候我們就需要新的開發人員補充進來，可是這些人的水平不同，理解能力不同，如果我們系統設計的過於「好」，那麼這些人掌握程式的代價就會過大了。所以，設計是乙個平衡。畢竟我們做的都是專案而不是研究。
3。忽略專案干係人
我們很多架構師總是和專案組成員打交道，和需求人員以及專案發起人打交道，可是往往忽略了其他人，比如測試人員，網管，將來系統上線以後的維護人員，dba等等。但是往往對於他們的忽略可能造成系統的不完整或者失敗。比如在有的地方，你的專案上線是需要其他人員來做的，是需要驗收的，部署過於複雜或者維護手段不夠，不符合企業的安全規定，網路規定等等，都有可能導致系統的失敗。
4。忽略系統的質量要求
乙個系統往往會在功能需求上面寫的很清楚，但是需求人員很難提出具體的質量指標（也有叫做非功能需求），比如系統的高可用性，可維護性，安全性，效能等等各個方面的要素。這些要素其實往往是互相矛盾的，架構師需要充分了解需求，和各種人員溝通，在專案開始的時候明確這些非功能性要求，然後針對這些進行系統的設計。
5。設計過於簡化
我們以前見過一些架構設計，就是一張大圖，顯得非常酷，但是用處卻不大，因為我們不太可能在一張圖裡面描述清楚乙個大型系統的一切。我們的架構設計實際上是給不同的人看得，比如給使用者獲得認可，比如給開發人員，比如給系統部署人員了解部署情況等等。所以，目前最好的方法就是多檢視，多層次，針對不同的物件開發不同的檢視，並且每乙個檢視都有乙個逐步細化的過程，然後還要配上足夠的文字說明，這樣的架構設計才真正有用。這個業界有很多方法，比如微軟有bait，ibm有4+1檢視，還有著名的zachman的六個檢視六個模型等等。
6。不切實際的設計
很多架構師非常喜歡用新的技術，沒有錯，了解it趨勢，使用新的設計思路，平台，技術是應該的也是必須的，但是我們必須結合實際，如果乙個技術太新，就意味著你的開發人員需要大量的學習成本，以為者這個技術可能還有很多bug，就意味著專案過多的風險，也可能意味著你的維護人員也需要足夠的學習成本。所以，即使是新的技術，也應該結合專案的實際，盡可能的選擇相對成熟的，當然，如果你的專案是那種研究性的或者其他特殊專案，另當別論。
！！！！新手最容易犯的錯誤
今天寫了乙個很簡單的程式，輸入三個不同長度的字串，然後將其右對齊顯示 因為剛學了幾天，經常會犯一些錯誤，如下 file day01.py line 62 print maxn len b b syntaerror invalid syntax 以上是之前的錯誤，找了好半天,也一直沒有發現，從頭到尾推...
軟體架構師
軟體企業中有乙個角色叫做軟體架構師，不同公司或者不同的環境下，對該職位的定位可能不盡相同。微軟首席架構師ray ozzie 對自己職位的一些看法，倒是給人很多啟發 1.不管是設計一座橋梁還是一幢大廈，你是在特定的情況下應用各種設計模式 2.在做程式設計師的時候你要花時間讓自己理解各種不同的模式，並能...
軟體架構師
軟體企業中有乙個角色叫做軟體架構師，不同公司或者不同的環境下，對該職位的定位可能不盡相同。微軟首席架構師ray ozzie 對自己職位的一些看法，倒是給人很多啟發 1.不管是設計一座橋梁還是一幢大廈，你是在特定的情況下應用各種設計模式 2.在做程式設計師的時候你要花時間讓自己理解各種不同的模式，並能...