本篇文章關注於程式設計實踐中的相關流程設計內容，內容**自己過去的工作總結。
越複雜流程，越容易出錯。為了減少出錯的情況，需要提取並且封裝通用邏輯，用乙個易於理解的名字來對外提供服務。在業務不同抽象層級上，幹各自職責對應的事情。
前後臺互動的流程越多，需要維護的狀態就越多，出現問題的概率就越大，因此在不影響主要功能的前提下，流程能簡化就盡量簡化，那些被簡化的路徑，在某些異常場景下，會對業務有一定的影響，具體影響到什麼程式，在上線前，誰也不好說。可通過資料埋點得到上線後的真實資料，以供權衡。
針對複雜業務時，不能一上手就開始寫，要先設計好框架和整體流程。對於一些需求上面沒有明確的互動細節，一般按照通用互動細節來就可以。
對於具體子功能的實現上，需要細緻考慮，較好的實踐方法是逐條列出來，在每種狀態或情況下，什麼樣的輸入得到什麼樣的輸出。
在複雜程式執行過程中，需要維護多個狀態，隨著業務的改變，在處理於狀態關聯的事件時，思維負擔會越來越重重，很容易顧此失彼。
為了更好的控制複雜度，簡化邏輯，需要對狀態進行分級管理，將每個級別的狀態和對應處理分層化。對外統一狀態操作介面，每個模組中，都通過統一狀態介面來管理狀態。
每乙個常量數字，在業務上都要有依據**，要麼是經驗值，要麼是業務規則規定的。
任何失敗重試類操作，都要考慮對後台的影響。因為閘道器只會**請求，大量冗餘的請求會給後台造成巨大壓力，可能會影響正常業務流程。對於失敗重試，一定要設定定時間隔以及重試次數，這裡的失敗要區分型別，如果是業務操作類的失敗，業務層直接提示出錯即可。如果是其他型別的失敗，底層需要做好重試策略，直到重試策略返回失敗，才可認為是失敗，此過程對上層是透明的。
針對開發回發的資料，要進行有效性校驗才能繼續往下走，在有些業務場景中，需要對不同型別的失敗分配不同類的錯誤碼，以便外部處理。比如讀取配置資訊這個功能，可能的出錯就有以下幾種情況：
配置檔案不存在
配置檔案存在，但檔案格式不正確
配置檔案存在，檔案格式正確，屬性key缺失
配置檔案存在，檔案格式正確，屬性key正常，屬性value缺失
配置檔案存在，檔案格式正確，屬性key正常，屬性value是異常值（超大的數，或者是負數）
如果因為上述種種原因，導致讀取配置檔案失敗，那要做好預設配置的處理，根據產品要求，對不同的異常情況，做出對應的處理，使用預設配置繼續執行，還是彈框提示使用者等。
在對後台返回來的格式化資料進行解析時，一定要考慮對應欄位不存在的情況下該如何處理。不管後台返回什麼型別的錯誤資料，都不能崩潰。
仔細分析業務流程，避免不必要的依賴和操作，相關的業務邏輯，要聚合到一起。
分析問題的思路要不斷在實踐中打磨，反思，總結。自己第一時間想到的方案，往往還有很大的優化空間，那麼，從什麼角度去思考優化呢？在開發實踐中，逐漸明確兩個大的方向，在此記錄一下
從底層往上層思考 : 底層是最基礎的資料層，業務流程的資料是不是可以往下移動到底層，然後呼叫底層明確性語義介面函式來實現上層業務，而不是把一堆判斷邏輯都交由業務層去做。
從上層往底層思考 : 在業務層和底層資料之間，要有乙個間接層，對上提供較為高階的功能，對下封裝最底層資料，提供更高層次的介面。
相似的業務處理採用相似的辦法，不要一堆條件，範圍a-c的用這樣的處理方法，業務範圍d-f的用那樣的處理方法，其他型別業務用其他的處理方法。這樣一來，業務和對應的錯誤處理分散在各處，後期維護很容易出錯。
乙個類，如需向其他類獲得相關資訊，不要依賴於類與類之間的繼承組織關係，嘗試通過this來進行強制轉換來獲取，因為這種層級關係在未來可能會發生變動，而這種層級關係的變動，不會通知使用者，因此在實現類似需求時，需要將對外部的依賴關係盡可能的降低，建議採用訊息的方式，每層規定好訊息的職責，一層一層向上傳遞請求，直到某一層給與響應為止。
一致性，指的是對於ui元素和**命名的一致性，同一邏輯元素的命名一致性，它在ui層、中間層、網路層以及後台介面中的核心詞彙要保持一致，這樣增加**的可讀性。
一致性體現在資源管理上，同乙份資源，誰申請，誰就負責釋放。誰增加引用記數，誰就負責減少。
在一些通用功能的設定上，保持**一致性很重要。比如設定控制項字型，原生系統會提供一套介面，自繪部分也會提供一套介面，那麼外部在使用時，就會有疑惑，設定字型是用原生介面還是自繪介面呢？他們會不會相互影響呢？在前期設計時，同一類功能，只提供一套介面較好。
相似操作能夠歸集到一起的，一定要歸集到一起，讓邏輯聚合，而不是到處分散。
比如，你修改了a函式中的a分支，a函式的b分支沒有改動。外部o1模組使用了a函式的b分支，o2模組使用了a函式的a分支，那麼你的本次修改涉及到的影響範圍是哪些呢？o2模組肯定是要測的，o1模組需不需要提測?答案是需要的，從廣義上來看，任何呼叫a函式的模組都要重測一片。即使本次修改沒有涉及到分支，也要去測試。
在嘗試修改後台程式時，要注意與之前系統的相容性。
在修改乙個涉及範圍比較大的問題時，如果涉及的地方太多了，為了最終問題的解決和測試方面的平滑過渡，需要將問題分治，按照功能需求模組來統計彙總，然後，將問題列表按模組分配給各自負責人，由他們去進一步往下分散進行修改，這樣可以保證大型問題的平滑過渡，為開發和測試提供緩衝時間段。
比如本次修改點可分為以下幾個集合，
集合1：涉及到哪些方面
集合2：涉及到哪些方面
集合3：涉及到哪些方面
對於層級呼叫，資源的申請和釋放，要特別注意一致。這一點，特別容易遺漏。
比如說，先壓入快取，再發出請求，那麼，清理快取的時機，應該要覆蓋發出請求後的每一條執行路徑。
7.1 發出請求失敗
7.2 發出請求成功，響應成功
7.3 發出請求成功，響應失敗
一段業務**，正確的路徑只有一條，但錯誤的路徑有很多條，怎麼處理在這個過程中有可能出現的錯誤，就很顯的功力所在了。
如果遇到一些需要特殊處理的地方，優先把大部分情況放在主幹邏輯上，在額外的分支中處理額外。
凡是涉及到網路請求的，如果中途關閉了頁面，一定要注意請求資源的清理操作，這樣在重新開啟頁面，不會收到上一次無效的響應。
沒有profile的優化都是瞎扯淡，一旦開始重構，就要指定好優化目標，所有的相關修改都聚焦在目標上，不能跑偏了。優化前要分析現狀、制定方案和可量化的目標，完成優化後，需要提取相關的資料，總結對比可量化的分析優化成果。後台重構需要配置a/b方案，對於可能會有變化的模組或者業務，或者a、b方案不好取捨的，可採用後台配置採用哪個方案，當重構的版本上線時，先保留舊的模組，如果有問題，可以在後台中配置切回到舊的模組，這種思想同可以同灰度發布一起使用（5w，10w）
在進行元件的重構時，需要遵循最小影響範圍來做，一處重構，盡量只影響到這個業務，不影響到其他業務，保證可控性和可測試性。
對於接手舊專案，裡面用到的第三方庫，如果有新版本的介面庫或者更好的第三方介面庫，該如何抉擇？
當老舊**中有很多相互交纏的邏輯，需要改動多處才能改好詞bug，不好評估改動影響的範圍，這個時候，為了最大限度的相容老舊**，不能繼續在老舊**的基礎上繼續填坑、挖坑，如果選取其中乙個簡單的介面，用清晰簡單的邏輯去實現，然後在逐步替換老舊模組，小步慢跑的改進。
當需要在原有功能上面增加新的功能時，要特別注意一點，就是原有功能所使用的指令和流程不能更改。比如查詢a產品的天數資訊，原有的指令只支援一種產品的查詢，現在其他介面有同時查詢多種產品的情況，而原有指令只實現了查詢單個產品資訊, 那麼，下面有兩種解決方法：
優點 缺點
方法一：修改原有指令，使其支援多條資訊的查詢 增加指令的功能 需修改原有查詢單條產品的頁面，增加了測試成本
方法二：不改動原有指令，新增支援多條資訊查詢指令 不會影響已有功能 類似功能有多處實現，查多條包含查一條的功能
有a、b、c三個賬號，有id1，id2，id3，id4四個功能，每個賬號允許的功能如下：
a--> id1, id3
b--> id2, id3
c--> id4
一種是從上往下，從入口id和各個可操作id段來判斷，優點是直觀，簡單，缺點是對擴充套件性不好，未來要增加新的入口時，需要修改多出
方法一： 從上到下，邏輯簡單直接，可擴充套件性差
bool isallow(account acnt, int nfunid)
}else if (b == acnt)
}else if (c == acnt)
}return false;
}
struct tidinfo
}vectorallidinfo; // 所有功能id集合
bool isallow(account acnt, int nfunid)
}return false;
}
開發小結 團隊管理類
code review 很有必要，在code review時，要按既定的原則與目標進行，不炫技，不挑刺，找出 的缺陷和需求理解不到位的地方，相互學習 設計與思路。要做到對每個人的每次提交都做嚴格的code review機制，這需要乙個強大的制度流程保證和團隊leader的主力推進。否則很難在實際工作...
管理類命令
管理類命令 hostname 顯示主機名稱 uname顯示系統資訊 top 顯示當前系統中耗費資源最多的程序 ps 顯示瞬間的程序狀態 du 顯示指定的檔案 目錄 已使用的磁碟空間的總量 df 顯示檔案系統磁碟空間的使用情況 free 顯示當前記憶體和交換空間的使用情況 ifconfig 顯示網路介...
管理類聯考
管理類聯考 數學 問題求解15題 條件充分性判斷10題，每題3分 共75分 高中 初中 小學數學知識的運用 邏輯推理 30題，每題2分 共60分 形式推理 論證推理 綜合推理 寫作論證有效性分析1題30分 論說文1題35分 共65分 論證有效性分析 較快地找出一段論證中的漏洞 論說文良好的議 寫作能...