最佳實踐：應用程序設計的順序

Question

編寫Web應用程序時，我可以想到需要創建的相當多的組件。我知道它應該可以逐步完成，但是我想看看你通常會處理這些任務的順序。佈置你通常的事件順序和一些理由。

幾個可能的組件或部分我已經想到了：

• 故事（即pivotaltracker.com）
• 集成測試（Rspec的，黃瓜，...）
• 功能測試
• 單元測試
• 控制器
• 查看
• JavaScript功能
• ...

的問題是，你做的一切零碎？（一個故事，一個集成測試，讓它通過，移到下一個，...）或者先完成一個組件的所有，然後移到下一個組件。

Answer 1

我是BDDer，所以我傾向於在外面進行。在高層次上，這意味着首先建立項目願景（你會驚訝於很少有公司實際做到這一點），識別其他利益相關者及其目標（法律，架構等），然後將事情分解成功能集，功能和故事。故事是我們可以獲得反饋的最小可用代碼片段，它可能與一個或多個場景相關聯。這就是Chris Matts所說的「特徵注入」 - 創建特徵，因爲它們需要支持利益相關者目標和項目願景。 I wrote an article about this a while back.我證明了這一點，因爲無論你的代碼有多好或是多好的測試，如果首先是錯誤的代碼，這並不重要。

一旦我們有了故事和場景，我傾向於首先編寫UI，然後是支持它的類。 I wrote a blog post about a real-life example here - 我們用Java編程，所以你可能不得不用Rails做一些不同的事情，但是原則依然存在。當有實際的行爲需要描述時，我傾向於開始編寫單元測試 - 也就是說，一個類的行爲有所不同，取決於它的上下文，以及之前已經發生的事情。通常情況下，第一類確實是控制器，我傾向於使用靜態數據來構建UI。我會寫第一個單元測試來幫助我擺脫那些靜態數據。

首先進行用戶界面讓我可以儘早獲得利益相關者的反饋，因爲它是用戶將與之交互的用戶界面。然後，我開始「幸福的路徑」 - 讓用戶做最有價值的事情 - 接着是特殊情況，驗證等。

然後我盡我所能說服我的PM讓我們釋放我們的代碼提前，因爲只有當用戶真正掌握了它才能玩，你才能發現你真的做錯了什麼。