概述
這一年來讀了讀有關國外大牛和先輩相關的書,最近自己也在做項目架構.見一些同行的言論,有些感觸
有贊同的地方也有不贊同的地方,這里談談自己的架構觀.
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.眼界決定成敗
這個了解過嗎?