簡潔至上——探索產(chǎn)品與技術(shù)的優(yōu)雅原則

背景

上周開發(fā)了一個需求，發(fā)現(xiàn)一個歷史功能，從產(chǎn)品和技術(shù)代碼的角度看，將簡單的事情變得復(fù)雜。這一經(jīng)歷再次深化了我對一個核心理念的認(rèn)識：簡化復(fù)雜性是產(chǎn)品設(shè)計和軟件開發(fā)中永恒的挑戰(zhàn)。我們必須不斷努力，將復(fù)雜的邏輯轉(zhuǎn)化為直觀、易用的用戶功能，并將冗長、難以維護的代碼結(jié)構(gòu)變?yōu)楹啙?、效率高的形式?/p>

在《人月神話》中作者提到，軟件開發(fā)的復(fù)雜度可以劃分為本質(zhì)復(fù)雜度和偶然復(fù)雜度。本質(zhì)復(fù)雜度它是一個客觀的東西，跟你用的工具、經(jīng)驗或解決渠道都沒有任何關(guān)系。而偶然復(fù)雜度是因為我們在處理任務(wù)的時候選錯了方向，或者使用了錯誤的方法。

作為工程師，我們的追求不僅僅局限于代碼的編寫。更深層次的，我們探索的是如何對抗軟件本身產(chǎn)生的復(fù)雜度，如何將繁雜的需求轉(zhuǎn)化為簡潔、優(yōu)雅的解決方案。

不單單是程序員，任何化繁為簡的能力才是一個人功力深厚的體現(xiàn)，沒有之一。越簡單，越接近本質(zhì)。這個“簡單”指的是整體的簡單，而不是通過局部的復(fù)雜讓另一個局部簡單。

附：需求案例復(fù)雜點 1）業(yè)務(wù)產(chǎn)品設(shè)計方面：Promise 業(yè)務(wù)類型(比如生鮮時效、航空時效、普通中小件時效等）與單據(jù)類型、作業(yè)類型之間存在一系列復(fù)雜的轉(zhuǎn)換關(guān)系。但這幾個類型本質(zhì)是一樣的，沒必要轉(zhuǎn)換，術(shù)語統(tǒng)一，對業(yè)務(wù)使用來說也簡單。 2）技術(shù)代碼方面（組內(nèi)同學(xué)CodeReview發(fā)現(xiàn)的）：代碼方法“副作用”（side effect），即方法除了返回值之外，還通過修改某些外部狀態(tài)或?qū)ο髞韨鬟f信息。比如filterBusinessType方法的主要作用是返回一個int類型的值，但它也修改了入?yún)⒌膔esponse對象作為一個副作用，外部鏈路會使用reponse對象屬性值。并且代碼內(nèi)部調(diào)用鏈路復(fù)雜，對于新人來說成本較高。為了確保清晰理解這些關(guān)系，并有效地進行代碼維護，特意對這些關(guān)系及代碼鏈路進行了詳細的梳理。

一、為什么要簡單？

為什么我們要追求簡單性？不應(yīng)該是復(fù)雜，才能顯得技術(shù)牛嗎？

對應(yīng)簡單，各有個的說法，個人理解如下：所見即所得

1.比如你架構(gòu)圖別人一看就明白這是干什么的，系統(tǒng)之間如何交互，模板之間如何交互。

2.比如定義API 別人一看文檔就明白功能職責(zé)，請求入?yún)?，出參含義，有基本的計算機知識人都能看明白，這叫所見即所得。

3.比如新人在1周左右就能快速更改代碼，而不是要記住代碼各種注意事項,盡可能減少用戶的學(xué)習(xí)曲線和理解成本

接下來從本次需求的復(fù)雜案例著手，引入自己的一些思考

二、案例詳細

1）產(chǎn)品設(shè)計

1.1）現(xiàn)狀

Promise業(yè)務(wù)類型 > 單據(jù)類型 > 作業(yè)類型 各種轉(zhuǎn)換關(guān)系

1.業(yè)務(wù)類型 轉(zhuǎn)換單據(jù)類型（1 VS 1)

2.單據(jù)類型 轉(zhuǎn)換為 作業(yè)類型：根據(jù)單據(jù)類型找到 倉、干支線、本地 作業(yè)類型

3.倉&干支線&本地 作業(yè)類型：

1.2）思考點

1.一對一映射的簡化

“業(yè)務(wù)類型&單據(jù)類型 其實是1V1映射”，這表明系統(tǒng)當(dāng)初設(shè)計時考慮了業(yè)務(wù)類型和單據(jù)類型之間的直接關(guān)聯(lián)。如果這種一對一的關(guān)系確實存在，那么單據(jù)類型可能是一個冗余的概念，因為每個業(yè)務(wù)類型已經(jīng)隱含了單據(jù)類型的信息。簡化模型，去除冗余的單據(jù)類型，可以減少系統(tǒng)的復(fù)雜性，并可能簡化數(shù)據(jù)庫設(shè)計和代碼實現(xiàn)。

1.概念統(tǒng)一

“作業(yè)類型本質(zhì)還是業(yè)務(wù)類型”，這意味著在不同的上下文中可能使用了不同的術(shù)語來描述相同的概念。在編碼和產(chǎn)品設(shè)計中，使用統(tǒng)一的術(shù)語可以減少混淆，提高團隊成員之間的溝通效率，并使得新成員更容易理解系統(tǒng)。

1.維度劃分

將業(yè)務(wù)類型進一步細分為“倉、干支線、本地維度”，這表明系統(tǒng)有不同的操作維度或者分類標(biāo)準(zhǔn)。這種維度劃分有助于在不同層面上組織和處理業(yè)務(wù)邏輯。

2）代碼問題

2.1）內(nèi)部鏈路太長

業(yè)務(wù)類型邏輯入口之一：getBusinessTypeInfoForAll > getBusinessTypeInfo > getOrderCategoryNew > obtainOrderCategoryByCode > filterBusinessType

??

在我們的代碼庫中，上面關(guān)鍵的五個方法被多個調(diào)用入口所使用，這種情況使得管理這些入口變得極為棘手。由于調(diào)用點的廣泛分布，理解代碼的影響范圍變得復(fù)雜，難以一目了然地掌握。此外，這種做法也顯露出我們的代碼缺乏清晰的分層架構(gòu)。這一原則的缺失，不僅使得現(xiàn)有代碼難以維護，也給未來的功能擴展和迭代帶來了不必要的復(fù)雜性和風(fēng)險。

2.2）副作用

在Java 編程語言中，術(shù)語“副作用”(side effects) 指的是一個函數(shù)或表達式在計算結(jié)果以外對程序狀態(tài)（如修改全局變量、改變輸入參數(shù)的值、進行I/O 操作等）產(chǎn)生的影響。

?

如下filterBusinessType方法的主要作用是返回一個業(yè)務(wù)類型int類型的值，但它也修改了傳入的response對象的A值作為一個副作用。在外面鏈路使用了A屬性值做邏輯判斷

?

副作用問題：在filterBusinessType方法中如果是在response之前return了數(shù)據(jù)，從方法角度看不出問題，但整個鏈路會出現(xiàn)問題。

?錯誤寫法

public int filterBusinessType( Request request,Response response) {
    if(...){
      return ...
    }
    boolean flag = isXXX(request, response);
}

?正確寫法

public int filterBusinessType( Request request,Response response) {
    /**
     * 切記：return必須在下面這行代碼（isXXX方法）后面，因為外面會使用response.A()來判斷邏輯
     * 你可以理解本filterBusinessType方法會返回業(yè)務(wù)類型，同時如果isXXX方法會修改response.setA(）屬性
    */
    boolean flag = isXXX(request, response);
    if(...){
      return ...
    }
}

2.3）思考點

思考點1：代碼鏈路太長

內(nèi)部代碼鏈路太長是一個常見的維護問題，通常源于缺乏良好的模塊化和抽象設(shè)計。以下是一些思考點：

1.避免過度抽象：雖然抽象可以幫助簡化代碼，但過度抽象反而可能會增加復(fù)雜性。確保你的抽象層次是合理的，并且每個抽象都有明確的目的和價值。

2.分層架構(gòu)：將代碼按照邏輯和職責(zé)分成不同的層次，每一層只對其下一層有依賴性，而不需要知道更深層次的實現(xiàn)細節(jié)。這樣可以減少代碼之間的耦合度，簡化內(nèi)部鏈路。

3.合并重復(fù)代碼：如果發(fā)現(xiàn)多個方法都在執(zhí)行類似的操作，嘗試合并這些重復(fù)的代碼段，創(chuàng)建一個通用的方法來處理它們。這樣可以減少代碼的總量，提高代碼的可讀性和可維護性。

4.團隊共識和標(biāo)準(zhǔn)：與團隊成員討論并達成共識，制定一些編碼標(biāo)準(zhǔn)和最佳實踐，以便在日常開發(fā)中就能夠遵循簡潔性原則，避免產(chǎn)生新的長鏈路。

思考點2：副作用

1）注意事項

1.將副作用明確化：如果一個方法有副作用，應(yīng)該在方法的名稱、文檔或使用方式中明確指出。這樣可以幫助其他開發(fā)者更好地理解該方法的行為。

2.避免使用靜態(tài)變量：靜態(tài)變量可以被多個線程或方法共享，容易引起副作用問題。除非有明確的理由，否則應(yīng)盡量避免使用靜態(tài)變量。

3.完全消除副作用可能是不現(xiàn)實的，尤其是在需要與外部交互的應(yīng)用程序中。關(guān)鍵是要理解副作用的存在，并采取合適的策略來管理和控制它們。

2）Java的設(shè)計約定鼓勵我們遵循以下原則：

1.單一責(zé)任原則：每個方法或類都應(yīng)該有單一的責(zé)任或功能。

2.最小驚奇原則：方法的行為應(yīng)該符合預(yù)期，避免出現(xiàn)意外的副作用。

在這個例子中，filterBusinessType方法既返回一個整數(shù)結(jié)果，又更新了response對象，這違反了單一責(zé)任原則和最小驚奇原則。因為調(diào)用者可能會預(yù)期這個方法只會過濾業(yè)務(wù)類型，而不清楚它還會修改response對象。

3）如何規(guī)避這種現(xiàn)象

為了避免這種情況，可以采用以下幾種策略：

1.分離關(guān)注點: 可以將獲取業(yè)務(wù)類型和響應(yīng)設(shè)置分離成兩個不同的方法。這樣，調(diào)用者就可以清晰地看到每個方法的職責(zé)。

public int filterBusinessType(String logPrefix, Request request) {
    // 過濾邏輯...
    int businessType=...;
    return businessType;
}
public void setResponseData(int filterResult, Response response) {
    // 根據(jù)過濾結(jié)果設(shè)置響應(yīng)數(shù)據(jù)...
    response.setFilteredData(...);
}

1.返回復(fù)合對象（上下文context）: 如果業(yè)務(wù)類型結(jié)果和響應(yīng)數(shù)據(jù)是緊密相關(guān)的，可以考慮創(chuàng)建一個包含這兩個信息的復(fù)合對象，并將其作為方法的返回值。

public FilterResultAndResponse filterBusinessType(Request request) {
    // 過濾邏輯...
    int result=...;
    Response response=new Response();
    response.setFilteredData(...);
    return new FilterResultAndResponse(result, response);
}
class FilterResultAndResponse {
    private int filterResult;
    private Response response;
    
    public FilterResultAndResponse(int filterResult, Response response) {
        this.filterResult = filterResult;
        this.response = response;
    }
    
    // Getters and setters for filterResult and response
}

總的來說，副作用有時候是不可避免的，但我們可以通過以上方法來規(guī)避和管理它們，寫出更可靠、更易于維護的代碼。

三、案例解決方案

回到本文開頭說的產(chǎn)品和技術(shù)復(fù)雜性案例，考慮到產(chǎn)品和技術(shù)影響promise時效內(nèi)核最底層邏輯范圍。我是采取保守的策略：維持現(xiàn)狀不變。這是因為對核心邏輯進行改動會帶來廣泛的影響和較高的風(fēng)險，可能會牽扯到整個系統(tǒng)的穩(wěn)定性和一致性。然而，這并不意味著我們放任復(fù)雜性存在。相反，我做了以下兩點改進措施：

1.增加注釋和注意事項：在代碼中添加詳細的注釋和注意事項，幫助團隊其他開發(fā)者理解這部分代碼的工作原理和潛在風(fēng)險。這樣可以降低新成員上手的難度，并且減少在維護或擴展時出現(xiàn)錯誤的可能性。

2.團隊分享和知識傳遞：我將分享這個案例和相應(yīng)的經(jīng)驗教訓(xùn)，向團隊成員解釋為什么在這個特定情況下我們選擇了保持現(xiàn)狀不變，以及如何在未來的需求、架構(gòu)設(shè)計和代碼編寫中更好地管理復(fù)雜性和副作用。通過這種方式，我們可以共同學(xué)習(xí)和成長，避免在類似情況下重蹈覆轍。

這兩種方法雖然不能立即簡化復(fù)雜性，但它們可以提高代碼的可讀性和可維護性，減少長期的技術(shù)債務(wù)。同時，團隊分享也能促進知識共享和團隊協(xié)作，讓大家知道什么是正確的做法，幫助我們在面對類似挑戰(zhàn)時做出更明智的決策。

四、如何做到簡單--思考點

KISS 原則是指在設(shè)計當(dāng)中應(yīng)當(dāng)注重簡約的原則?？偨Y(jié)工程專業(yè)人員在設(shè)計過程中的經(jīng)驗，大多數(shù)系統(tǒng)的設(shè)計應(yīng)保持簡潔和單純，而不摻入非必要的復(fù)雜性，這樣的系統(tǒng)運作成效會取得最優(yōu)；因此簡單性應(yīng)該是設(shè)計中的關(guān)鍵目標(biāo)，盡量避免不必要的復(fù)雜性。

1）產(chǎn)品設(shè)計

作為技術(shù)從業(yè)者，我們常常需要從用戶（無論是面向C端消費者還是面向企業(yè)內(nèi)部的產(chǎn)品）的視角出發(fā)，來探討產(chǎn)品設(shè)計中的簡潔性原則。以下是我的一些觀點，說的并不一定對，但愿能為您提供一些啟發(fā)。

以用戶為中心

?深入理解用戶需求：深刻洞察用戶的核心需求和痛點，用客觀數(shù)據(jù)驅(qū)動決策，而不是單憑個人直覺。

?簡化用戶旅程：力求打造一個直觀的用戶旅程，盡量減輕用戶的決策壓力和學(xué)習(xí)負擔(dān)。一個優(yōu)秀的界面應(yīng)該是清晰、易懂的，使用戶能夠毫不費力地完成所需任務(wù)。

減法設(shè)計

?在設(shè)計每一個功能環(huán)節(jié)時，我們需要反復(fù)自問：這個功能是否真正必要？如果它的缺失不會損害用戶體驗，那它很可能是多余的。

直觀交互

?設(shè)計時應(yīng)確?？丶筒僮鬟壿嬆軌蜃匀坏赜成淦涔δ?，使用戶能夠直覺地理解產(chǎn)品的使用方法。

持續(xù)迭代

?不斷地收集用戶畫像和分析用戶反饋，將其作為產(chǎn)品設(shè)計迭代的重要依據(jù)，以此不斷地精進和完善產(chǎn)品。

案例： 1、Alfred：這個我覺得根本無需介紹，神器，使用 macOS 的同學(xué)應(yīng)該都知道。一句話來說就是，Alfred 是 macOS 上神級的效率應(yīng)用，能夠在實際操作中大幅提升工作效率。

2、1Password：使用 1Password 生成并管理密碼后，就再也不用費心思去想密碼的事情了，只需要記住 1Password 主密碼就萬事大吉。 原先你需要4步驟：比如1）打開瀏覽器 2）輸入網(wǎng)站（或者打開收藏夾） 3）打開網(wǎng)站輸入用戶名密碼 4）點擊登錄 使用1Password只需要 一步到位，自動打開瀏覽器登錄相關(guān)頁面

2）架構(gòu)設(shè)計

不要跟風(fēng)選擇所謂高大上的技術(shù)，適合的才是最重要的。夠用+1即可。什么意思呢，就是系統(tǒng)目前夠用再往前走一步就可以了。至于這一步是什么？可能需要你在實踐過程中，慢慢找到你認(rèn)為比較合適。很多時候，我們系統(tǒng)架構(gòu)引入一個新框架或者新技術(shù)，它本身帶來的復(fù)雜性其實比你這個問題還要復(fù)雜。

簡化架構(gòu)也是提高技術(shù)穩(wěn)定性的重要步驟。一個復(fù)雜的架構(gòu)可能會導(dǎo)致系統(tǒng)的各個部分難以協(xié)同工作，從而影響系統(tǒng)的穩(wěn)定性。因此，我們應(yīng)該盡量采用簡單的架構(gòu)設(shè)計，使得各個部分可以更容易地協(xié)同工作。

案例：業(yè)務(wù)架構(gòu)簡單化-小件日歷天數(shù)30天擴充到90天 復(fù)雜解法： 1）目前是根據(jù)業(yè)務(wù)的時效配置預(yù)計算好30天日歷，依賴N個配置(倉-干支線-本地緩存等），在現(xiàn)有基礎(chǔ)上，預(yù)計算90天日歷。 2）缺點：牽扯數(shù)據(jù)預(yù)計算N個地方改造，并且增加了數(shù)據(jù)量的存儲。改造排期長并且數(shù)據(jù)存儲成本高 簡單解法： 1）還是保持現(xiàn)有30天日歷的算法。第31天以后的日歷按照最后一天日歷進行復(fù)制。如果日歷計算命中集約地址（比如3天1送），過濾對應(yīng)日歷即可。 2）優(yōu)點：代碼改造工作量小，數(shù)據(jù)存儲成本保持不變

?

案例2：技術(shù)架構(gòu)簡單化-避免過度使用技術(shù)棧 以緩存(本地、分布式緩存）為例，它的引入確實能顯著提高系統(tǒng)的響應(yīng)速度和效率。然而，這同時也帶來了新的挑戰(zhàn)，如數(shù)據(jù)一致性問題和緩存策略的選擇。

??

1）數(shù)據(jù)一致性問題可能導(dǎo)致用戶獲取到舊的或不正確的信息。 2）而緩存策略的選擇則需要在系統(tǒng)資源利用和數(shù)據(jù)時效性之間找到平衡點。 為了解決這些問題，我們可能需要引入更復(fù)雜的緩存失效策略， 1）如基于時間的失效、事件驅(qū)動的失效機制， 這些策略的引入和管理本身就增加了系統(tǒng)的復(fù)雜性，因此在設(shè)計緩存解決方案時，我們需要仔細權(quán)衡其帶來的效率提升和潛在的復(fù)雜性增加，以找到最適合當(dāng)前系統(tǒng)需求的平衡點。

3）最小API

對外 API 的設(shè)計決定了系統(tǒng)的可擴展性和兼容性。一個清晰、簡潔且易于理解的 API 設(shè)計可以減少各種交互問題。編寫一個明確的、最小的API是管理軟件系統(tǒng)簡單性的必要條件，我們向API消費者提供的方法和參數(shù)越少，這些API就越容易理解，就有更多的時間去完善這些方法，

將復(fù)雜的API設(shè)計簡化為更易用、更直觀的形式，以便用戶能夠更容易地理解和使用。

1.使用標(biāo)準(zhǔn)格式：遵循一致的命名約定、數(shù)據(jù)格式和錯誤處理機制。這將使API更加一致和易于使用。

2.API功能單一職責(zé)原則：在API設(shè)計中，單一職責(zé)原則也非常重要。如果一個API具有多個職責(zé)，那么它將變得復(fù)雜且難以維護。因此，建議將API拆分為多個簡單的API，每個API只負責(zé)一個特定的職責(zé)。明確其功能和用途。這將有助于確保API具有清晰的職責(zé)劃分，避免不必要的復(fù)雜性。

3.簡化參數(shù)：盡量避免使用過多的參數(shù)，而是使用簡單、易于理解的參數(shù)。如果必須使用多個參數(shù)，請確保它們之間有明確的關(guān)系。

4.提供簡潔的文檔：編寫簡潔明了的API文檔，解釋每個端點的功能、請求方法、參數(shù)和響應(yīng)格式。確保文檔易于閱讀和理解，以便用戶能夠快速上手。

5.提供示例代碼：為API提供示例代碼，展示如何使用不同的請求方法和參數(shù)。這將幫助用戶更快地掌握API的使用技巧。

在軟件工程上，少即是多，一個很小、很簡單的API通常也是一個對問題深刻理解的標(biāo)志。

案例1：Promise適配M系統(tǒng)API 背景：M系統(tǒng)的時效是自己計算閉環(huán)的，promise是對外統(tǒng)一收口時效，在M系統(tǒng)時效業(yè)務(wù)線上，promise只是透傳，不做任何時效邏輯 復(fù)雜解法： 1）每次M系統(tǒng)相關(guān)時效需求，下游M系統(tǒng)的API需要變更，promise也需要參與改造，改造點2個，第一個是從訂單中間件xml獲取M系統(tǒng)需要的參數(shù)。第二點把獲取的參數(shù)調(diào)用M系統(tǒng)API透傳 2）缺點：需求改造系統(tǒng)多，但都是轉(zhuǎn)發(fā)適配，無核心邏輯，工作量耗時長，項目排期協(xié)調(diào)，溝通成本大 簡單解法： 1）跟M系統(tǒng)溝通，M系統(tǒng)時效要的信息從X節(jié)點獲取，promise把該節(jié)點的json信息全部透傳給M系統(tǒng)，這樣后期需求promise不參與改造， 2）優(yōu)點：從promise角度來說新需求不用改造，從M系統(tǒng)角度來說時效自己閉環(huán)。這是雙贏的局面，從全局來說，減少了鏈路的開發(fā)/聯(lián)調(diào)/溝通/協(xié)調(diào)成本，整個項目交互效率提升了.

案例2：?錯誤碼設(shè)計---未傳播錯誤碼 案例：外單無妥投時間，目前鏈路是A---->B---->C系統(tǒng)。但錯誤碼是各自封裝，沒有把根本原因傳播出去，而是各自加工，導(dǎo)致最終看到的原因跟真實的原因千差萬別。導(dǎo)致整個鏈路牽扯 業(yè)務(wù)方--->A研發(fā)---->B研發(fā)---->C研發(fā)---->C業(yè)務(wù)同事 總共5個環(huán)節(jié)，如下圖：

??

?

案例2：?錯誤碼信息--傳播錯誤碼信息 1、如果API在翻譯錯誤時，需要把底層根本原因返回上去，比如上面案例，把沒有妥投日期的根本原因【XXXXXX】周知 2、改造后鏈路 A業(yè)務(wù)方---->C業(yè)務(wù)同事 總共2個環(huán)節(jié)（改造前5個環(huán)節(jié)），因為界面提示錯誤信息，所見即所得，減少了中間環(huán)節(jié)。提升了業(yè)務(wù)效率，減少了研發(fā)內(nèi)部中間環(huán)節(jié)的排查成本。

??

4）代碼簡單

編碼簡單化也是提高技術(shù)穩(wěn)定性的有效方法。過于復(fù)雜的編碼可能會導(dǎo)致錯誤和漏洞的出現(xiàn)，從而影響系統(tǒng)的穩(wěn)定性。因此，我們應(yīng)該盡量使用簡單、清晰的代碼。此外，我們還應(yīng)該注重代碼的可讀性和可維護性，這樣可以更容易地找到和修復(fù)錯誤。

1.遵循單一職責(zé)原則：每個函數(shù)或類應(yīng)該只負責(zé)一個特定的任務(wù)。這樣可以使代碼更易于理解和維護，并減少錯誤的可能性。

2.避免冗余代碼：盡量避免重復(fù)的代碼。如果需要多次使用相同的代碼塊，請將其封裝為函數(shù)或方法，以便在需要時調(diào)用。

3.使用注釋來解釋復(fù)雜的邏輯：如果代碼中包含復(fù)雜的邏輯或算法，請使用注釋來解釋其工作原理。這可以幫助其他人更好地理解代碼。

4.將長代碼段拆分為多個小段：如果一個代碼段很長，可以考慮將其拆分為多個小段，每個小段只做一件事情。這可以使代碼更加清晰明了，并有助于調(diào)試和維護。

5.使用有意義的變量名和函數(shù)名：變量名和函數(shù)名應(yīng)具有描述性，以便其他人可以快速了解其用途。

總之，編寫簡單的代碼需要考慮多個方面，包括可讀性、可維護性和可重用性等。

五、簡單原則--踐行中

我也是正在積極踐行以下原則。雖然在實踐中仍面臨挑戰(zhàn)，但正不斷學(xué)習(xí)和改進

1）復(fù)雜(重復(fù))的事情簡單(工具)化

當(dāng)我們面對重復(fù)而無差別的任務(wù)時，工具化的價值便凸顯出來。引入合適的工具不僅簡化工作流程，還能大幅提升效率。

對于復(fù)雜的業(yè)務(wù)邏輯，我們應(yīng)致力于深入梳理和理解。詳盡的文檔是理解這些邏輯的鑰匙，它能夠?qū)?fù)雜性降低。

對于系統(tǒng)架構(gòu)，我們應(yīng)該梳理上下游依賴、交互、核心接口、業(yè)務(wù)場景、應(yīng)急預(yù)案等，具備全局視圖

對于技術(shù)密集的代碼，充分的注釋和示例案例是必不可少的，它們是簡化理解過程的橋梁。

我們還應(yīng)該將復(fù)雜的系統(tǒng)解構(gòu)為小型、可管理的模塊，這是一個將復(fù)雜事物簡化的過程。

2）簡單的事情標(biāo)準(zhǔn)化

一旦這些復(fù)雜的系統(tǒng)被拆分成多個簡單的組件，我們就可以對每個組件進行定制化和標(biāo)準(zhǔn)化。

3）標(biāo)準(zhǔn)的事情流程化

這樣的標(biāo)準(zhǔn)化模塊，一旦定制完成，就能夠形成一個簡潔且固定的流程。這種流程化不僅為防止最糟糕情況的發(fā)生提供了保障，也使得任務(wù)能以統(tǒng)一和高效的方式運行。

4）流程的事情自動化

正如自動化測試所示，一旦流程化得以實施，自動化的基礎(chǔ)便已鋪墊?；谶@一基礎(chǔ)，我們可以將復(fù)雜的任務(wù)轉(zhuǎn)化為自動化的操作，從而盡可能地減少手動干預(yù)，實現(xiàn)高效運作。

案例：行云部署發(fā)布上線 簡單提效快 背景：為解決用戶手動部署操作耗時高、分組多人工容易遺漏、對人依賴度高等痛點，2個以上分組，20個容器以上的應(yīng)用，強烈推薦您使用【部署編排】功能，用戶可靈活制定部署策略，實現(xiàn)從編譯構(gòu)建到實例部署的自動化運行，提高部署效率！ 復(fù)雜-->簡單-->標(biāo)準(zhǔn)-->流程-->自動化：部署編排接入了豐富的原子，提供了部署策略、流量管理、編譯構(gòu)建等功能，可基于這些功能進行任務(wù)排布，形成一個獨立的部署編排。部署時，只需執(zhí)行此編排任務(wù)即可，解放雙手實現(xiàn)自動化部署！同時部署編排支持多分組同時部署。

六、總結(jié)

1.復(fù)雜的事情簡單化

2.簡單的事情標(biāo)準(zhǔn)化

3.標(biāo)準(zhǔn)的事情流程化

4.流程的事情自動化

我們先踏出第一步化繁為簡

簡化復(fù)雜性不僅能在短期內(nèi)提高開發(fā)效率和代碼質(zhì)量，也對產(chǎn)品和技術(shù)的長期價值產(chǎn)生深遠影響

1.當(dāng)我們考慮如何簡化一個給定的任務(wù)的每一步時，這不并是在偷懶。相反，我們是在明確實際上要完成的任務(wù)是什么，以及如何更容易做到。

2.我們對某些無意義的新功能說“不”的時候，不是在限制創(chuàng)新，是在保持環(huán)境整潔，以免分心。

3.軟件的簡單性是可靠性的前提條件。這樣我們可以持續(xù)關(guān)注創(chuàng)新，并且可以進行真正的有價值的事、長期的事。

?

本文旨在拋磚引玉，僅就偶然復(fù)雜度的議題，從產(chǎn)品與技術(shù)的角度，分享一些關(guān)于簡單化的個人思考。希望這些初步的觀點能激發(fā)更多精彩的思考和深入的實踐。如果文中有任何不足之處，懇請各位不吝賜教，留言指正。謝謝大家的閱讀和反饋！

審核編輯 黃宇