8、從架構的角度看如何寫好**
**對於乙個軟體工程專業的學生再熟悉不過，關於**架構的那一篇文章現在雖然看不到，但我依舊從第八篇文章中得到了部分結論，重寫**，推翻原有架構，重新設計等等說法，來說明架構的進化。這實際上就是當初為了完成任務，沒有充分思考所帶來的後果。這也並不是架構進化的事情，而是個人對問題領域的逐漸深入理解的過程。所以有必要再討論一下，**的架構應該是怎樣的。
首先提到的就是業務邏輯，在軟體**中，不需縮排和計算的順序呼叫，包括縮排的**目的是 catch exception 的，都不算邏輯，除此以外都是邏輯。這裡通過例項，為我們介紹了業務邏輯等相關知識，也提到了，我們真正想快速的完成**工作，就要克服自己對時間的恐懼，真正的去研究業務的問題，相關 stakeholder 的利益，把這個變成我們的習慣。寫**的時候讓該出現邏輯的地方出現邏輯，讓不該出現的地方不能出現。一旦不該出現的地方出現了邏輯，那麼要馬上意識到，這個地方是乙個坑，這個問題一定和業務的分析不透徹有關係。
讀到這裡，我突然發現乙個問題：「克服恐懼」,在《架構漫談》系列文章中，確實提到了不少關於克服恐懼的觀點，想想自己編碼時的煩躁，確實，有很大一部分是恐懼，畏懼，不確定，害怕自己時間不夠，害怕自己花費了時間沒有完成，害怕自己實現不了相關功能，這裡確實，我們在開發的路上，需要克服的恐懼很多，每個階段都要克服自己心裡不同的恐懼。
9、理清技術、業務和架構的關係
文章開頭提到的那個關於開發軟體的話題我覺得很有意思：「作為架構師或者做技術的人，在開發軟體時，我們基本上就是在扮演上帝的角色：我們不但要建立出乙個個的程式，還要讓這些程式能夠脫離我們在硬體上獨立執行，以便為這個程式所服務的群體提供服務。當這個程式出現問題甚至 bug 的時候，我們還得扮演牧師的角色去修復這些問題。」讓我又從另乙個方面認識了所謂程式設計，所謂開發，就是建立乙個程式的社會，我們都在這個社會中扮演重要的角色，
技術的產生是為了解決乙個業務目標（比如取火），這裡解決的是人類自己的問題，實現人類的利益，技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。一般是先有技術，才會有架構。這些其他技術（弓弦拉動木棍），是從直接解決問題的初始主要技術中分拆出來形成的，並通過樹狀結構和主要技術（鑽木取火）組合在一起。在解決主要問題（生火）之後，再開始逐漸的分拆為更為細粒度的技術（弓弦轉木棍）。
最後講解了業務人員和技術人員的衝突產生以及解決，這裡就提到了軟體架構師重要性，架構師應該承擔起解決業務問題的這個角色來，專注於 business domain 和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。
總結
在閱讀完《架構漫談》系列文章之後，我感覺自己之前的一些關於軟體，關於編碼的認知在不斷的被重新整理中，以及了解了軟體架構的必要性和必然性，以及要成為一名軟體架構師要具備的能力，和承擔的角色，已經架構在整個軟體開發中的作用。
架構漫談閱讀筆記03
所有的概念基本都有乙個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的乙個最大的前提就是要搞清楚 是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。以上面切土豆的例子來分析 女主人提出...
《架構漫談》閱讀筆記
在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的 當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的 一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的...
《架構漫談》閱讀筆記
架構漫談是由資深架構師王概凱執筆的系列專欄，通過對其閱讀，我從中逐步認識到了什麼是架構，怎樣做好架構，軟體架構如何落地等內容。一 什麼是架構 在軟體行業，對於什麼是架構一直有很多的爭論。事實上，架構在軟體發明時的n多年以前，就已經存在了，這個詞最早出現在建築上。架構產生的五個動力可以概括為 由個人執...