剛進公司的第一堂培訓——《程序猿的結構化思維》

初級程序猿就是用技術給各種問題進行「分類「？

剛進公司的時候，我們老大對我說了這樣一句話~，作為一個剛從0基礎培訓出來，幾乎沒有什麼開發經驗的你，要會分類~

當時我心想，分類這麼簡單的問題，誰不會啊~在以前學習的時候，我知道要把代碼進行前後端的分類啊~ 那麼問題來了，如果要完全分類的話，分成什麼樣才算分完了呢？ 當然是分到不能再分的時候~ 代碼裡面什麼時候算作不能再分呢？分類的依據是什麼？......

分類之前先要了解的I/O

I/O是什麼？

領導說的就是Input和Output,是一個對於我們做分類的時候一個很重要的依據。

比如說，按照軟體的各個階段來說的話，我們總體流程大致有這些：

設計、實現、需求、交付

那麼怎麼給這幾個過程進行排序呢？

這就要來看看各個過程的I/O了

設計：Input（需求文檔），Output（概要設計/詳細設計）

實現：Input（概要設計/詳細設計），Output（可交付的代碼）

需求：Input（客戶提出的需求），Output（需求文檔）

交付：Input（可交付的代碼），Output（）

通過整理清楚每個階段的I/O，我們就能理清楚這個流程是什麼樣的了~

根據I/O來思考，起碼能讓我們在開發過程中的思維不混亂~

分類/分層的原則

1.層次不混亂（根據I/O）

因為分類的依據不一樣，所以分類的結果也是不同的，但是他們的共同點，就是層次不混亂

比如我們寫一些小型項目的時候，在後端開發的分解中，會把後端代碼按功能進行區分：

如果是按照模塊來進行區分的話~我們又會這樣分：

2.單一職責

因為分層的原則是多種多樣的，但是分到最後的每一個小模塊都是單一職責的，這是因為單一職責的模塊或方法，

他們最後產生的結果是必須要有價值可交換的，也就是說，可以被別人調用，而且輸出的結果是在整個開發過程中有用的。

同時，分解出來的結果，能把上一級覆蓋完全，這樣我們的分層就分解完畢了。

先佔個坑，未完待續~~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！