作一個有產品思惟的研發：課程架構

天天10分鐘，解決一個研發問題。

若是你想了解我在作什麼，請看《作一個有產品思惟的研發：課程大綱》傳送門：http://www.javashuo.com/article/p-cayviilq-hn.html

 

1、是什麼殺死了咱們的初創項目

1. 將軍難打無兵之仗
案例：小A曾在多家一線互聯網公司呆過，技術上也有很多積累。16年，他加入了一家創業公司，老闆很是常識他的才化，讓他帶幾我的作數據分析爲公司的運營提供決策依據，於時小A按照一線互聯網標準作了一套方案，方案中包括：一套數據倉庫、一套算法建模工具、一套數據可視化系統等，預算大概在100萬左右。他把方案發給了老闆，當老闆看了他的方案之後，一口鮮血噴在電腦屏幕上——遂卒！
總結：沒那麼多人，卻想幹那麼多活。若是你招人、招人、招人，那麼死法就是另外一個：過早的擴大規模。

 

2. 羅馬不是一天建成的
案例：小B在技術圈裏混跡多年，閱博客無數，對各類技術說來頭頭是道。小B所在公司因爲業務發展，須要對原有系統進行優化、改造。因而，老闆找到見多識廣的小B，讓他出一套解決方案。小B發揮他的畢生所學，終於在三每天夜的奮戰後給出了他的方案：新方案能夠日處理MQ十億條以上，日處理訂單100萬單以上，採用組件化、微服務、分步式架構。小B滿意得將他的做品發給了老闆，老闆滿意得點了點頭，說道：「方案不錯，你去落地吧！」，因而小B連夜逃回了老家。
總結：沒有積累那麼多「資源」，卻想一步登天（細節請看《億級流量網站架構核心技術》）。

 

3. 冰山下面纔是關鍵
案例：小C是一家小企業的技術骨幹，經手開發了許多業務系統，最近幹得挺鬧心的，準備辭職了，緣由是：他新來的Leader老是Diss他，說他作的系統爲何跟BAT的差那麼多？爲何沒這個功能？爲何實現不了那個？
總結：優秀的解決方案都是被業務「逼」出來的！說人話就是，「業務」發展到必定階段，量變致使了質變，出現了新的問題，已有的方式已經不能應對這些問題，須要用一種新的方案來解決，經過創新和嘗試，纔有了業界領先的方案（細節請看《淘寶技術這十年》）。沒有那麼卓越的業務場景，卻幻想靈光一閃成爲天才。

 

4. 人心不足蛇吞象
還有一個殺死初創項目的錯誤源於產品，而非工程。「經驗豐富」的產品經理，他們的產品路線圖一般會超出團隊的能力。這種樂觀情緒致使了過多的招聘、過多的開發，最終精疲力盡。在管理層看來，這彷佛是由於「工程師表現不佳」，但其實是由於管理層沒有設定好清晰的願景。

 

2、架構設計中的原則
1. 單一職責原則：簡單的來講，一個模塊只實現一個功能，哪怕這個模塊只有兩行代碼，這樣能夠保證各大個模塊你們分工協做，互不影響，各作各的事情。
4. 最少知識原則：說人話就是：低耦合，高內聚。
2. 無環依賴原則：當 A 模塊依賴於 B 模塊，B 模塊依賴於 C 模塊，C 依賴於 A 模塊，致使的結果就是：循環依賴。
4. 共同重用原則：不要讓重複的代碼處處都是，要讓它們足夠的重用，因此要儘量地封裝。
5. 好萊塢原則    ：咱們不須要在代碼中主動的建立對象，而是由容器幫咱們來建立並管理這些對象，比較有名的就是「控制反轉」（或稱爲「依賴注入」）。
6. 大道至簡原則：界面簡潔，功能實用，操做方便，要讓它足夠的簡單，換言之就是你得保證你的系統馬雲也會用。

只記住這簡單的6條原則就夠了，說多了一個也記不住也沒啥用！

 

3、課程的總體架構

下面的框架結構畫得比較簡單，目的只是讓瀏覽者更直觀的瞭解總體架構。事實上，一個研發生態遠遠不止於這麼簡單！比你想象的還要複雜。

 

 

今日總結：

理想很豐滿，現實很骨感。那咱們面對一個項目具體應該怎麼辦？這裏我給三點建議：

一、「作多少飯，架多大的鍋」： 若是你的項目只服務於幾百個用戶，那麼緩存能夠不要；若是服務幾千個用戶，那麼先後臺分離能夠不要；若是服務於幾萬個用戶，那麼中間件也不用上用場。

二、最小產品上線，根據使用反饋不斷優化、迭代開發。

三、好的系統是業務不斷逼出來的，不要一開始就設計面面俱到的系統，不然頗有可能你在是浪費時間。