每天10分鐘，解決一個研發問題。
如果你想了解我在做什麼，請看《做一個有產品思維的研發：課程大綱》傳送門：https://www.cnblogs.com/hunttown/p/10490965.html
一、是什麼殺死了我們的初創專案
1. 將軍難打無兵之仗
案例：小A曾在多家一線網際網路公司呆過，技術上也有不少積累。16年，他加入了一家創業公司，老闆非常常識他的才化，讓他帶幾個人做資料分析為公司的運營提供決策依據，於時小A按照一線網際網路標準做了一套方案，方案中包括：一套資料倉儲、一套演算法建模工具、一套資料視覺化系統等，預算大概在100萬左右。他把方案發給了老闆，當老闆看了他的方案以後，一口鮮血噴在電腦螢幕上——遂卒！
總結：沒那麼多人，卻想幹那麼多活。如果你招人、招人、招人，那麼死法就是另一個：過早的擴大規模。
2. 羅馬不是一天建成的
案例：小B在技術圈裡混跡多年，閱部落格無數，對各種技術說來頭頭是道。小B所在公司由於業務發展，需要對原有系統進行最佳化、改造。於是，老闆找到見多識廣的小B，讓他出一套解決方案。小B發揮他的畢生所學，終於在三天天夜的奮戰後給出了他的方案：新方案可以日處理MQ十億條以上，日處理訂單100萬單以上，採用元件化、微服務、分步式架構。小B滿意得將他的作品發給了老闆，老闆滿意得點了點頭，說道：“方案不錯，你去落地吧！”，於是小B連夜逃回了老家。
總結：沒有積累那麼多“資源”，卻想一步登天（細節請看《億級流量網站架構核心技術》）。
3. 冰山下面才是關鍵
案例：小C是一家小企業的技術骨幹，經手開發了許多業務系統，最近幹得挺鬧心的，準備辭職了，原因是：他新來的Leader總是Diss他，說他做的系統為什麼跟BAT的差那麼多？為什麼沒這個功能？為什麼實現不了那個？
總結：優秀的解決方案都是被業務“逼”出來的！說人話就是，“業務”發展到一定階段，量變導致了質變，出現了新的問題，已有的方式已經不能應對這些問題，需要用一種新的方案來解決，透過創新和嘗試，才有了業界領先的方案（細節請看《淘寶技術這十年》）。沒有那麼卓越的業務場景，卻幻想靈光一閃成為天才。
4. 人心不足蛇吞象
還有一個殺死初創專案的錯誤源於產品，而非工程。“經驗豐富”的產品經理，他們的產品路線圖通常會超出團隊的能力。這種樂觀情緒導致了過多的招聘、過多的開發，最終精疲力盡。在管理層看來，這似乎是因為“工程師表現不佳”，但實際上是因為管理層沒有設定好清晰的願景。
二、架構設計中的原則
1.
單一職責原則：簡單的來說，一個模組只實現一個功能，哪怕這個模組只有兩行程式碼，這樣可以保證各大個模組大家分工協作，互不影響，各做各的事情。
4.
最少知識原則：說人話就是：低耦合，高內聚。
2.
無環依賴原則：當 A 模組依賴於 B 模組，B 模組依賴於 C 模組，C 依賴於 A 模組，導致的結果就是：迴圈依賴。
4.
共同重用原則：不要讓重複的程式碼到處都是，要讓它們足夠的重用，所以要儘可能地封裝。
5.
好萊塢原則 ：我們不需要在程式碼中主動的建立物件，而是由容器幫我們來建立並管理這些物件，比較有名的就是“控制反轉”（或稱為“依賴注入”）。
6.
大道至簡原則：介面簡潔，功能實用，操作方便，要讓它足夠的簡單，換言之就是你得保證你的系統馬雲也會用。
只記住這簡單的6條原則就夠了，說多了一個也記不住也沒啥用！
三、課程的整體架構
下面的框架結構畫得比較簡單，目的只是讓瀏覽者更直觀的瞭解整體架構。事實上，一個研發生態遠遠不止於這麼簡單！比你想象的還要複雜。
今日總結：
理想很豐滿，現實很骨感。那我們面對一個專案具體應該怎麼辦？這裡我給三點建議：
1、“做多少飯，架多大的鍋”： 如果你的專案只服務於幾百個使用者，那麼快取可以不要；如果服務幾千個使用者，那麼前後臺分離可以不要；如果服務於幾萬個使用者，那麼中介軟體也不用上用場。
2、最小產品上線，根據使用反饋不斷最佳化、迭代開發。
3、好的系統是業務不斷逼出來的，不要一開始就設計面面俱到的系統，否則很有可能你在是浪費時間。