程式設計師生產力提升之路－Step1：需求分析

程式設計師生產力提升之路。

9:00 AM，你的老闆突然衝進辦公室，說：「市場希望我們的網站能夠做一個新的花式登入框。只需要提供使用者名稱和密碼欄位成不？也許加上恢復連結也成。 ，你可以保持冷靜了：因為你學會PHP瞭如何解構。

什麼是解構？

解構就是將需求分解成盡可能小的片段，然後對這些片段予以整理和闡述，最後成為你（程式設計師）和你老闆/客戶之間的共識。

如果有人給你的是現成的規範，也沒關係。一切始於解構！

我已經在編碼了，為什麼還要解構呢？

是的，也許你已經在使用AngularJS搗鼓如何ng-submit()你的登陸表單了，並且感覺比按部就班地先進行Struts 1要容易得多了。哦，no，趕緊懸崖勒馬吧！

我們首先要做的是對需求做穩健性的檢查。分解。 「我希望用戶能夠透過框來登入」並不是一個正確的需求。

聽起來特別easy，有木頭有？我的意思是，你可以在短短的幾分鐘的時間內搞定，是不是？好吧，讓我們繼續往下看…

有沒有一些關於現實生活中的實例呢？

這還真有，從我的經驗來看，這個真實的例子就發生於2011年2月，德國的一家汽車製造商對於他們新網站的需求。

請看下面這張圖片的左下角。請注意看那個登入框。看起來多麼小巧簡單啊，但其實是非常複雜。讓我們來看看為什麼…

首先，關於如何解構？

你應該和技術驅動和業務驅動人員一起攜手。所以需要說服老闆獲得更多的INPUT！

哦，對了，如果必要的話，可以加人。不過，根據我以往的經驗來看，整個團隊來做解構工作將會大大浪費時間、金錢和精力——但這是另一個話題了。

接下來，打開你喜歡的書寫工具，可以開始問一些「幼稚」的問題了。然後將答案一一記下來整理。這些「幼稚」問題是什麼呢？ —— “那是什麼？”，“是什麼造成這樣的後果？”,“為什麼我們需要它？”,“還有沒有其他部分？”。

至於要問多久？要嘛問完問題，要嘛其他人嫌棄你了

關於實例？

繼續回來說上面的範例：「我們需要一個登入框」。首先進行分解： [1]我們需要[2]登入[3]框。假設[1]在那個時候已經給出，那麼可以從[2]開始。

關於[登入]部分的問題

你：「登入是什麼？」

商務人員：「嗯，使用者名稱和密碼應該就足夠登陸了。」

你：「使用者名稱亦或是電子郵件？」

商務人員：「都可以！」

你：「等一下，誰是我們的用戶呢？ 」

商務人員：「這麼笨。 >

商務人員：「嗯，是的。不過，高層管理人員這麼提過，如果是那些已經買了寶馬車的用戶，就可以透過客戶編號登入網站，並自動取得訪客帳號。」

你：「呃，那我們怎麼取得這些客戶的表單呢？」

商務人員：「從CRM系統。平行於我們自己新建的用戶資料庫。哦，順便說一句，有幾種不同的CRM系統，所以需要說明原因。不可用的時候怎麼辦？什麼是自動訪客帳號？他們怎麼知道他們突然就能登入？ ……救命！

=>繼續問問題

先暫停會，來看看[框] 部分

你：「框是什麼？」

商務人員：「差不多都已經設計好了。使用者名稱/密碼字段，登入按鈕。還有什麼難的呢？」

你：「框只要顯示在首頁上嗎？」

商務人員：「不是的，我們要在若干網頁上顯示，如有些活動頁面。所以在你的CMS系統中應該將它做成一個元件。」

你：「元件？啊哈。 呃，你知道HTTP/HTTPS的差別嗎？ ……是不是我們一定要確保使用者安全地傳輸資料呢。可以禁止使用者。 他們需要接受新的“條款和條件”，才可以登入相應的層。和條件？我們才剛開始！

還有很多很多的內容是沒有覆蓋到。比如說，基礎設施，SSL-Loadbalancers，忘記密碼的工作流程，錯誤訊息/資訊訊息，等等等等。以及究竟是誰說「我們需要登入框」的？客戶？那麼，誰才是真正的客戶呢？

關於HTTP/HTTPS的問題，在製定需求之前，技術和商務人員得先坐在一起討論。如果沒有雙向交流，那麼你就真的只能在夢裡實現了。

最後但並非是最不重要的，關於這個例子，我們甚至還沒有完全解構——相反，這還只是冰山一角而已。

森林森林森林，沒有樹哪來的森林？

在問了一系列的問題之後，我們首先需要整理闡述這些問題。在沒有整理闡述之前，你不能規劃，亦無法估算，否則，差之毫釐，謬以千里。

自然，在沒有完成這些步驟之前，先去敲程式碼肯定是不正確的。先好好提煉這些問題吧，就像淘金一樣，去偽存真。

下一步：是的，離完成任務還遠得很遠。這還只是解構的開始。

在以後的文章裡，我會繼續寫解構以及後面的步驟，敬請期待。如有不同意見，也歡迎指正。

免費領取LAMP兄弟連原創php教學光碟/《細說PHP》精要版，詳情諮詢官網客服：http://www.lampbrother.net