序
擔任系統(tǒng)設(shè)計師的職位一年了，盡管自己到現(xiàn)在為止仍然是個不合格的設(shè)計師，雖然這一年以來也不是完全從事設(shè)計的工作，但畢竟站在這個崗位上，主要從事的還是系統(tǒng)設(shè)計方面的工作，加上自己也有志于在這個方向發(fā)展，所以做一個年度總結(jié)是有必要的，也希望能對希望進入設(shè)計崗位的朋友們有些幫助，同時也希望得到在設(shè)計崗位上有經(jīng)驗的同行們的指點。
這也是自己真正擔任系統(tǒng)設(shè)計師這個崗位的第一年，盡管在以前的工作中也曾經(jīng)負責過設(shè)計部分，但現(xiàn)在回顧起來，覺得如果不在這個職位上，很多時候是無法了解到這個職位應(yīng)該做的事的，自然也就無法去做了，在整個一年的工作中學到了很多的東西，同時也暴露了自己很多的不足，但總體而言自己是覺得已經(jīng)踏入了系統(tǒng)設(shè)計的大門，但還需要不斷的提高。
學到的東西
概述
一年以來作為系統(tǒng)設(shè)計師主要參與了公司的一個C/S結(jié)構(gòu)的產(chǎn)品的研發(fā)、工作流系統(tǒng)研發(fā)的規(guī)劃、一個辦公應(yīng)用系統(tǒng)的項目以及現(xiàn)在手頭上的一個開發(fā)框架中。
詳細
在從事C/S結(jié)構(gòu)的產(chǎn)品的研發(fā)上，此產(chǎn)品的系統(tǒng)架構(gòu)主要為插件體系架構(gòu)，不過在實際實現(xiàn)過程中做的不夠好，不過一直到現(xiàn)在插件體系架構(gòu)仍然是我最為關(guān)注的，而且自己也在做這方面的事情，從設(shè)計角度的考慮上來說完成了遠程調(diào)用、增量緩存等的設(shè)計實現(xiàn)方案，同時也根據(jù)場景運用了合適的模式。在這個產(chǎn)品中遠程調(diào)用角度引入了同步、異步的機制，盡管后來異步一直沒搞定，不過畢竟去摸索了，呵呵，現(xiàn)在倒是有解決方案了；增量緩存方面則是為了提升客戶端與服務(wù)端的數(shù)據(jù)交互效率；模式方面運用的主要有命令模式、責任鏈模式、Template模式、Observer模式。這是自己第一次作為系統(tǒng)設(shè)計師負責整個產(chǎn)品的設(shè)計，現(xiàn)在回顧起來自己在那個階段做的是不夠的好，主要是在整體系統(tǒng)的設(shè)計上做的不夠的周全，系統(tǒng)全貌的體現(xiàn)仍然不夠，其實從一定程度上來講就是架構(gòu)不夠完善，而且在架構(gòu)的實現(xiàn)上做的也不到位。
在從事工作流系統(tǒng)研發(fā)的規(guī)劃上，自己主要是作為規(guī)劃人員對整個工作流系統(tǒng)的研發(fā)進行規(guī)劃，同時也作為系統(tǒng)設(shè)計師對整個工作流系統(tǒng)進行設(shè)計，工作流系統(tǒng)一直是工作以來的重點，相對來說在這方面的經(jīng)驗比較的多，整個工作流系統(tǒng)研發(fā)的規(guī)劃做的比較順利，可惜后來由于公司的某些原因，無疾而終。
在辦公應(yīng)用系統(tǒng)的項目上自己作為項目經(jīng)理和系統(tǒng)架構(gòu)師雙重角色，這里主要講系統(tǒng)設(shè)計方面的工作，在這個項目上根據(jù)自己以往的經(jīng)驗完成了一個辦公類應(yīng)用系統(tǒng)的架構(gòu)設(shè)計，同時完成了一個完整的權(quán)限系統(tǒng)以及一個基本的CMS的設(shè)計工作上，收獲不小的項目。權(quán)限系統(tǒng)的設(shè)計也是在blog上曾經(jīng)專門寫了一個系列，而在CMS中的話主要是完成了緩存、模板機制、CMS模型的設(shè)計工作。
目前手頭上則是一個開發(fā)框架的東西，這個東西則讓自己開始真正的做框架級的設(shè)計，和實際項目的那種感覺是不一樣的，難度大大增加，現(xiàn)在主要是做數(shù)據(jù)集的表現(xiàn)層組件、代碼、配置文件的自動生成、緩存策略、通用子系統(tǒng)部分的設(shè)計和實現(xiàn)工作。
小結(jié)
一年以來覺得自己在系統(tǒng)設(shè)計方面學到的最多的就是產(chǎn)品的規(guī)劃、設(shè)計、需求驅(qū)動的設(shè)計方式(需求到設(shè)計的映射)、領(lǐng)域模型的運用以及模式的適當運用。
最大的進步就在于逐漸的學會了從系統(tǒng)全局去分析系統(tǒng)，形成一個系統(tǒng)需求分析--->設(shè)計--->實現(xiàn)的步驟，對于系統(tǒng)的架構(gòu)設(shè)計、概要設(shè)計以及詳細設(shè)計也能夠更加清楚的了解，設(shè)計的目的就是為了需求的實現(xiàn)，所以設(shè)計需要根據(jù)需求來產(chǎn)生。
架構(gòu)設(shè)計中最重要的是根據(jù)對需求共性的分析形成系統(tǒng)的骨架，架構(gòu)中考評的重點是對于系統(tǒng)實現(xiàn)的支撐
、擴展以及對非功能性需求的滿足，同時還需要考慮架構(gòu)中具體引入的技術(shù)或者框架，這個更多的是需要根據(jù)team、項目的大小、時間緊急等因素來決定，這也是架構(gòu)設(shè)計中最為困難的一步，目前在做架構(gòu)設(shè)計時更多的是參考業(yè)界內(nèi)已有的架構(gòu)體系，只是有些時候需要考慮特殊業(yè)務(wù)需求的實現(xiàn)方法，最后根據(jù)職責單一、內(nèi)聚和松耦合的重要原則形成系統(tǒng)模塊的劃分以及接口的定義。
概要設(shè)計最重要的在于根據(jù)模塊的劃分以及接口的定義形成模塊的設(shè)計和接口的實現(xiàn)設(shè)計，模塊的設(shè)計受架構(gòu)的約束形成。
詳細設(shè)計則是具體的模塊的設(shè)計的實現(xiàn)以及對象接口的定義。
關(guān)于架構(gòu)、概要、詳細設(shè)計將專門寫blog來闡述。
另外一點來說就是在一個公司而言通常來說面對的往往是同類型的項目占多，這個時候架構(gòu)的重用是非常明顯的，在這種情況下為了保證公司的項目技術(shù)結(jié)構(gòu)的統(tǒng)一以及技術(shù)人員的統(tǒng)一，通常會有框架的需求，這點以后也將專門寫blog來闡述。
最后一點就是這一年來真正在架構(gòu)體系的接觸上來說應(yīng)該就是插件架構(gòu)體系，其他方面則主要是些系統(tǒng)方面的模型設(shè)計，如，自己在這個方面也是投入了巨大的關(guān)注，目前也在做這方面的東西，這個在我完成目前手上的東西后將專門來闡述插件架構(gòu)體系以及其應(yīng)用模式。
不足
在一年來各個項目的自己所做的設(shè)計來看，最大的不足在于自己缺乏一套系統(tǒng)的、理論的系統(tǒng)設(shè)計過程的指導，個人覺得即使這套理論不是很優(yōu)秀也沒關(guān)系，這個可以根據(jù)自己的實踐經(jīng)驗來調(diào)整，但需要的是一個系統(tǒng)的過程，這點我覺得是自己現(xiàn)在最大的不足。
在自己的不足上，主要列了以下幾點：
1、系統(tǒng)的、理論的系統(tǒng)設(shè)計過程的學習
需要有個清晰的系統(tǒng)設(shè)計過程的體現(xiàn)，并能足以明確的說明其形成的過程。
2、需求驅(qū)動以及領(lǐng)域驅(qū)動的深入實踐和改進
設(shè)計對于需求的滿足性以及符合性的體現(xiàn)。
領(lǐng)域模型驅(qū)動的體現(xiàn)以及建模的體現(xiàn)。
3、加強技術(shù)基本功
作為架構(gòu)設(shè)計師，最重要的是設(shè)計合適的架構(gòu)，特別是作為國內(nèi)目前大部分的中小企業(yè)來說，面對的系統(tǒng)其實在業(yè)界內(nèi)都是有成熟的架構(gòu)體系的，關(guān)鍵是要根據(jù)team、時間等方面因素來做出選擇，這個時候就要求架構(gòu)師對于各種技術(shù)的選擇、框架的選擇需要有個準確的判斷。
4、架構(gòu)的合理性
這點和3中說的有重復，就是如何做出一個適合一定背景的架構(gòu)？
5、模式的合理運用
對于模式的運用需要更加的純熟，包括分析模式、架構(gòu)模式和設(shè)計模式。