畫與軟件項目
這篇博客開始寫很久了，都已經在我隨筆列表的第三頁了，然而因為各種原因一直拖著沒有寫完，所以下面可能出現的最近未必是真的最近。還有最喜歡的兩幅畫沒放進來，有些遺憾，分別是現藏於中國美術館的萬山紅遍層林盡染和常熟田。因為一個意外的契機開始，很長時間以來不斷的去各種畫展，有美術館、畫院，也會去私人的畫廊。雖然看不懂，但是畢竟好看的不好看還是能看出來的、賞心悅目，懂不懂什麽的......。藝術可以觸動人的感性思維，我就屬於感性思維有缺陷的，期望能被藝術品感染一下，彌補點這方面的缺陷，或許也能借他山之石在技術方面有所感悟也未可知......吧，總之既然能感受其中的美目前也就足夠了，就像某個段子說的，喜歡吃冰淇淋並不需要先學會制冷。看的時間長了就會有一些與自己工作相關的感觸。另外，在聽一些數學、力學課的時候，偶爾會意外得聽到一些關於藝術的認識，我覺得很適合先給大家看一下。
萊布尼茨：音樂，是人類精神通過無意識計算而獲得的愉悅享受。
下面這張圖是我聽清華力學課的時候，截下來的一張截圖：
別的不多說，只說經常在美術館聽到的一類評價，這畫畫的真像。我個人是覺得畫得像應該是相機出現以前的事，之後更多的應該是畫家在畫中表現出的感悟，或者某些畫面對畫家的觸動，這類甚至在有些攝影藝術中也難以展現出來的令人"愉悅"的"無意識計算"。
畫家以畫展示所思所感，觀者因畫中感性被畫家心境引導出自己的心境。其實我們做需求的時候多數也是這樣的，讓客戶提需求，很難能提出什麽來，但是你做出點東西以後，他就會有這樣那樣的想法，這樣那樣的改法，相對這句話我們就是畫作者，客戶就是觀者，我們需要引導出客戶的真實需求，是想提高辦公效率還是輔助標準化辦公流程，我真實遇到過一個項目，客戶提出的需求和最終的目的有一定沖突，事實上多數項目都有這種問題，只是有時候不難麽明顯，不過頻繁修改的需求很多都是這種原因。
關於開頭的第一句話：“畫家以畫展示所思所感，觀者因畫中感性被畫家心境引導出自己的心境”。太宗以史為鑒，我現在有機會以畫為鑒，品味被畫家引導出的自己的心境。以觀者的角度體味能被畫引導出的對自己的認識，凡事需先認清自己，方能擇一適自己所行之路。有了需求就需要開始選型，能從畫中發現自己有什麽能與之共鳴，我們要使用什麽樣的技術和框架幫助自己完成項目，選擇之前就要首先認清自己，擅長什麽、能多大程度上使用從未接觸的技術、團隊的技術組成、人員性格、配合的默契程度等等。
明確了自身的情況，也更容易設計出自己團隊可以完成的業務模型，並在期限內完成它。由於接連不斷的去看畫，總是有新的想法，所以改了很多次，原本打算在博客最後引出的我對貼在DDD初學指南的對評論的回答，但是由於某天看了王衍成先生的畫，於是我決定在這部分寫了。關於“業務模型更接近現實
其實開始沒什麽感覺，只覺得是水邊倒影，直到走到這個角度：
說句實在話，走到這個角度，其實我也完全不知道他在畫什麽，但是這時這幅畫突然給我一種林間小路的感覺，雖然本來覺得更像是水面，不過感覺到了上午緊張工作的大腦突然放松了，不管作者究竟想表達什麽，看畫人有所觸動也就夠了，就像某些閱讀理解的答案中常說的：留給讀者無限的想象空間。畫通過畫家對所畫之物的抽象來表達畫的核心，軟件通過業務邏輯的抽象來體現軟件的核心價值。
王先生的畫幾乎畫名都是無題，他應該只是想傳達他的一種感性，一種體會到的感覺，並不想說明白那是什麽，其實感性很多時候是沒法說明白的，所以才說是無意識的計算，只要目的達到了，究竟畫的是什麽不太重要。軟件模型也是，最重要的不是設計出了什麽，而是是否完成了目標，模型是手段，手段通常是不應該喧賓奪主的。當然，這並不是說手段不重要，畫的名字本身就是落在畫之外的一種手段：
畫名很多時候是核心概念的表達，相對於軟件是系統的核心價值，業務方的表達傾向於描述現實他們需要的功能，而這可能並不是軟件真正的需求，有時候在需求說明書的不起眼套路段落中，有時候甚至不會出現。他們的目的或許是加快工作效率，或許是限制職能權限，或許是調整業務方向，如果不確認好真正的目的，只按他們對現實的描述去做，絕大多數時候會導致後期大幅調整，這一點不只是業務，在技術理論中也是一樣的，某一處差之毫厘，整個系統謬以千裏。
這畫說實在初看時沒什麽感覺，然而一看名字，乾坤一草堂，再看畫面，以草堂為中心頓感草堂之簡與畫面自然映照，其草堂當為詩人畫家觀湖光山色之處，滿幅乾坤圖盡收與草堂之中，頓感豪氣，令人精神振奮。名字之重要程度可見一斑。而做需求的時候也不能僅僅關註系統之內的功能，系統之外的主題更是核心。
王先生的畫對我們來說可能有些太抽象了，我們來看一個不那麽抽象的，並且有名字的：
這幅畫也是在中國美術館看到的，時間由點長了，沒記錯的話畫名叫藍天，作者是張立國先生。這幅畫最重要的部分很顯然左上角的一小塊藍天，能說明它是藍天模型的也只有一小塊雲，或者還有它的位置，然而已經足夠表現出它作為核心子領域的業務概念了；這幅畫的架構清晰，表達出來的業務對象也非常明確，但並沒有去逐漸貼近現實去建模；三面圍墻（姑且認為是墻吧）和墻下之人以及一點藍天就是整幅畫，畫中之人或許在望天或許是渴望輕松自然；墻的顏色不同，也或許是現代化的生活築起的高墻隔開了人與人之間的關系，然而他們或許都是向往著同一片藍天，當然三人也可能在同一件屋子中。至於究竟如何，或許不重要，每個人的觸動或許也是如人飲水冷暖自知，看懂畫家在畫什麽並不重要，只要對畫有所觸動，便也算沒有白看，畫的價值也在與此。清晰的架構和業務模型，更利於表達相對清晰的感情，至少我的感想被限定在了一個小範圍內，而王先生那副畫，有時看著像林間小路，有時候又覺得草樹池塘，偶爾還會春綠秋黃，但一切都是為了最終目的，無題亦是主題，不能因為技術潔癖或對模型本身的最求而使目標有所偏差。一幅畫要想感染人，我想畫家並不是單純的只想畫得像，不然照照片就可以了；軟件同樣如此，我們開發軟件目的並不是要讓它做出現實人做的事，而是讓用戶借助它更好的完成工作。
剛剛提到了，好的模型一定是最簡化的模型，大家都明白這個道理，但是做的時候，經常會不自覺的為了讓模型看起來邏輯上更完整，更“合理”而增加些東西，例如群裏曾經討論過論壇帖子的回復是否要作為帖子聚合的對象，因為帖子刪了，回復的存在可能就沒有意義了，但是這個看起來邏輯上更完整的約束是否有價值就未必了。1+1=2，是因為抽象出了現實中的數量這一屬性，但是如果一個1是男人，另外一個是女性，這1+1極有可能結果會是3，然而數學可不能這麽算，所以業務模型的抽象與真實的現實，並不一定要統一。
這是在一家私人畫廊看的，雖然不是畫，不過也差不多，關於這件作品的講解：http://www.vart.cc/guides/1141?fragment=9799，我也不多介紹了。此作品的作者農西奧的一句名言，大家有沒有覺得比較熟悉。。。
到這可以先小結一下開篇的那個問題了，模型未必應該貼近現實，而是抽象出現實的某一部分，其實這也並不是很貼切，模型的目的是為了更好的實現整個系統，只是一般情況下這樣更容易開發而已，關於部分抽象這事可以看一下下面的作品與現實的對比，我就不多說了，更何況一個完全不按現實去抽象的模型就一定不利於系統開發麽，面向對象出現以前就沒有好的軟件系統麽？
上圖為潘天壽先生的畫與原型對比。其實前些天公司組織去長城拓展，我拍的照片總覺得不好看，一度非常懷疑我萊卡的鏡頭，後來想明白了：之所以看著很好看，但拍出來效果不好是因為人會選擇性忽略一些不重要的東西，相機不會，所以有電線等東西照進來，所以會感覺沒看到的好看，經常在美術館拍的畫也是，現場看很漂亮，但是很多畫是在玻璃保護中，玻璃的反光導致照下來的根本看不出效果。所以畫也好我們的模型也好，如果想要滿意，該忽略的東西無論在現實中多重要都是要忽略的。
這個問題我的看法大概就是這樣了，似乎這個結並不怎麽小，不過就不要在意這些細節了。
開篇就是一張抽象畫可能不是很容易找到方向欣賞畫。其實小學就學過，萬物都是有聯系的。畫和程序都是人創作出來的，既然不懂美術，可以試著從軟件的角度來欣賞一副畫，即使和原作者想表達的不同，只要能有所得就不算白看了，就像nginx，本來是個靜態服務器，但是有幾個人真是從靜態服務器的角度用的。
最容易看明白的畫當屬素描了（其他如靜物畫和油畫也多包涵濃重的感情色彩），我之所以覺得素描的傳達的感情色彩少，主要是因為它多是一種記錄寫實，是真正作品創作前的一個標記，用來引導藝術家回憶起當時的感覺（不算學生練筆的），畢竟直接在荒山野嶺畫出成品來即使有素描版，多半也不會展出，我反正是沒見過。也不是說素描一點感情色彩都沒有，當然是有一定傾向的，但是我看不出來（極個別除外），手裏畫的圖片太多了，常見的鉛筆素描沒翻到，但是找到了幾張水墨寫生：
素描很多時候看不出，我個人覺得可能也不需要看出畫家想表達什麽，多是對應成品來欣賞的，雖然這兩幅也不是完全沒有韻味。在軟件中，這類還比較多，比如一些通用的開源框架，如Spring Boot，它沒有業務含義，但作為一個可以拿過來就用組件也是非常不錯的，本身也是相當不錯的架構。
基礎設施在有一定的業務傾向，甚至於需求討論之前就可以進行，但可能是伴隨著業務的開發才逐步完成的。關於業務模型的建立和落實到開發上，多數現在還是一個並列的過程，一次性設計一個完整的模型，之後再按著模型按部就班的開發。但是這種方式其實是幾十年前的經典，在一定規模下，還是成功的。而現在已經不再是那個時代了，市場瞬息萬變，政策也總在調整，需求無法一成不變。若是一個工期一年以上的項目，按第一版出的模型去做，股市可能都差了幾千點了。其實，畫畫也是需要一遍一遍叠代的。
先有一個大體方向，然後從主要部分開始，一點一點的豐滿，再細化叠代。我試驗過一些建模和落地的理論，其中在項目中最成功的應該屬於測試驅動+T型功能導向集成（在功能構建中描述過）。比如人像，臉當然是最重要的部分，於是先構造出頭部輪廓，再以頭部輪廓為基礎，逐漸延展開來。對於開發，我們就先開發最核心、穩定的模型和功能，以此為基礎，逐漸開展相關的模型和功能，並根據實際情況逐漸調整，比如今天碳...不夠...黑，就多圖兩筆...什麽的。測試驅動開發也是一個非常好的實踐，很適合輔助功能導向的集成。以單元測試組成業務的結構，也就是畫的輪廓組成，最初的被測試方法內部可能只是返回了個偽造的結果，過程中也不一定時時刻刻都是完善的，臉第一次上色的第四幅看上去並不怎麽好看，集成測試開始後，結合整個畫面也可以看出到了第五幅臉似乎顏色有些過重了，就根據當時的具體情況對功能做一定的調整，為了項目的順利完成，對需求和功能甚至於模型進行適當的刪減調整也是必要的。當集成測試完成，色彩填充畫的各部分的精神被聯結起來，被單元測試過的代碼內部實現豐滿連通，畫就完成了。
其實，我本來是想用齊白石老先生的草稿來著，那一系列草稿更明顯更豐富，然而我沒找到，那些草稿在畫院，偶爾會展出，碰到的時候再說吧。對於上面這畫，人像應該就屬於核心子域，但是只有一個核心是不成的，其實經常也能看到一些不錯的話，但是畫面不夠豐滿，給人的感覺總想缺了什麽的。 對這幅畫來說，畫面上的題字恰到好處。軟件架構通常也是圍繞著業務核心，延展出各個通用子領域，各部分相互獨立，但並不能缺少。一旦某部分的業務膨脹，也可以將其獨立為一個上下文，它對於原有系統是一個支持子域，對於自身也是一個核心子域。也有遇到過這種情況，一幅畫上的題字特別漂亮，大家都不去關心主要部分的畫，而是看字了，而既然被展出了，就說明了其藝術價值。這種情況也並不是壞事，比如互聯網企業本身就是隨著市場發展而變化，比如只去京東和亞馬遜自營買東西，大家也少不了用支付寶。
核心子域和非核心子域在開發中投入的比重也未必一定是核心最重，比如上面的乾坤一草堂。我們在做項目的時候，每一層面都是在找一個平衡，因為平衡並不是有固定規律的，所以很多書才會說，軟件是門藝術。我在網上聽清華大學數學建模課程的時候，姜啟源教授曾講過，技術大致有章可循，而藝術無法歸納成普遍使用的準則。雖然姜教授是在講數學建模，但我認為貫穿整個項目的每一個部分都是這樣的，無論是需求與開發團隊資源之間的平衡、模型距離現實遠近之間的平衡，還是開發時實現的優雅與性能之間的平衡（當然，個別時候未必不可兼得）。這些平衡並無一定之規。比如下面這幅環保題材的畫，小姑娘、彩色的氣球、小狗、後面的煙囪、以及看不清後面是工廠還是廢墟的影影綽綽，無處不是模糊與清晰之間平衡的體現，清晰一點或再模糊一些都未必能有如此效果。
也不必為框框架架約束，不一定實現的要華麗。極有可能很簡單的實現也能恰到好處，當然，恰到好處說起來容易，既然無法規定普適的規則怎麽辦呢，我的經驗是，當模型或實現等可以讓自己覺得不別扭、或者念頭通暢就可以了。開頭萊布尼茨的名言暗示了一點，我們的無意識計算或者直覺可以幫助我們找到自己根據現有資源所能達到的最好平衡。
最後再看一幅畫，這幅畫非常簡單，但傳達的感性非常豐滿。我們做軟件也是一樣，只要有合適的數據結構，體會畫的動與靜，抽象程度未必需要非常精細，特地強調這點因為說起來容易，其實很多人，尤其是有代碼潔癖的人非常容易把數據結構設計的非常精致，下手之前還在想要把握分寸，但是一旦開始就一發不可收拾，我以前就經常這樣。下面這幅畫中核心部分是一個出門迎接陽光的人，這人看起來只是隨便畫了些輪廓陰影，但是恰到好處，線條並不覺得亂，而大面積的房間簡約而不簡單，墻上一幅樹葉既使畫面豐滿，也能突出主人向往春天，我初看時還有一種在家臨淵慕魚不如出門享受陽關，退而結網腳踏實地一步一步走出去的感覺。
------------------------------------------------------------------------------------------------------
公眾號：
畫與軟件項目