概述

      這一年來讀了讀有關國外大牛和先輩相關的書,最近自己也在做專案架構.見一些同行的言論,有些感觸

有贊同的地方也有不贊同的地方,這裡談談自己的架構觀.

1.架構不是為了玩技術

     很多人在玩技術技巧,但架構這東西非作秀,然而一些人在這麼幹,

架構的稽核標準第一條:便捷、易維護、適合於需求不斷調整業務場景.

     曾經在一個企業見過這樣的場景:所謂的一個leader十多年的時間帶領一幫人做一個簡單的資訊管理系統,

他們所有的一切都一團糟,卻玩起了技術秀--學著別人做DDD.

邯鄲學步的後果--完全在模仿形式,系統隨著需求調整和加增時立即變現出來牽一髮動全身.

還有一個明顯的表現:開發和維護起來的靈活性完全喪失.

 　架構不是表演、而是為需求和開發人員服務的.　　

　用過async await的朋友,估計會發現微軟設計中的問題:一致性問題,UI程式設計模式下(winform wpf等)和在

純程式設計模式下的實現一致性問題.這不僅讓我想到一直讓人唾棄的ASP.NET webform,微軟這些年幹了一些荒唐事情(直到VNEXT的出現).

　微軟這些年不行了--這不是我說的,而是一位曾擔任微軟亞洲架構師說的.不要問我是誰,不會告訴你.

　因為這幫人在玩技術概念,而不是做好的架構.

2.架構的目的是將軟體工程精簡化

世界上最好的學者總是可以深入淺出的把大道理講給外行聽，而不是故弄玄虛的把簡單的問題複雜化

就DDD而言,我贊同其中的層次理念,但人們的使用估計多數在邯鄲學步,

我問:你這麼用DDD,完全在套形式呢?還是讓所有的業務都在等著你這麼去使用??

有人贊同我的反問,有人 贊同對方.各種原因不在評說.

只讓大家去思考一件事情:軟體開發中唯一不變的是:業務需求一直在變:調整、增減.

架構的目的在於為需求和開發人員服務.

3.檢驗架構終極考研--現行市場

這些年出了幾個基於瀏覽器的PC作業系統,如谷歌,惠普等??還有類似的手機作業系統如Mozilla.

架構理念堪稱完美,但最終都成了邊緣、廢棄的東西.

首先從架構上來講,他們的設計理念確實很完美:

利用Html5

1.解決了開發成本問題;

2.解決開發人員稀少問題;

3.解決作業系統本身維護問題;

以上是他們的如意算盤,但他們最終失敗了,他們說之所以失敗---效能和使用者體驗.

但仔細想想,難道一開始他們沒有想過這個問題?不會,絕對不會犯這麼低階的錯誤,

無論怎樣都考慮過這個問題,至少他們認為:效能到時候應該不是一個問題.

那麼為什麼會失敗呢?

他們脫離了現行市場的考驗:當下市場中的產品,他們的優勢自己是否具備,

畢竟其他的系統都已經成為市場巨無霸了,而自己的新東西是否具備顛覆現行需求的基本條件???

這是IT決策者和市場脫節的後果.

4.架構在程式碼中的衡量

程式碼重用性、耦合度、可維護性、可測試性

在談及這四種特性之前,我們談談業務功能,

所有的開發都是圍繞著業務功能走的,每一個業務功能(如充值)都由

其他更細的圍繞著該業務的小功能組成.

責任越多,越不易被重用;

涉及得越多,越容易耦合;

便於構造和觀察的輸入輸出,才能有更好的測試性.

5.謀定而後動

沒有人告訴你什麼時候該敏捷開發、什麼時候應該瀑布型開發,

但無論何種開發開發模式,謀定而後動是其根本,

謀定而後動不是指一種開發模式,而是指一種做事的原則.

出來混的遲早都是要還的,明白人都懂得這個道理.

------------------------------------------

6.眼界決定成敗

 這個瞭解過嗎?