架構漫談感想

      看了架構漫談這篇文章，使我感觸很深。文章中先是從架構的起源來談的。架構在軟體發明之前就已經存在了，是随着建築興起的。早期的人類完全是自己自足的，各自幹各自，都是獨立的個體，互不往來。為了解決種族延續，于是出現男女群居，進而出現了分工。分工出現後，每個人的生産力都得到了提高，因為做的都是各自擅長的事。在每個人都必須自己完成所有生活必須品的生産的時候，是沒有架構的。一旦産生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，隻需要每個個體做好自己擅長的事情，并具備一定的交易能力即可。 這實際上就形成了社會的架構。架構實際上就是指人們根據自己對世界的認識，為解決某個問題，主動地、有目的地去識别問題，并進行分解、合并，解決這個問題的實踐活動。架構的産出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合并的原則以及理由，以及拆分，拆分出來的各個部分和合并所對應的角色和所需要的核心能力等。這讓我不禁想到，大二的軟體工程課程上四人結組做的大作業，我們也是分工寫的，也相當于一個最最基礎的架構吧，分工合作的出現，于是産生了架構，就像老師說的，金山創始人之一求伯君最開始是自己一個人編的這個軟體，那時候并沒有架構，等到軟體越做越大，合作出現的時候，才有了架構。架構實際上解決的就是人的問題。

　　認識概念是了解架構的基礎，作者用“一個杯子的故事”引入概念的解釋。概念也屬于人認識這個世界并用來溝通的手段，包括“概念”這個概念，也是一樣的。在古代，不叫“概念”，稱之為“名相”。相實際上代表的是這個作用，并不是具體的某個東西，而名是用來辨別這個作用的，用來交流的。是以說，每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了一個名字，這個名字就是對應的某個特定的概念。根據架構的定義，要做好架構所首先必須具備的能力，就是能夠正确的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目标領域所需要解決的問題，這樣才能夠為做好架構打好基礎。

　　其次就是識别問題。記得老師舉得“切洋芋”的例子，問這是什麼問題，很多同學都回答溝通，或做洋芋的問題，其實我開始也想的是溝通的問題，因為女主人沒有表達清楚自己的意思，進而男主人切錯了洋芋。通過老師的講解和閱讀這篇文章後，我深刻的了解到：出現這個現象是由于我們大部分時候過于關注解決問題，急于完成自己的工作，而不關心“真正的問題是什麼”而造成的。當我們去解決一個問題的時候，一定要先把問題搞清楚。文章中的一句話：“隻有真正投入思考問題是什麼的工程師，才可能會真正的成長為架構師”是我印象深刻，确實在以前的程式設計中都是按照老師給的題目，大緻有一個解決方法就開始編寫程式，并沒關注問題的本身，跟别說思考了，都是通過直覺來解決問題的。是以，找出問題的主體，是做架構的首要問題，我們要解決的問題，一定都是人的問題。還有最重要的任何找上架構師的問題，絕對都不是真正的問題。如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。明白了問題的主體，我們才可能真正的認識問題是什麼。因為問題的主體是問題的隐含邊界，邊界不确定下來，問題就是不确定的。一旦确定了主體，剩下的就是去搞明白主體有哪些問題。是以在以後要正确的認識問題，要注意兩個方面:是誰的問題，有什麼問題。

　　還有就是架構切分。所有的切分調整，都是對相關人的利益的調整。切分的過程就是模組化的過程，每次對大問題的切分都會生成很多小問題，每個小問題就形成了不同的概念。這些不同的概念大部分時候人們自發的已經建好了，架構師更多的是要去了解這些概念，識别概念背後所代表的的人的利益。還有就是準确識别采用什麼技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。

　　那麼我們又應該如何寫好代碼呢，這篇文章中也說到了。我的認識就是，前台對使用者的單獨寫一部分，相當于界面，然後業務邏輯的寫一部分，資料庫寫一部分，相當于把軟體代碼分為三各部分。每個部分的職能都很單一，互不影響。就相當于我們這學期學的ssh架構。

轉載于:https://www.cnblogs.com/hyluckydog/p/6490703.html