架構與設計

雖然我其實在軟體這個行業裡面也幹了不少的年頭了，但是回想起來其實很多時候都在從事一些很“粗淺”的工作。因為那個時候雖然在不停的寫程式，但根本不知道什麼是對的，什麼是好的。所以，人其實不能總是埋頭工作，總要用一些時間來思考。

總的來說，在我看來，從事軟體工作，專業能力是最重要的。什麼是專業呢？我覺得其一，能夠熟練使用工具；其二，瞭解材料的特性；（注：各種程式語言其實都是材料）。因此，程式是最重要的。軟體公司的價值是首先是人，其次是程式，最後是文件。而且文件是否是價值的一部分其實還很值得商榷。

下面說說什麼是架構

我理解的架構其實是在程式這一層的。這層才是最有意義的。好的架構，能夠固化業務的精華，同時還能夠通過抽象手段的應用來提高對變化的支援。此外，通過合理的分層可以使程式能夠適應多人並行開發以提高效率。注意，架構不是工作的步驟，或者模組的劃分，而是程式的結構。並且，不是靜態的程式結構，而是執行中的程式結構。靜態的程式結構，你看到的都是在不同目錄裡面的檔案，這其實沒有意義。架構的意義在於讓這些檔案以不同的順序，按某種約定的規則合理有效的執行，同時，還能很好的擴充套件。

要做到這些，首先就需要能夠對業務進行合理的抽象。抽象的目的很明顯，就是為了固化某些東西，並讓整個程式呈現一種層次結構。這樣，讓瞭解業務的專業程式人員，很容易理解，並且很容易分工。所以，設計其實針對的都是執行時，都是記憶體模型。至於你使用的是什麼抽象手段，到還在其次，因為這個需要看你使用的材料是什麼，這個材料支援什麼樣子的抽象手段。

那麼什麼不是架構

架構不是模組的劃分和工作的步驟。因為這些東西其實是屬於業務的。做不同的事情，他們就必然不同，另外，如果做相同的事情，他們就註定是相似的。就算你認為這就是架構，你也要明白，這種東西價值不大。因為對於業務來說，這些劃分與步驟基本都是固定的，不能改變。把大象放進冰箱，總是那三步。如果你設計一個炒菜的系統，你分幾個模組？洗菜模組、切菜模組，入鍋模組、翻炒模組，出鍋模組。總是這些，也許你可以分的更新，或者你分的更粗，但這些沒有意義，因為你需要人實現它。

把大象放進冰箱，你需要實現一個能放下大象的冰箱，我覺得這和如何分析步驟比起來價值更大。很多軟體公司裡面缺乏真正的程式架構師，而這樣的業務架構師往往很多。他們一行程式碼也寫不出來，最愛乾的事情就是寫文件和開會吵架，一群人討論的面紅耳赤，把模組分來分去，最後形成一堆堆的文件汗牛充棟讓人望而生畏而如何程式實現沒人知道。實現出來的程式最終往往是打了折扣的，比如原來設計可以放進一個大象的冰箱，可能只能放進去一個大象玩具。這樣的產品除了能騙騙人，也沒有什麼用處了。

另外還有一種很有趣的現象，那就是程式很薄，資料庫很厚。有些人特別喜歡設計極其複雜的表關係，認為這個似乎就是架構和設計。那麼我只能說他還停留在20年前。

什麼是架構師

架構師是這樣的人，首先他必然是程式方面的專家，必須熟悉材料。其次，他必須有好的理解力，能夠和上面說的業務架構很好的溝通，能夠把業務轉換成程式。所以，真正的架構師註定不可能是一個人。我覺得最好的架構師應該是一個team，裡面有業務專家，有程式專家，有資料庫專家。