關于軟件工程，我一直有一些零散的想法，正好@技術人攻略 這期聊這個話題，于是順手寫了這篇「散」文。

關于延期

2004年，我大學畢業到新浪時，正好參與了一個大型的互聯網項目——新浪教育頻道見習就業項目。進度是由項目經理控制的，光是需求分析報告疊起來有一個iPhone側面高。過程還算正規，有ER圖，有數據結構表，還有界面示意圖。從項目開始我們就天天加班到晚上四五點，回去睡個覺，早上9點回來接著干。還記得我和偉平半夜3點出去買煙，回來看見前端的妹子一邊哭一邊嵌頁面。***項目還是延期了蠻久。

出于對加班的恐懼，那時候我就對軟件工程產生了興趣，然后讀了大量關于軟件工程的書，統一過程、敏捷開發、極限編程以及***期限、人月神話這些周邊。我試圖弄懂，為什么需求和開發之間，會有如此之大的鴻溝，以至于它能成為一門獨立學科。

這個思索持續了多年，我一直沒有找到合適的答案，直到2009年我回到新浪，擔任新浪云計算產品經理。

SinaAppEngine項目8月立項，11月上線***個版本，整體進度延遲3天（這就是為什么它是11月3日上線的），當時我們就五六個人。我在新浪云負責的***一個大項目——新浪云商店***期上線，沒有進度延遲。

這讓我發現，延期最核心的問題其實并不在于過程，而在于需求。作為一個曾經開發過億訪問量系統的產品經理，我可以異常精準的控制需求和進度。我們在需求分解時，可以在技術實現級別討論時間表。最終我們的時間表可以精準在小時級別，誤差在天。這招屢試不爽，從快簡歷到JobDeer.com，我們的進度延期都最多幾天。

關于質量

再來說質量的控制。

如何提升軟質量

程序員有一個習慣，就是把自己的高標準拿去要求別的人。所以我們會發明各種高效但是一點都不易用的框架，覺得——如果連這個都不明白，還當什么程序員。

我一直都是這么想的，但當我08年自己開工作室的時候，我發現我沒法招到技術特別好的人，我們新招的同學甚至搞不明白面向對象。

于是后來我寫了LazyPHP框架，這是一個用面向過程封裝面向對象的框架。整個框架20個函數，搞定一切。它只有一個目標，讓不懂面向對象的人，也可以寫出強壯的Web程序。大體來說，它做到了。

再說一件事情。在設計SAE的時候，我們有一個最常討論的話題，就是如何讓那些寫出不良代碼的程序員進行自我修正。后來我們采用了云豆和配額兩個方式來進行軟性限制。現在SAE上訪問量特別大的應用都優化得特別好。

如何提升硬質量

我從來不相信軟件是什么藝術，藝術從來不會Done is better than perfect。所以有些核心的質量指標是必須的，比如單元測試，比如編碼規則，比如常規安全檢查。而這些東西，不應該作為圣經天天念，而應該簡單粗暴的做到代碼發布系統里邊，不遵守就提交不了的代碼。

關于軟件工程

坦白的說，我覺得「軟件工程」這個名字過時了，那是軟件時代的遺物，在互聯網時代是很詭異的。軟件不再是被定義好的大規模工程，分發到外包公司去做實現。它是產品不可分割的一部分，是受需求影響***最慘的部分。

需求分析，原來是軟件工程的起點，現在已經由專門的產品團隊來做了，這個決定創業公司生死存亡的東西，居然以前是程序員在做。user story，在沒有用戶畫像、應用場景時也很容易失之千里。

我們需要一個新的，產品整體的工程化，以天為周期進行全產品流程迭代的過程。而我在這個方向找到的最接近的理論，是《精益創業》。它是精益開發在產品全流程的實現方法論。

我覺得，未來「產品工程」會替代「軟件工程」。

大型互聯網公司的技術團隊會分成兩類人，一類做私有云平臺——提供通用技術能力（這部分前期可以用公有云），一類直接合并到業務團隊做實現。

超大型項目，會被API分割成平臺和應用，通過強隔離的方式有序生長；而以往那些依賴關系，也會在這個層面得到很好的解決。

大部分人不用關心系統，只需要關心自己的應用。

軟件工程本身，則浴火重生，從一個面向過程式的管理，變成一個面向對象式的支撐環境（有點像對象容器）。

具體的東西，我沒想太好，我就隨便寫寫，您就順便看看。