ddd小白，一篇章節便能激起了心中漣漪，感慨之初，記於筆下。 第1章 消化知識 用醍醐灌頂、茅塞頓開來形容此章短短的文字，實不為過。 簡單介紹背景：旅游互聯網，B2B，初創公司。產品設計-代碼開發的銜接有過兩種明顯形式： 1. 項目的推進由產品部起頭，收集、分析、過濾需求，形成原型文檔（word，e ...
ddd小白，一篇章節便能激起了心中漣漪，感慨之初，記於筆下。
第1章 消化知識
用醍醐灌頂、茅塞頓開來形容此章短短的文字，實不為過。
簡單介紹背景：旅游互聯網，B2B，初創公司。產品設計-代碼開發的銜接有過兩種明顯形式：
1. 項目的推進由產品部起頭，收集、分析、過濾需求，形成原型文檔（word，excel，visio，axure），提交CTO、CEO評審（整個產品90%的原型、流程、欄位），交付開發、測試工程師。
開發工程師花一兩天理解、討論原型文檔，而後建立資料庫表，開擼代碼，按模塊交付測試工程師。
2. 曾經有一段時日，管理層要求打破部門的界限，以項目組為單位，每個項目組有產品經理、開發工程師、測試工程師。項目小分隊高內聚，分隊間低耦合。開發與測試充分介入產品設計階段，產品原型文檔定稿之時，開發與測試心中也將早已心領神會。
經多方因素，情景2還是回到了情景1的狀態，主因有：部門座位區分離、部門內部討論頻率更高、項目較多開發節奏甚緊導致開發沒有更多的時間加入產品設計（一句玩笑也害人——作為開發的你和產品討論一天設計，他的產品設計有了，你的代碼還沒有——啊，多麼痛而現實的打工者）。
回想上述1、2情景，孰優孰劣，或更優何在？
我曾與公司一位善於思考的產品經理討論時提出觀點：若產品的設計已完成了較小粒度（也許是按模塊，或按功能）的閉環，便可提前交付開發——在該產品所有功能模塊都設計完之前。意在平衡"完全設計再交付開發的瀑布"與"完全重疊討論產品的時間浪費"之間的關係，找到平衡點。現在想來，當時的愚見仍然幼稚。
一直縈繞耳邊的有兩個思考：
1. 曾聽到有經驗的開發人員向產品經理抱怨：你們的產品設計要有模型建立，經過實踐，不要我們開發做著做著發現模型不對又調整。（模型是什麼？word、excel、axure？）
2. 幾個月前，我負責開發一個企業基礎設置管理的模塊，市面上我能普通查找到的做法都不符合CTO對我的要求，故我只能重新做代碼設計（產品經理忙別的項目去了，此管理模塊直接由CTO表達期望結果，由碼農我直接實現）。在經過了長達一周的反覆檢驗、討論、再檢驗，終於定下了較為詳細的代碼設計（即類之間的關係、界面交互效果、持久化關係）。其中需要另一位善於技術框架的開發工程師提供相關介面，在簡單-詳細-詳盡描述意圖後，他拒絕了介面的提供，原因是：這樣設計是不合理的，市面上沒有這樣的設計，沒人這麼做。而我也確實沒有十足的理由進行反駁，只能退到"用戶習慣、設計要求"的擋箭牌之後（市面上沒這麼做的，就說明咱不應該這麼做嗎？）
閱讀了第1章 消化知識，我有了第一份答案（也許未來的第二份會完全推倒，那就太棒了，說明我在進步）：
答1：應該建模，尤其對於複雜業務邏輯，以減少（肯定無法避免）需求變動帶來的較大調整，但是建模不只是產品的事、更是開發的事，建模的結果可以是若幹實現核心業務邏輯的單元測試程式。
答案受啟發於書中P9：隨後，我們又拿出一部分工作時間進行了幾輪這樣的討論，我覺得自己已經理解了足夠多的知識，可以試著編寫一些代碼了。我寫了一個非常簡單的原型，並用一個自動測試框架測試它。我避開了所有基礎設施。這個原型沒有持久化機制，也沒有用戶界面（UI）。這樣我就可以專註於代碼的行為……雖然它使用的是虛擬數據，而且像控制台輸出的是原始文本，但確實是……執行實際的計算。
對於複雜建模，開發可以對核心業務邏輯進行梳理後，建立無關界面、存儲的類間交互，形成單元測試，並提交產品設計優化核心代碼——這是不是比原型文檔更接近與模型的感覺了？
答2：最終的結果，善於學習的開發工程師一邊保留著他的堅持，一邊給了介面，畢竟要爭論就不得不多次面對再設計與撕X的過程。市面上的沒有，並不代表我們的開創就是錯誤的，這不是盲目創新，而是要忠於用戶需求（當然至於這是否是用戶需求，我認為開發人員應充分相信團隊的產品設計者，畢竟這是合作的前提）。
答案受啟發於書中P3：軟體的核心是其為用戶解決領域相關的問題的能力。所有其他特性，不管多麼重要，都要服務於這個基本目的……大部分有才能的開發人員對學習與他們的工作領域有關的知識不感興趣，更不會下力氣去擴展自己的領域建模技巧。技術人員喜歡那些能夠提高其技能的可量化問題……技術人才更願意從事精細的框架工作，試圖用技術來解決領域問題。他們把學習領域知識和領域建模的工作留給別人去做。軟體核心的複雜性需要我們直接去面對和解決，如果不這樣做，則可能導致工作重點的偏離。
"很少有開發會來探討和深入瞭解需求"，被我固執地認為是那位善於思考的產品經理做出的好的評價 :)
書中P11：領域模型的不斷精化迫使開發人員學習重要的業務原理，而不是機械地進行功能開發……模型在不斷改進的同時，也成為組織項目信息流的工具。模型聚焦於需求分析。它與編程和設計緊密交互……模型永遠都不會是完美的……模型對理解領域必須是切實可用……以便使應用程式易於實現和理解。
這進一步向我們傳遞：建模應該有開發的身影，且應該是項目組共同商討、一同反覆檢驗和完善的產物，是知識積累的方式，是未來程式實現的原型，是關鍵代碼的主心骨。
一年前我接觸了公司產品中第一版訂單系統，流程錯綜複雜，特殊性較強，在深刻瞭解需求後——複雜之處在於：對於訂單流程中的不同狀態，買賣雙方可操作的內容不同。若仍使用代碼中的if-else解決，代碼量之多、代碼意圖之隱晦將是一枚定時炸彈。在參見23中經典設計模式之後，決定借鑒狀態模式——重寫訂單後端核心業務邏輯（前端不變）。能看到的效果是：原if-else的設計，bug總是改不完，總會有邏輯錯綜交互而疏漏之處；狀態模式的設計，將訂單狀態間解耦，獨立變化，獨立發展，能找到業務邏輯bug，那是你本事。
一年後的今天，產品升級換代，第二版訂單系統對第一版做了調整，增加了買賣雙方分開處理、不同來源走不同的訂單流程的複雜性，在參照（照搬絕壁也是個死）自己去年的狀態模式設計後，加入了橋接模式，更獨立處理"訂單操作"與"訂單狀態"。逐漸體會到了書中P12的航程-貨物示例——我們將超定規則轉移到領域對象中——訂單交互邏輯與界面、持久化無關，完全是判斷走向與限制可修改屬性等記憶體級的事情，故將邏輯抽離service，放入domain，不但利於代碼寓意傳遞，也利於無關ui、db的單元測試，更利於領域業務獨立處理。但我遇到了一個問題：類似超定規則的事情還有很多，如何把他們都扔到領域對象當中，是一個問題，最後我疲於穩定，妥協於項目進度，暫且延緩。此時我看到書中P14的一句話似乎提點了我——我並不建議將這些精細設計應用到領域的每個細節中。第15章將深入闡述如何關註重點以及如何隔離其他問題或使這些問題最小化——天啊，我已經迫不及待跳到15章尋求答案了，但我還是原意保留這個疑問，因為的確當下我只需要知道我似乎歪打正著做了一件對的事情就好了，至於理由，我可以下一步再知其所以然。
2016年寫代碼多，讀書籍少，博客園也來得少了。閱讀筆記有一些好處：
1. 閱讀本來只需1h，可記錄卻在要求你反覆細品值得細品之處。
2. 閱讀的過程中不免思考，放下書本，思考一會，記錄下來，利於思路的整理與表達，甚至可能發現更多閃光點。
3. 一邊閱讀，一邊記錄。當你閱讀完一整本再回頭看這些閱讀筆記，一定會發現自己以前是個傻x，太棒了，成長也。
文初提到"醍醐灌頂、茅塞頓開"，意在：有一些纏繞心中的問題（這些問題可以不予解決的確也能碌碌終生，畢竟不是代碼問題那樣務必需要解決的硬骨頭），但當你遇到一些觀點尤其是已經過實踐認證的大神的觀點，能夠指引甚至直接給出問題的答案時，簡直直戳心窩——在你最需要時出現的，帶來的幸福指數最高。
願讀者朋友們都能"遇"到如此"暖心"的讀物。
