rel="file-list" href="file:///c:%5cdocume%7e1%5cdangxin%5clocals%7e1%5ctemp%5cmsohtml1%5c01%5cclip_filelist.xml">堅決架構務實
前段時間和同事一起對伺服器的邏輯架構進行了一次調整，清晰了很多。忽然想起很早年
umluml
的出現將能「徹底
」改變軟體開發的工作方式，甚至「不通
uml者無法染指軟體開發」。
三年之後，《程式設計師》雜誌專訪
ivar jacobson
時，uml
已經是盡人皆知。記得
jacobson
在那次採訪中勸告中國的開發者，趕快去學習
rup。從那時候起，越來越多的人頂上了
「軟體架構師
」的頭銜，張口模式閉口架構，一時間好不風光。然而最初的熱乎勁過去之後，人們發現，「不通
uml者無法染指軟體開發
」的預言似乎落了空，而一些軟體架構師們似乎也並不那麼神乎其技，很多時候反而不如那些實實在在寫**的人管用。他們所宣傳的那些架床迭屋的抽象層，那些複雜精緻的模式設計，看上去精美無比，柔性十足，然而實踐當中乙個出乎意料的小變更，便常常能把這一切打得粉碎。他們樂談的松耦合，小介面，往往只是說起來好聽，實際很難落實，或者代價過高，有的時候，反而是反其道而行之，才更「管用
」。
為什麼會出現這種情況？我想這裡有客觀和主觀的原因。
就客觀原因來說，軟體開發畢竟還是年輕的行業，各方面還在劇烈發展和變化中。如果把軟體技術做乙個層次劃分的話，軟體架構及設計屬於上層建築，而像程式語言、技術平台、資料管理技術、網路體系結構等，均在其之下，屬於基礎。這幾年隨著網際網路的飛速發展，基礎尚且在劇烈變化當中，上層建築自然會搖搖晃晃，甚至趕不上趟。
具體來說，現今的軟體體系結構設計總體上是基於物件導向思想，而且是強型別語言時代的物件導向思想，而動態語言的出現和流行，實際上很大程度上顛覆了傳統物件導向思想的一些原則。例如，人們曾經認為封裝非常重要，物件成員能夠隱藏便應當盡量隱藏，但是
python
和ruby
中public
是常態,private
反而是**，實踐當中也工作的很好，甚至更好。再例如，幾年來人們津津樂道的設計模式，其中有很多在動態語言裡毫無必要。而很多在關聯式資料庫時代被視為秘笈的資料儲存與訪問模式，比如層次關係的表達，反規範化的經驗，放到後關係性資料庫裡就沒有多大意義了。再諸如應用的
web化、
ria、
soa等基本思想的變遷，都是能引起整個軟體技術格局強烈**的大事件，所有這些進行中的劇烈變化，不可能不對軟體架構的設計產生影響，從而使得很多關於架構設計的思想迅速過時或者必須調整。如果架構師們不能夠充分重視實踐，與時俱進，那麼就很有可能做出不合時宜的設計。
就主觀原因來說，很多軟體架構師走入了乙個誤區，即一旦公升級為架構師，就可以脫離具體的**實踐，可以陽春白雪了。事實上，由於下層技術的變化迅速，架構師一旦脫離**實踐，脫離現實應用，很快就會與實實在在的軟體開發工作產生距離感，忘卻一線開發者需要面對的現實問題，做出一些不切實際的設計決策。這樣的設計，或者執行不下去，或者執行下去也代價巨大，該解決的問題沒解決，卻在無關緊要的問題上大做文章。毫無疑問，這樣的設計得不到一線開發者的衷心支援，得不到好的結果。架構設計跟開發發生矛盾，誰有問題？多半是架構設計出了問題。因為開發直接面對實踐，直接從事實踐，開發出了問題，那就是實踐在向自以為是的偽真理宣戰了。
然而，一部分架構師不去檢討自己脫離實踐的設計，卻搞起本本主義，硬拿書本教條死扣實際。另一方面，如果開發者對於架構設計的原則和嘗試缺乏了解，不願意提高對於軟體架構設計的認識和理解，不願意付出對長遠有利的代價，也不理解，不支援，甚至消極抵制架構師的決定，那麼同樣會引起架構設計與開發之間的矛盾。結果往往是，兩個必要的角色之間產生矛盾。開發者抱怨架構設計華而不實，架構師抱怨開發者不嚴格按設計行事，進而相互質疑對方角色的必要性。開發者認為架構師就是吃乾飯的文人，根本應該人間蒸發，沒有存在的必要，而架構師則覺得開發者是一群無組織無紀律的驕傲的野貓，幻想有朝一日自動**生成器能把這幫不聽話的開發者趕出山門。
事實上，開發者和架構師都是軟體開發中必不可少的角色，即使在單人開發的專案中，開發者本人也需要經常在這兩個角色之間切換。兩個角色的相互理解，和諧協作，才能夠共同克服現實困難，開發成功的軟體。在促進這種和諧的過程中，開發者應當積極學習架構設計的理論並充分實踐，而架構師則需要本著務實的態度貼近一線。
作為優秀的受到擁護的架構設計師，必須要務實。把多年的軟體開發經驗，把對軟體本質深入的理解，充分的應用到實踐中去，積極地學習軟體架構的理論，嘗試用理論來指導實踐。掌握了理論之後，一定要親自落實，用實踐來檢驗。當理論與實踐產生矛盾的時候，既不會輕易否定理論，更不會教條主義般地削足適履，而是認真分析矛盾產生的原因，研究可能的對策。在反覆思考和實踐之下，要敢於做出
「離經叛道
」的結論，敢於質疑大師偶像的論斷，更能夠在錯綜複雜的實際做出簡單、可靠、靈活而便於實現的設計，並且向開發者傳達意圖，答疑解惑，實現整個團隊的思想一致。做出的設計，要使開發者看得懂，做得出，自然會得到衷心的擁護。
程式設計師堅決！堅決！堅決！不找外包的理由
1，背鍋俠。自己心裡默默體會 2，人種歧視。內部人員老覺得自己高高在上。就是給你雞蛋挑骨頭，完事，沒人會幫你說話。你的外包公司領導，在內部領導面前宛如舔狗，不會舔的一定不會混的太好。真正有實力的也不會在外包，或者早就轉內 3，找新工作的歧視。有的公司沒有明文規定，但是潛規則，直接pass外包候選人 ...
Google 堅決殺死Flash
google 的新計畫讓 flash 這個問題頻出的外掛程式離退休又進了一步。來自 chromium 開發者論壇的訊息，google 正計畫逐步在 chrome 瀏覽器內遮蔽頁面上的 flash 外掛程式。當然，chrome 瀏覽器內依舊還是會提供 flash 外掛程式。當使用者開啟有 flash ...
生而為奴，堅決說不
我的立場，更加偏向人民群眾一些。長期以來，一直在思考個人的發展問題，群眾的民生問題。生而為奴，不是不可能，只會越來越近。等社會發展穩定了，社會資源將被主要的大廠大機構壟斷，個體戶會以什麼樣的方式生存。物質上依賴他人，精神上被操縱，還有幾個人敢喊出 王侯將相，寧有種乎 輕則全網 中則住所為牢，重則物理...