按照之前閱讀之後得到的架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。
女主人公：老公，把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半，然後下鍋。這個笑話是書中所提到的，也是我們老師上課提到過的。引人深思，老公做的有錯嗎？有的話，為什麼老公就是不知道女主人公的意圖呢？可能就是倆人不了解對方。
接下來是筆者的看法：當然很多人會說，這個是溝通問題，然後一笑了之。其實，出現這個現象是由於我們大部分時候過於關注解決問題，急於完成自己的工作，而不關心「真正的問題是什麼」而造成的。當我們去解決乙個問題的時候，一定要先把問題搞清楚。這也是我為什麼要單獨寫一篇文章講這個的原因。去看看軟體開發工作者的時間分配也可以看出，大家大部分時間花在討論解決方案和實現的細節上，基本都不會花時間去想「問題是什麼」。或者即使想了一點點，也是一閃而過，憑自己的直覺下判斷。只有真正投入思考問題是什麼的工程師，才可能會真正的成長為架構師。
以這個笑話為例，看看在我們處理問題的時候，都會犯什麼樣的錯誤：
那麼如何識別問題呢?
所有的概念基本都有乙個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的乙個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
以上面切土豆的例子來分析：
女主人提出乙個問題，要切土豆下鍋煮。
男主人有乙個問題，女主人交代了自己必須要完成的乙個任務。
每個人都是優先處理自己的問題，自然就選擇了2，完成了這個任務。這也是大部分軟體工程師處理的方式，以自己認為對的方式完成自己的問題，沒什麼不對啊，也難怪能得到我們的共鳴。這個裡面犯的錯誤是什麼呢?
首先，女主人公提出的實際上是解決方案，而不是燒土豆這個問題本身。女主人當時執行這個解決方案可能有困難，就把執行解決方案作為乙個任務，委託給了男主人。其次，男主人得到了乙個任務，盡心盡職地把這個任務完成了。
最後的結果是什麼呢，每個人都做了很多任務作，每個人都認為自己做的是對的，因此沒有乙個人對結果滿意。因為真正的問題沒有被發現，自然也就沒有被解決，那麼後續還得收拾殘局，還要繼續解決問題。事實上自己的工作並沒有完成，反而更多了。把原因歸結為溝通問題也是可以的，但對於解決問題似乎並沒有太多的幫助。因為要改進溝通，這也是乙個大問題。搞明白目標問題「是誰的問題，是什麼問題」，當然也是需要溝通的。為了幫助自己更快的搞明白，首先要做的事是問正確的問題。架構師應該問的第乙個正確的問題就是：目標問題是誰的問題。
當我們處理問題的時候，如果發現自己正在致力於把自己的工作完成，要馬上警惕起來，因為這樣下去會演變成沒有ownership的工作態度。在面對概念的時候，也會不求甚解，最終會導致沒有真正的理解概念。
在我看來：身為軟體工作人員的話，最重要的還是要知道使用者其實想要的是什麼樣的軟體，他的淺層次的需求，都需要我們挖掘出來。
根據筆者的總結的話要正確的認識問題，需要問兩個問題：
這是誰的問題？
有什麼問題？
當得到的回答是支支吾吾的時候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經驗，問題1會花比較多的時間，也是支支吾吾最多的地方，因為架構要解決的問題都是人的問題。但是一旦確定了答案，問題2就會變得非常容易。可以這樣說，架構師的能力大部分會體現在問題1的識別上。
《架構漫談》閱讀筆記三
今天將 架構漫談 又讀了一遍，在此進行了總結 第一篇主要在介紹了什麼是架構以及為什麼會產生架構。文章中提到，架構是把乙個整體切分成不同的部分，由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為乙個整體，並完成這個整體所需要的所有活動。比如平時像我們學習中有很多情...
架構漫談 閱讀筆記（三）
作者 了軟體發展火熱的根本原因以及軟體扮演的角色等問題。就像說中所提到的我們並不缺架構實踐，而是缺少對於架構的反思。軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家 包括在這個歷史過程中的參與者 有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。從馮諾依曼結構開始，程式邏輯開始脫離硬體，...
架構漫談閱讀筆記三
在識別出問題後，大部分問題都會迎刃而解，但還是會有一些問題需要做出相應的調整，也就是架構的切分。切分是乙個很生動的詞彙 切分團體中每個人應得的 蛋糕 也就是合理分配每個人的利益。利益是乙個人生存的根本，所有維護利益是每個人的本能，人不為己天誅地滅 正是由此而來。有捨才有所得，在這個模式下，每個人都必...