這裡是it修真院產品分享課，今天要分享的是
【關於後台的那些小事】
顧名思義，就是與前台相反的唄，前台我們都知道是使用者檢視資訊，提交資訊的地方，那麼後台相應的就是建立元素資訊，儲存資訊，處理資訊的地方，他也叫管理系統。
打個比方，前台就好像我們去餐廳裡，坐下來看選單，然後告訴服務員我們今天要吃什麼，服務員就蹦蹦跳跳的到了後廚，告訴廚師要做哪些菜，廚師記下桌號和菜品，就開始製作了。這裡的後廚實際上就是我們所說的後台系統，而那個廚師就是後台管理員。
首先最頭疼的問題就是——從**入手？記住一句話，跟隨你的業務流程。找到流程中需要與系統互動的地方，那就是你想要找的東西。
ok，讓我們用乙個簡單的門戶**舉例。
需求：在**上要有新聞模組，首頁需要有輪播圖可以更換公司的大事件，給公司乙個發聲的地方，明年的重點需要擴大招商範圍和規模，**上最好有個招商板塊，再有就是對公司整體有個業務介紹，最後，公司最近招人比較困難，如果官網有個招聘模組也許就能提高招聘的效率。
就是這麼多了，如果是你你會怎麼做？
畫原型嗎？no。先停一下，去把這個「喜訊」告訴所有「干係人」吧，讓大家的資訊對稱一下。面對這個需求，我們需要調動多少人？產品狗自己，ui乙個，前端乙個，後端1-2個，市場文案狗乙個，人力資源輔助配合招聘模組1人，最後是**後期運營者。想想功能，想想要完成的事情，大概就這麼多了。
根據需求可以看出，大概功能並不複雜；做個功能列表，簡單用語言包裝一下你要做的東西，然後去挨個聊或者召集大家開會，讓大家提供乙個完成時間，這個完成時間不能超過deadline，所以溝通過程中可能需要你去說服對方，提高效率，甚至可能加班，讓大家有心理準備。
我們先來做個簡單的梳理
首頁，會有乙個輪播圖方便後期更新，如果更新不頻繁也可以做成靜態，開發成本低。首頁還會是一些公司競爭力介紹等等。
新聞，新聞會有運營人員不定期更新，就是需要建立資訊，他就是需要在後台有這個功能。
招商加盟，看看招商**多半是一些公司介紹，在底部會放乙個****提交的地方，詢問老闆後，他認為也需要這個模組，ok，需要傳遞資訊，他也需要在後台有個功能。
但是這些方案好像聽起來不錯，但是時間允許你這樣做嗎？成本你承受得起嗎？那麼不如用最原始的方式，雖然不那麼酷但是後簡單，前端只提供職位職責預覽，並提供乙個人力的郵箱，大家可以向裡面投遞簡歷，後台只做職位的簡單發布。
業務介紹，屬於靜態頁面，設計上去就ok了，這個不涉及到後台。
經過分析和溝通，我們發現與後台有交集的地方分別是，首頁輪播圖，新聞，招商和招聘。這時候你可以去看看其他產品，在這些模組都會顯示哪些字段資訊，找到你決定有用的，把他填寫到這些功能描述中，再去進行前台的產品設計；不過有時你會發現做著做著發現缺了某個字段，為了避免這種事情的發生，就需要你在資訊收集的過程中，多去看幾個產品，把他們的展示的內容都先羅列下來，再做刪減。
前台不是今天說的重點，我們直接進入後台設計。
我常以為後台就是乙個個的「倉庫」
這個庫里堆放著你想要管理的內容，後台的搭建就是建立乙個又乙個的庫，並且將他們合理的連線起來。回看我們要做的東西，可以簡單的分為四個庫，並對他們分別管理。
知道有哪些庫了，我們需要將他們合理的組合起來，形成」導航「。業務流程越長，功能越多這個組合的工作越不好，這就是為什麼需要資訊架構師這種職位，不過面對簡單的後台，產品們還是可以直接應付。
整個後台的介面通常會有以下模組組成：後台導航——管理庫(管理內容列表\管理的內容)，從最大的框架到最小元素。
新聞管理
輪播圖管理（廣告位管理）
加盟資訊
招聘資訊管理
知道有哪些庫了，我們需要將他們合理的組合起來，形成」導航「。業務流程越長，功能越多這個組合的工作越不好，這就是為什麼需要資訊架構師這種職位，不過面對簡單的後台，產品們還是可以直接應付。
整個後台的介面通常會有以下模組組成：後台導航——管理庫(管理內容列表\管理的內容)，從最大的框架到最小元素。
後台導航
在我接觸的後台導航中常見的有幾種。
1. 橫向導航
2. 縱向樹結構導航
3. 橫向導航縱向樹結構
橫向導航會用在後台功能較少，層級很少的情況下，他的優勢就是學習成本低，劣勢就是可擴充套件性比較差。
縱向樹結構導航，這個我們看的其實是比較常見的，很多電商**的個人中心或是訂單頁面就是用的這種結構，邏輯清晰，能夠很快的找到想要找的東西。
第三種比較複雜，適用於平台功能較多，功能模組相差很多的**，會在最頂部的橫向導航放置頂級功能導航，在某個功能下用樹結構導航清晰的表現二級功能。
因為這一次我們做的功能並不複雜實際上可以用橫向導航，不過因為我是根據現有後台來製作，所以為了不增加開發成本，所以依然延續橫向導航縱向樹結構。
管理庫
決定了哪種導航形式，來看看最重要的「管理庫」，面對「庫」大家記住，絕大部分情況都會有個「列表頁」，然後就是對資訊的「增刪改查」，遇到商品或是輪播圖還會有上下架，顯示與隱藏的功能，基本上「庫」都會這樣的管理的。
ok，其實整個管理列表頁已經躍然紙上了，之後就是正文編輯了，使用者可以從列表頁或導航中的「新增新聞」進入，把可以實現功能的字段做到頁面上，再加上文字編輯器，乙個發布按鈕，乙個簡單的新聞管理就搞定了。
那加盟資訊怎麼做呢？其實也很簡單了，既然使用者需要在前台提交資訊，那麼我們的後台實際上就是乙個接受資訊的地方。我們讓使用者在前台提交「姓名**郵箱」等****，在後台加盟管理中，利用列表頁將這些資訊進行展示，有新的加盟資訊推送過來可以在導航上加乙個數字角標，這個功能甚至都用不到詳情頁就能搞定。
像門戶**這種還算比較簡單的了，不過為了方便管理，你可以給不同的角色賦予不同的許可權，比如人力資源的同學只可以使用招聘發布，**運營人員只能使用新聞發布等等，專人專項，分工明確。
一句話，跟隨你的產品業務。比如拿電商而言乙個商品從使用者確認下單，支付之後，在後台會走過多少流程，我想每個公司的業務流程都會不同，但是在這個流程中一定會涉及到很多「角色」來處理訂單，而這「角色」就是你來劃分後台許可權的依據，而功能亦是從業務需求中轉化而成的。
讓我們短暫回顧一下
回顧一下後台的設計，我們會發現他實際上是一種面向資訊的設計，對於資訊進行審核，記錄，閱讀，操控等等。在做後台設計時你需要對業務流程有一定了解，知道哪個環節會與系統產生互動，那麼這個互動的點就是後台設計的「庫」，我們需要對這些庫進行管理，有時候我們還需要將這些庫與另外一些庫進行連線，庫與庫之間互相調取資料。
比如電商**做的**管理，都會去呼叫「商品庫」裡面的資料。想要掌握後台產品的設計的核心就是處理好每個庫的劃分與整個產品的運作邏輯。
先做前台還是後台
這是我曾經很糾結的問題，不知道你是不是也是一樣，當你慢慢了解之後，這個問題其實就不復存在了，找你熟悉的東西開始做，這樣會讓你有我已經完成了多少多少了的感覺，而不是面對乙個不熟悉的東西，痛苦的死磕，磕到對自己失去信心。
前台與後台共同構成了你的產品，缺少一方，產品便無法運轉，先把業務邏輯思考清楚，你會發現「哦，這裡是給使用者看的」「啊，這裡是後台要處理的」當業務邏輯走向完整之後，我想你的前後臺就都已經設計完成了。
關於後台的那些小事
這裡是it修真院產品分享課，今天要分享的是 關於後台的那些小事 顧名思義，就是與前台相反的唄，前台我們都知道是使用者檢視資訊，提交資訊的地方，那麼後台相應的就是建立元素資訊，儲存資訊，處理資訊的地方，他也叫管理系統。打個比方，前台就好像我們去餐廳裡，坐下來看選單，然後告訴服務員我們今天要吃什麼，服務...
HTTP那些小事
這是一篇資訊整理文章，可以當作工具來看 http全稱是超文字傳輸協議，構建於tcp之上，屬於應用層協議。請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊被稱為中間人攻擊 man in the middle attack，mitm https是在通訊介面部分用 tls transport layer...
const的那些小事
關於const 為什麼需要const?請看以下語句 for int index 0 index 512 index 在此語句中有兩個問題 1 512這個常量含義不明確，也並不清楚index與512比較有什麼作用 2 假如在程式中多次使用到512這個常量時，在後來的工作需要把512改為111的話修改的...