1樓：龍騰道默默地
不可或缺地帶著所有環節的視野和閱歷，按以下步驟：
定性需求分析》業務流程設定》路徑及資料結構架構》介面視覺設計》html@js-mvc》css+素材圖。
然後不可避免地重構一遍。
其中前三步是需要含業務素養和設計素養在內的前後端全棧主腦（可由不計其數的分工者溝通模擬）深入使用者生活確定的。
2樓：itlr
有時候好的開發流程就是能幫你快速發現問題的流程，一套邏輯的頭次設計和實現最好的結果也就是試出了很多問題，這是正常的；流程本身不能立竿見影地解決項技術複雜度；光是好工具和選型也不能解決所有的複雜度問題；技術上來說，乙個週期做不完乙個專案，乙個週期只能做在這個週期裡最重要的事情。從這個意義上說，好的流程裡至少應該考慮實現優先順序，允許問題的存在，但把它們規劃到接下來的週期裡。通常起初的幾個週期裡重要的是實現功能，實現好功能；把乙個API的協議設計得無懈可擊，邏輯合理甚至哲學合理往往是以後做更好，因為開始的時候你對問題的理解一定不全面，不經過一段時間的迭代，你很難真正掌握問題域到底有多寬。
乙個不完美但容易改進的設計比乙個立刻就完美的設計更有意義，無論是資料庫，API介面還是前端，更合乎開發實際的留下迭代演進的空間，而不是試圖一步到位。這也是好的開發流程裡必不可少的意識。
市場上的技術選型，流程規約紛繁複雜，但歸根到底，真正決定乙個專案的過程與結果的，是人自己的水平，你能用好任何你能駕馭的技術，也能用爛任何流行但你駕馭不了的技術。個人專案流程的乙個好處就是你擁有決定權，當你有決定權的時候應該考慮「我想怎麼做」，而不是「怎麼做最好」和「通常怎麼做」，如果你駕馭CSS，沒人強迫你用bootstrap，用了也只用5%。
3樓：
需求要考慮好，資料庫、api等設計一定要有規範才能更好的拓展功能，所謂敏捷開發嘛，基本的需求要明朗，系統框架搭好了，剩下的就是砌磚了，然後多次迭代，蹭蹭蹭就是萬丈高樓了~~~~~~
4樓：王賢斌
最核心的還是需求，需求上不存在悖論了，開發過程中碰到問題乙個乙個解決就是，架構上出現問題重構就是。開發過程中本來就會存在各種風險（某個技術實現想的太簡單了，某個流程沒有想清楚出現問題了），這些林林總總的風險，也是分程度的。規避掉大風險，專案都是可以成功的。
這個風險的控制也真的是需要經驗。不管是實踐得來的，還是書上領悟的。
說來說去，還是都要靠經驗——貌似是屁話
5樓：
有沒有寫分析文件不重要，重要的是你是不是真的分析過，用他們產品經理的話來說就是「有沒有想清楚」
所以，你的問題不是流程和技術方案和框架，而是缺少乙個幫你把整個東西想明白的人。
btw：聽上去你是第一次做東西，所以。。。。。建議先別考慮以後擴充套件，先把東西做出來吧
web前端開發工程師需求飽和了嗎？現在去培訓機構參加培訓值嗎？大概多久能找到工作呢？
上邪 對於前端學習報班值不值得這個問題得因人而異，培訓班那麼多，為什麼有些人能夠通過培訓班走向成功，而有些人依舊連找工作都是問題，這樣的差距主要在這兩個方面，一是自身原因，二是選擇培訓班的不同，所以說值不值得還得看自己如何考慮。如果說你選擇乙個不錯的培訓班同時你也很努力的學習，到最後找到乙份蠻不錯的...
怎麼樣從 web 開發人員轉成 DBA ？
今天也要加油鴨 優化頁面響應速度的時候，走歪了，發現是後台速度慢，又深入研究之，發現是oracle查詢速度慢，加了乙個索引後，發現哇塞，學好資料庫對體驗好處多多，遠比多加一些花裡胡哨的頁面給使用者的體驗更好。從此你就開始了dba生涯了。 itlr 把所有能找到的書先都看了 Oracle 看完以後，知...
如何從GIS軟體應用轉向GIS開發？
力敵萬人邢道榮 什麼開發基礎都沒有的，可以按這個順序來自學 C 資料結構 C 地信原理 吳信才老師編的空間資料庫 但是這樣自學有幾個壞處 第一沒有系統性和方向性，學習的內容很散 第二自學期間遇到問題沒有辦法得到及時解答，問題會像滾雪球一樣越積越多 第三時間會拖的非常長，也很耗精力。如果有老師指導就會...