架構師、設計師、程序員大家的差異到底在哪？

架構師、設計師、程序員

大家的差異到底在哪？

         今天在作架構諮詢服務包的時候，內心真是有不少感慨，看着這些須要細化的內容，看着每步步的流程，讓我想起了一個不太願意也不得不想的問題。架構師、設計師、程序員大家到底有什麼不一樣？
         不少朋友都知道，咱們剛剛大學畢業時候都去XX公司應聘程序員工做。這個時候咱們作什麼呢？開發代碼唄。對，但你們有考慮的一件事情嗎？就是咱們開發的代碼質量如何？美觀嗎？整齊嗎？易於修改嗎？好維護嗎？還有一個面向對象開發來講重要的一點，咱們寫出來的代碼OO（面向對象）嗎？

         對於上面的一大堆問題，咱們捫心自問一下，咱們的代碼如何？反正我剛入職的那會可謂——垃圾代碼呀，難看死了，很差修改，很差維護，不對稱不美觀不平衡，並且不面向對象，說實在的就是用對象語言在寫過程代碼，就想大學裏面寫C語言同樣。其實這個比較好意識到，由於當你寫的代碼變成產品的時候，問題就暴露出來了。我相信每一個程序員都經歷過熬夜修改錯誤，鬱悶，頭大的難熬夏夜吧（別說沒有，我不信）。其實如今不少公司，尤爲是小公司，開發人員就是這樣的，程序員通常都是有毅力、有耐心，一說開發，熬呀熬呀，也很累。可是需求變動了，再熬呀熬呀，代碼修改，再修改。那麼咱們就應該反思一下緣由爲何（反正我是反思了，不知道你們如何作的）？這個時候，從新學習面向對象，看模式設計，再根據當時間安排對之前開發過的代碼進行代碼重構。別小看重構，這但是一項很高深的技術哦，也有相關的書籍，我強烈建議你們看看，我以爲學習重構技術和學習模式設計一樣重要。我當時下在重構上面的功夫可不比研究模式設計少。好了，經過上面的階段，我相信你們的代碼應該和畢業時候比有了一個質的飛躍了吧。程序員作開發最好的狀況是，有UML圖，有相關接口設計的條件，進行代碼實現的開發。固然UML圖和相關接口設計本就應該是設計師的事情，公司都喜歡一個當十個用，因此這點無語嘛。到這裏咱們總結出程序員的工做了，開發，看得懂相關設計圖，技術過硬。

         如今咱們要向上爬一個層次了，去作設計師，怎麼作呢？前面咱們說了在開發的時候最好的前置條件是有UML圖，有相關接口設計，這些從哪裏來呢？對，這些是設計師寫的。在整個RUP階段，分析和設計在第三個階段（詳細步驟朋友們能夠去看看Rational統一過程），設計包含兩種，架構設計和系統設計。這段咱們先說系統設計，在系統設計階段，設計師們應該拿到，架構設計文檔，業務需求，相關的領域模型等。這裏設計師們就不能向程序員同樣光想開發了，這裏第一位的是需求（這裏不光是軟件功能上的需求，還有環境需求，硬件需求，技術需求等內容），怎麼樣在架構中進行系統設計可以知足需求，有了編程的經驗，設計師們可以提早預測開發的痛點，技術的難點和一些建議的解決方案。咱們手裏還有前輩們總結好的精華——設計模式，結合一系列需求進行設計。

        設計師可就比開發須要考慮的方面也不少，視角、關注點都會有變化。再向上就是另外一個高度了，架構師。這個就難了，通常架構師都是軟件架構的大拿，或者是某一行業領域的專家，從事某行業領域不少年的大哥級人物了（我說的時候真正的好的架構師，幹兩年編程就跑出來講我是架構的那種不算在內）。架構師能夠說是站在總體企業，甚至是行業內，看待軟件的，他們的着眼點更高了，在業務建模和總體軟件架構上進行設計。朋友們能夠學習一下EA，裏面包含的四個部分的架構，哪同樣都是要下功夫的。

         咱們看到了，從程序員到設計師，再到架構師，他們雖然都是在開發軟件，可是從內容、視角、觀察的高度是不同的。但願朋友們根據本身定位的目標，進行學習和鍛鍊，從而實現你們的目標哦。