日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
我們一起聊聊如何從容應(yīng)對復(fù)雜性

但是一直都是開發(fā)過程中的一個難題，本文旨在探討如何去從容應(yīng)對復(fù)雜性。

創(chuàng)新互聯(lián)建站科技有限公司專業(yè)互聯(lián)網(wǎng)基礎(chǔ)服務(wù)商，為您提供遂寧托管服務(wù)器，高防主機(jī)，成都IDC機(jī)房托管，成都主機(jī)托管等互聯(lián)網(wǎng)服務(wù)。

一、軟件的熵增、構(gòu)造定律

1.熵增定律

熵的概念最早起源于物理學(xué)，熱力學(xué)第二定律(又稱“熵增定律”)，表明了在自然過程中，一個孤立的系統(tǒng)總是從最初的集中、有序的排列狀態(tài)，趨向于分散、混亂和無序;當(dāng)熵達(dá)到最大時，系統(tǒng)就會處于一種靜寂狀態(tài)。

軟件系統(tǒng)亦是如此， 在軟件系統(tǒng)的維護(hù)過程中。軟件的生命力會從最初的集中、有序的排列狀態(tài)，逐步趨向復(fù)雜、無序狀態(tài)，直到軟件不可維護(hù)而被迫下線或重構(gòu)。

2.構(gòu)造定律

自然界是如何應(yīng)對這復(fù)雜性?

這在物理中被稱為構(gòu)造定律 (Constructal Law), 是由Adrian Bejan于1995提出的：

For a finite-size system to persist in time (to live), it must evolve in such a way that it provides easier access to the imposed currents that flow through it.

對于一個有限大小的持續(xù)活動的系統(tǒng)，它必須以這種方式發(fā)展演進(jìn)：它提供了一種在自身元素之間更容易訪問的流動方式。

這個定理在自然界中比比皆是，最典型的比如水循環(huán)系統(tǒng)，海水蒸發(fā)到大氣，下雨時降落在地面，一部分滲入地面流入江河，一部分繼續(xù)蒸發(fā)，不斷循環(huán)。這種自發(fā)性質(zhì)的設(shè)計反映了這一趨勢：他們允許實體或事物更容易地流動 - 以最少的能量消耗到達(dá)最遠(yuǎn)的地方，就連街道和道路這些人為地構(gòu)建物體，往往也是有排序的模式，以提供最大的靈活性。

二、如何應(yīng)對軟件系統(tǒng)的復(fù)雜性?

軟件系統(tǒng)的復(fù)雜性往往是被低估的。復(fù)雜越高，開發(fā)人員會感到不安。對其的理解認(rèn)知負(fù)荷代價就越高，我們就更不快樂。真正的挑戰(zhàn)是在構(gòu)建我們的系統(tǒng)時要保持其有序以及工程師的生產(chǎn)方式。

Ousterhout教授在《軟件設(shè)計的哲學(xué)》書中提到：軟件設(shè)計的最大目標(biāo)，就是降低復(fù)雜度(complexity)。

就是設(shè)計符合業(yè)務(wù)的構(gòu)造定律的演進(jìn)方式，一種可以以最小的開發(fā)維護(hù)成本， 使業(yè)務(wù)更快更好的流動發(fā)展的方式。

三、軟件復(fù)雜性來自哪里， 如何解決?

1.不確定性的來源

（1）業(yè)務(wù)的不確定性

（2）技術(shù)的不確定性

（3）人員流動的不確定性

2.如何面對不確定性

面對外部的確定性，轉(zhuǎn)化為內(nèi)核的確定性。

面對外部的不確定性，找到穩(wěn)定的內(nèi)核基礎(chǔ)。

專注問題域

當(dāng)下互聯(lián)網(wǎng)發(fā)展速度是迅猛的， 軟件的形態(tài)也在不斷的變化演進(jìn)。面對未來的業(yè)務(wù)及變化，橫向業(yè)務(wù)與縱向業(yè)務(wù)的發(fā)展都是不確定性的。

Robert C. Martin提到的BDUF，永遠(yuǎn)不要想著在開始就設(shè)計好了全部的事情(big design up front)，一定要避免過度設(shè)計。除非能夠十分確認(rèn)的可預(yù)見變化， 業(yè)務(wù)邊界，否則專注解決當(dāng)前1-2年內(nèi)業(yè)務(wù)變化設(shè)計, 講好當(dāng)下的用戶故事，專注解決眼前的問題域。 面向不確定設(shè)計，增量敏捷開發(fā)。

確認(rèn)穩(wěn)定的系統(tǒng)內(nèi)核

隨著業(yè)務(wù)的變化、系統(tǒng)設(shè)計也要持續(xù)演進(jìn)升級。沒有一開始就完美的架構(gòu)， 好的架構(gòu)設(shè)計一定演化來的，不是一開始就設(shè)計出來的。

一個健康公司的成長，業(yè)務(wù)橫向、縱向會發(fā)展的會越來越復(fù)雜，支持業(yè)務(wù)的系統(tǒng)也一定會越來越復(fù)雜。

系統(tǒng)演進(jìn)過程中的成本，會受到最開始的設(shè)計、系統(tǒng)最初的內(nèi)核影響的。面對外部業(yè)務(wù)的不確定性， 技術(shù)的不確定性，外部依賴的不確定性。一個穩(wěn)定的內(nèi)核應(yīng)該盡量把外部的不確定性隔離。

  • 業(yè)務(wù)與技術(shù)的隔離。

以業(yè)務(wù)為核心，分離業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度。

  • 內(nèi)部系統(tǒng)與外部依賴的隔離；
  • 系統(tǒng)中常變部分與不常變部分的隔離；
  • 隔離復(fù)雜性(把復(fù)雜性的部分隔離在一個模塊，盡量不與其他模塊互動)。

3.無序性

系統(tǒng)和代碼像多個線團(tuán)一樣散落一地一樣，混亂不堪，毫無頭緒。

4.如何面對無序性

（1）統(tǒng)一認(rèn)知(秩序化)

（2）系統(tǒng)清晰明了的結(jié)構(gòu)(結(jié)構(gòu)化)

（3）業(yè)務(wù)開發(fā)流程化(標(biāo)準(zhǔn)化)

注：這里說的流程化并非指必須使用類似BPM的流程編排系統(tǒng)。

而是指對于一個需求，業(yè)務(wù)開發(fā)有一定的順序， 有規(guī)劃的先做一部分事情，開發(fā)哪一個模塊再去做剩下的工作，是可以流程化的。

5.規(guī)模

業(yè)務(wù)規(guī)模的膨脹以及開發(fā)團(tuán)隊規(guī)模的膨脹，都會帶來系統(tǒng)的復(fù)雜性提升。

6.如何面對規(guī)模膨脹帶來的復(fù)雜性

（1）業(yè)務(wù)隔離， 分而治之；

（2）專注產(chǎn)品核心競爭力的發(fā)展；

（3）場景分層。

關(guān)鍵場景

投入更多的開發(fā)、測試資源、業(yè)務(wù)資源(比如單元測試覆蓋率在90%以上)在關(guān)鍵場景。

普通場景

更快，更低成本、更少資源投入地完成普通場景的迭代。

7.認(rèn)知成本

是指開發(fā)人員需要多少知識才能完成一項任務(wù)。

在引入新的變化時，要考慮到帶來的好處是否大于系統(tǒng)認(rèn)知成本的提升，比如：之前提到的BPM流程編排引擎，如果對系統(tǒng)帶來的好處不夠多也是增加認(rèn)知成本的一種。

不合適的設(shè)計模式也是增加認(rèn)知成本的一種，前臺同學(xué)吐槽的中臺架構(gòu)比較高的學(xué)習(xí)成本， 也是認(rèn)知成本的一種。

8.如何降低認(rèn)知成本

（1）系統(tǒng)與現(xiàn)實業(yè)務(wù)更自然真實的映射，對業(yè)務(wù)抽象建模。

軟件工程師實際上只在做一件事情，即把現(xiàn)實中的問題搬到計算機(jī)上，通過信息化提升生產(chǎn)力。

（2）代碼的含義清晰，不模糊。

（3）代碼的整潔度。

（4）系統(tǒng)的有序性， 架構(gòu)清晰。

（5）避免過度設(shè)計。

（6）減少復(fù)雜、重復(fù)概念， 降低學(xué)習(xí)成本。

（7）謹(jǐn)慎引入會帶來系統(tǒng)復(fù)雜性的變化。

四、應(yīng)對復(fù)雜性的利器

1.領(lǐng)域驅(qū)動設(shè)計——DDD

DDD是把業(yè)務(wù)模型翻譯成系統(tǒng)架構(gòu)設(shè)計的一種方式, 領(lǐng)域模型是對業(yè)務(wù)模型的抽象。

不是所有的業(yè)務(wù)服務(wù)都合適做DDD架構(gòu)，DDD合適產(chǎn)品化，可持續(xù)迭代，業(yè)務(wù)邏輯足夠復(fù)雜的業(yè)務(wù)系統(tǒng)，小規(guī)模的系統(tǒng)與簡單業(yè)務(wù)不適合使用，畢竟相比較于MVC架構(gòu)，認(rèn)知成本和開發(fā)成本會大不少。但是DDD里面的一些戰(zhàn)略思想我認(rèn)為還是較為通用的。

對通用語言的提煉和推廣

清晰語言認(rèn)知， 比如之前在詳情裝修系統(tǒng)中：

ItemTemplate : 表示當(dāng)前具體的裝修頁面

ItemDescTemplate、Template，兩個都能表示模板概概念。

剛開始接觸這塊的時候比較難理解這一塊邏輯，之后在負(fù)責(zé)設(shè)計詳情編輯器大融合這個項目時第一件事就是團(tuán)隊內(nèi)先重新統(tǒng)一認(rèn)知。

  • 裝修頁面統(tǒng)一使用 —— Page概念
  • 模板統(tǒng)一使用 —— Template概念

不將模板和頁面的概念糅雜在一起，含糊不清，避免重復(fù)和混亂的概念定義。

貧血模型和充血模型

1）貧血模型

貧血模型的基本特征是：它第一眼看起來還真像這么回事兒。項目中有許多對象，它們的命名都是根據(jù)領(lǐng)域模型來的。然而當(dāng)你真正檢視這些對象的行為時，會發(fā)現(xiàn)它們基本上沒有任何行為，僅僅是一堆getter/setter方法。

這些貧血對象在設(shè)計之初就被定義為只能包含數(shù)據(jù)，不能加入領(lǐng)域邏輯;所有的業(yè)務(wù)邏輯是放在所謂的業(yè)務(wù)層(xxxService, xxxManager對象中)，需要使用這些模型來傳遞數(shù)據(jù)。

@Data
public class Person {
    /**
     * 姓名
     */
    private String name;

    /**
     * 年齡
     */
    private Integer age;

    /**
     * 生日
     */
    private Date birthday;

    /**
     * 當(dāng)前狀態(tài)
     */
    private Stauts stauts;
}
public class PersonServiceImpl implements PersonService {
    
    public void sleep(Person person) {
        person.setStauts(SleepStatus.get());
    }

    public void setAgeByBirth(Person person) {
        Date birthday = person.getBirthday();
        if (currentDate.before(birthday)) {
            throw new IllegalArgumentException("The birthday is before Now,It's unbelievable");
        }
        int yearNow = cal.get(Calendar.YEAR);
        int dayBirth = bir.get(Calendar.DAY_OF_MONTH);
        /*大概計算， 忽略月份等，年齡是當(dāng)前年減去出生年*/
        int age = yearNow - yearBirth;
        person.setAge(age);
    }
}
}
public class WorkServiceImpl implements WorkService{

    public void code(Person person) {
        person.setStauts(CodeStatus.get());
    }

}

這一段代碼就是貧血對象的處理過程，Person類， 通過PersonService、WorkingService去控制Person的行為，第一眼看起來像是沒什么問題，但是真正去思考整個流程。WorkingService， PersonService到底是什么樣的存在?與真實世界邏輯相比， 過于抽象?；谪氀Ｐ偷膫鹘y(tǒng)開發(fā)模式，將數(shù)據(jù)與業(yè)務(wù)邏輯分離，違反了 OOP 的封裝特性，實際上是一種面向過程的編程風(fēng)格。但是，現(xiàn)在幾乎所有的 Web 項目，都是基于這種貧血模型的開發(fā)模式，甚至連 Java Spring 框架的官方 demo，都是按照這種開發(fā)模式來編寫的。

面向過程編程風(fēng)格有種種弊端，比如，數(shù)據(jù)和操作分離之后，數(shù)據(jù)本身的操作就不受限制了。任何代碼都可以隨意修改數(shù)據(jù)。

2）充血模型

充血模型是一種有行為的模型，模型中狀態(tài)的改變只能通過模型上的行為來觸發(fā)，同時所有的約束及業(yè)務(wù)邏輯都收斂在模型上。

@Data
public class Person extends Entity {
    /**
     * 姓名
     */
    private String name;

    /**
     * 年齡
     */
    private Integer age;

    /**
     * 生日
     */
    private Date birthday;

    /**
     * 當(dāng)前狀態(tài)
     */
    private Stauts stauts;

    public void code() {
        this.setStauts(CodeStatus.get());
    }
    
    public void sleep() {
        this.setStauts(SleepStatus.get());
    }
    
    public void setAgeByBirth() {
        Date birthday = this.getBirthday();
        Calendar currentDate = Calendar.getInstance();
        if (currentDate.before(birthday)) {
            throw new IllegalArgumentException("The birthday is before Now,It's unbelievable");
        }
        int yearNow = currentDate.get(Calendar.YEAR);
        int yearBirth = birthday.getYear();
        /*粗略計算， 忽略月份等，年齡是當(dāng)前年減去出生年*/
        int age = yearNow - yearBirth;
        this.setAge(age);
    }
        
}

3）貧血模型和充血模型的區(qū)別

/**
 * 貧血模型
 */
public class Client {

    @Resource
    private PersonService personService;

    @Resource
    private WorkService workService;

    public void test() {
        Person person = new Person();
        personService.setAgeByBirth(person);
        workService.code(person);
        personService.sleep(person);
    }
}


/**
 * 充血模型
 */
public class Client {

    public void test() {
        Person person = new Person();
        person.setAgeByBirth();
        person.code();
        person.sleep();
    }
}

上面兩段代碼很明顯第二段的認(rèn)知成本更低， 這在滿是Service，Manage 的系統(tǒng)下更為明顯，Person的行為交由自己去管理， 而不是交給各種Service去管理。

貧血模型是事務(wù)腳本模式

貧血模型相對簡單，模型上只有數(shù)據(jù)沒有行為，業(yè)務(wù)邏輯由xxxService、xxxManger等類來承載，相對來說比較直接，針對簡單的業(yè)務(wù)，貧血模型可以快速的完成交付，但后期的維護(hù)成本比較高，很容易變成我們所說的面條代碼。

充血模型是領(lǐng)域模型模式

充血模型的實現(xiàn)相對比較復(fù)雜，但所有邏輯都由各自的類來負(fù)責(zé)，職責(zé)比較清晰，方便后期的迭代與維護(hù)。

面向?qū)ο笤O(shè)計主張將數(shù)據(jù)和行為綁定在一起也就是充血模型，而貧血領(lǐng)域模型則更像是一種面向過程設(shè)計，很多人認(rèn)為這些貧血領(lǐng)域?qū)ο笫钦嬲膶ο?，從而徹底誤解了面向?qū)ο笤O(shè)計的涵義。

Martin Fowler 曾經(jīng)和 Eric Evans 聊天談到它時，都覺得這個模型似乎越來越流行了。作為領(lǐng)域模型的推廣者，他們覺得這不是一件好事，極力反對這種做法。

貧血領(lǐng)域模型的根本問題是，它引入了領(lǐng)域模型設(shè)計的所有成本，卻沒有帶來任何好處。最主要的成本是將對象映射到數(shù)據(jù)庫中，從而產(chǎn)生了一個O/R(對象關(guān)系)映射層。

只有當(dāng)你充分使用了面向?qū)ο笤O(shè)計來組織復(fù)雜的業(yè)務(wù)邏輯后，這一成本才能夠被抵消。如果將所有行為都寫入到Service對象，那最終你會得到一組事務(wù)處理腳本，從而錯過了領(lǐng)域模型帶來的好處。而且當(dāng)業(yè)務(wù)足夠復(fù)雜時， 你將會得到一堆爆炸的事務(wù)處理腳本。

對業(yè)務(wù)的理解和抽象

限定業(yè)務(wù)邊界，對業(yè)務(wù)進(jìn)行與現(xiàn)實更自然的理解和抽象，數(shù)據(jù)模型與業(yè)務(wù)模型隔離，把業(yè)務(wù)映射成為領(lǐng)域模型沉淀在系統(tǒng)中。

結(jié)構(gòu)與防腐層

User Interfaces

  • 負(fù)責(zé)對外交互, 提供對外遠(yuǎn)程接口。

application

  • 應(yīng)用程序執(zhí)行其任務(wù)所需的代碼。
  • 它協(xié)調(diào)域?qū)訉ο笠詧?zhí)行實際任務(wù)。
  • 該層適用于跨事務(wù)、安全檢查和高級日志記錄。

domain

  • 負(fù)責(zé)表達(dá)業(yè)務(wù)概念。
  • 對業(yè)務(wù)的分解，抽象，建模 。
  • 業(yè)務(wù)邏輯、程序的核心。
  • 防腐層接口放在這里。

infrastucture

為其他層提供通用的技術(shù)能力。如repository的implementation(ibatis，hibernate, nosql)，中間件服務(wù)等anti-corruption layer的implementation 防腐層實現(xiàn)放在這里。

  • 防腐層的作用：
  • 封裝三方服務(wù)。
  • 隔離內(nèi)部系統(tǒng)對外部的依賴。

讓隱性概念顯性化

文檔與注釋可能會失去實時性(文檔、注釋沒有人持續(xù)維護(hù))，但是線上生產(chǎn)代碼是業(yè)務(wù)邏輯最真實的展現(xiàn)，減少代碼中模糊的地方，讓業(yè)務(wù)邏輯顯性化體現(xiàn)出來，提升代碼清晰度。

if (itemDO != null && MapUtils.isNotEmpty(itemDO.getFeatures()) && itemDO.getFeatures().containsKey(ITEM_PC_DESCRIPTION_PUSH)) {
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
} else {
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_WL_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_WL_PUSH, "" + content.hashCode());
}

比如這一段代碼就把判斷里的業(yè)務(wù)邏輯隱藏了起來，這段代碼其實的業(yè)務(wù)邏輯是這樣， 判斷商品是否有PC裝修內(nèi)容。如果有做一些操作， 如果沒有做一些操作，將hasPCContent 這個邏輯表現(xiàn)出來， 一眼就能看出來大概的業(yè)務(wù)邏輯，讓業(yè)務(wù)邏輯顯現(xiàn)化，能讓代碼更清晰?？梢愿膶懗蛇@樣：

boolean hasPCContent = itemDO != null && MapUtils.isNotEmpty(itemDO.getFeatures()) && itemDO.getFeatures().containsKey(ITEM_PC_DESCRIPTION_PUSH);
if (hasPCContent) {
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
} else {
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_PC_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_WL_TEMPLATEID, "" + templateId);
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_PC_PUSH, "" + pcContent.hashCode());
   itemUpdateBO.getFeatures().put(ItemTemplateConstant.FEATURE_TSP_SELL_WL_PUSH, "" + content.hashCode());
}

2.簡單設(shè)計原則——《Clean Code》

（1）保持系統(tǒng)最大可測試

只要系統(tǒng)可測試并且越豐富的單元測試越會導(dǎo)向保持類短小且目的單一的設(shè)計方案，遵循單一職責(zé)的類，測試起來比較簡單。

遵循有關(guān)編寫測試并持續(xù)運(yùn)行測試的簡單、明確規(guī)則，系統(tǒng)就會更貼近OO低偶爾度，高內(nèi)聚度的目標(biāo)。編寫測試越多，就越會遵循DIP之類的規(guī)則，編寫最大可測試可改進(jìn)并走向更好的系統(tǒng)設(shè)計。

（2）避免重復(fù)

重復(fù)是擁有良好設(shè)計系統(tǒng)的大敵。它代表著額外的工作、額外的風(fēng)險和額外且不必要的復(fù)雜度。除了雷同的代碼，功能類似的方法也可以進(jìn)行包裝減少重復(fù)，“小規(guī)模復(fù)用”可大量降低系統(tǒng)復(fù)雜性。要想實現(xiàn)大規(guī)模復(fù)用，必須理解如何實現(xiàn)小規(guī)模復(fù)用。

共性的抽取也會使代碼更好的符合單一職責(zé)原則。

（3）更清晰的表達(dá)開發(fā)者的意圖

軟件項目的主要成本在于長期維護(hù)，當(dāng)系統(tǒng)變得越來越復(fù)雜，開發(fā)者就需要越來越多的時間來理解他，而且也極有可能誤解。

所以作者需要將代碼寫的更清晰：選用好名稱、保持函數(shù)和類的短小、采用標(biāo)準(zhǔn)命名法、標(biāo)準(zhǔn)的設(shè)計模式名，編寫良好的單元測試。用心是最珍貴的資源。清晰：選用好名稱、保持函數(shù)和類的短小、采用標(biāo)準(zhǔn)命名法、標(biāo)準(zhǔn)的設(shè)計模式名，編寫良好的單元測試。用心是最珍貴的資源。

（4）盡可能減少類和方法

如果過度使用以上原則，為了保持類的函數(shù)短小，我們可能會造出太多細(xì)小的類和方法。所以這條規(guī)則也主張函數(shù)和類的數(shù)量要少。

如應(yīng)當(dāng)為每個類創(chuàng)建接口、字段和行為必須切分到數(shù)據(jù)類和行為類中。應(yīng)該抵制這類教條，采用更實用的手段。目標(biāo)是在保持函數(shù)和類短小的同時，保持系統(tǒng)的短小精悍。不過這是優(yōu)先級最低的一條。更重要的是測試，消除重復(fù)和清晰表達(dá)。

五、最后

總而言之，做業(yè)務(wù)開發(fā)其實一點也不簡單，面對不確定性的問題域，復(fù)雜的業(yè)務(wù)變化，

如何更好的理解和抽象業(yè)務(wù)，如何更優(yōu)雅的應(yīng)對復(fù)雜性，一直都是軟件開發(fā)的一個難題。

在對抗軟件熵增，尋找對抗軟件復(fù)雜性，符合業(yè)務(wù)的構(gòu)造定律的演進(jìn)方式，我們一直都在路上。

參考

[1] 《Domain-Driven Design》 ：https://book.douban.com/subject/1629512/

[2] 《Implementing Domain-Driven Design》 ：https://book.douban.com/subject/25844633/

[3] 《Clean Code》：https://book.douban.com/subject/4199741/

[4] 《A Philosophy of Software Design》 ：https://book.douban.com/subject/30218046/


當(dāng)前標(biāo)題：我們一起聊聊如何從容應(yīng)對復(fù)雜性
標(biāo)題鏈接：http://www.5511xx.com/article/dhjpsop.html