人對事物的認識不是僅僅通過文字描述就足夠的，紙上得來終覺淺，絕知此事要躬行。我們程式設計師更是這樣，沒有**的積累怎麼能有寫軟體的能力。
今天讀了架構漫談，說實話看到第四篇時我還不知道架構到底是什麼東西。在我的認識裡架構就是自己以前編的功能模組，它可以實現一定的功能，拼接起來就是乙個完整大軟體。
《架構漫談(四):如何做好架構之架構切分》，通過這篇文章我真的學到了一些東西，一些對我將來做軟體有用的東西。文章裡講的是切分即利益調整，這比我想象中的要現實得多，作者說，動力是我們每個人的利益，切分也是對利益的分割，或許將來生活的真的是因為利益而幹活吧，可現在想想真的蠻可怕的。切分是有原則的的：緊密聯絡的小模組不能再切、人對自己模組的權利和義務是對等的、模組不能太大，應在人的承受範圍內、正給切分過程和調整在系統中是完全透明的。bb這麼半天不知道自己說了個啥。用我自己的話來說切分就是將專案或工程分成等大的幾塊，分給每個負責人。甚至我認為專案負責人會不會對專案進行合理的切分與他了解不了解為什麼需要切分，切分的原則，切分與建模這些東西一點關係都沒有。因為這些東西都是在不斷做軟體，做專案中積累的最最基礎的經驗。
《架構漫談(五):什麼是軟體》，剛看到這個題目，有些詫異，什麼是軟體，這還真的說不上來，但我可以舉例子，像qq，瀏覽器，管理系統這些都是軟體。至於軟體的定義是什麼，又有多少人能說得上來。一開始是懵懵懂懂的去寫軟體，後來慢慢的就有意識的去切分，演變成了不同的架構。軟體工程師的任務太重，我們需要把很多任務作拆分出來。
《架構漫談(六):軟體架構到底是要解決什麼問題》，軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中執行起來的。要做到這一點需要解決兩個問題：業務問題，計算機問題。業務問題的本質，是業務所服務的物件的利益問題，明白了這個，就很容易搞清業務的概念和組織方式。再次強調一下，有了軟體，可以降低業務的成本，沒有軟體的情況下，業務是一樣跑的。如果只是為了跟風要用軟體，說不定反而提高了成本，這個是採用軟體之前首先要先搞清楚的。我們經常說軟體和技術是業務的enabler，實際就是把原來成本很高的降到到了很低的程度而已，並不是有了什麼新的業務。另外，軟體也不是降低業務成本的唯一方式。軟體工程師還必須要考慮，用什麼樣的硬體把軟體跑起來，怎樣跑得好，跑得快，並且可以隨著業務的流量逐漸的長大。
《架構漫談(七):不要空設架構師這個職位，給他實權》，當然這篇說的就是架構師的重要性了。要成為架構師，必須要超越這個恐懼才能夠看清楚，我們要解決的是別人的問題，不是自己完成工作的問題。因為僅僅是完成了自己的工作，也並不一定就解決了別人的問題。如果別人的問題沒有解決——即使我們認為自己的工作完成了——我們的工作實際也沒完成，因為我們工作是否完成，是別人說了算的，不是我們自己。
讀架構漫談 有感
什麼是架構 緣起一直以來，在軟體行業，對於什麼是架構，都有很多的爭論，每個人都有自己的理解。甚至於很多架構師一說架構，就開始談論什麼應用架構 硬體架構 資料架構等等。我曾經也到處尋找過架構的定義，請教過很多人，結果發現，沒有大家都認可的定義。套用一句關於 big data 流行的笑話，放在架構上也適...
讀《架構漫談》有感
上上週，在王老師的 威逼利誘 下,歷時兩周，總算是讀完了這九篇關於架構的部落格。雖然其中很多內容我還不是很理解，但是還是學到了很多，對於軟體工程以及架構的概念也有了更深的理解。首先就說說什麼是架構，用 架構漫談 中的原話來說，架構，就是 1.根據要解決的問題，對目標系統的邊界進行界定。2.並對目標系...
讀《架構漫談一》有感
架構漫談 一 什麼是架構？1.我的目的 我看架構漫談的目的是通過架構幫助我解決如何看懂一本書，如何看懂乙個概念並非是通過它來解決如何設計軟體架構 企業架構 架構等 這些問題，但通過看這篇文章也讓我得到了除了我的目的之外的一些知識，進一步擴張了我的思維方式，讓我從更抽象更高的層次去考慮如何解決自己不僅...