1樓：鐵原
先說結論
設計到概要設計為止。詳細設計不是設計，是管理
設計一定是抽象的，設計火車車廂一定不會先調查全國11億人每乙個人的身高體重。一定是概略的，抽象的。
為什麼需要設計？
1，一般上不需要設計，比如CRUD。或者乙個簡單的小功能，直接讓開發人員幹就好了
2，很複雜，很變化的才需要設計。設計是為了降低擴充套件成本和風險，是為了降低初級開發面對這些問題造成的系統複雜性。
架構師應該把這些複雜性遮蔽起來。讓開發去面對簡單的擴充套件。
這些簡單擴充套件就是詳細設計。
這種設計不叫設計，而是管理。 一般上我也不強調開發人員出，除非是第一次合作，不相信他，讓他出幾次就不讓他出了；因為擴充套件的介面已經足夠簡單和安全了
2樓：暗滅
敏捷開發中沒有詳細設計文件。
但我們通常都會增加方案評審環節。
設計方案包括：
介面設計，db設計，架構設計，技術選型，部署設計，關鍵業務邏輯。
同時在story拆解成task的時候，推薦是methon級別的task。
Demo之前會有codereview，三者結合，足夠啦。
3樓：
不實現出來是沒法預見到真正合理的設計是怎麼樣的。搞個poc，把架子搭出來，摸著石頭過河，設計自然就有了。
事先做什麼詳細設計這是計畫經濟的思路，不可取。
4樓：leafspace
問題一（在實際的企業開發裡，詳細設計是在編碼前就完成了嗎？）：
實際的企業裡面，人家已經不用瀑布模型了。為什麼？因為現代主流的網際網路應用都需要不停的變更需求，上課的時候你應該學過的，這對瀑布模型是大忌。所以後面才有了迭代的螺旋模型。
問題二（編碼之前真的能夠做到那麼詳細的設計嗎？）：
理論上是可以的，但也只能做到相對詳細，什麼叫相對詳細，就是說相比剛開始的需求分析階段要詳細得很多，但是對比初期的產品要差一點。因為你詳細設計是一套設計，但是由於編碼過程中你的思維風暴，某些地方你並不會完全按照詳細設計裡面的要求去做，所以初期的成果軟體與詳細設計相比有一定距離。所以這個時候需要重新更新詳細設計的文件，以達到與軟體同步。
問題三（現代的軟體開發流程裡並沒有這個傳統的步驟？）：
5樓：魚公尺糰子
我認為完全的TDD是不太容易實現的。
更多時候需要在開發中逐漸調整成可測試性比較好的體系，諸如抽離公共，做依賴注入等等。一開始就想完全設計幾乎是不可能的。
也就是在這樣的調整中逐漸完善設計。
軟體開發中設計的思想怎麼培養？
已重置 一定要說怎麼培養的話，那就是玩各種建造類的沙盒遊戲。設計的東西越多，設計的腦洞和經驗也就積累得越快。如果簡單總結的話，可以認為問題的本質都是 你手裡有哪些資源？想要的最終產物是什麼？怎樣對這些資源進行組合？然後我們需要給這些問題增加約束條件。資源當然不是無限制的了，各種資源可使用的數量是有限...
在軟體開發中，追求新的技術意義大嗎？
冬瓜不怕冷 新技術是肯定要研究的，現在的企業如果不進行創新，很快就會被淘汰。一般乙個專案在進行，另乙個專案就會調查新技術。包括可行性調查，製作Demo等等。如果新技術可以應用到下乙個專案，那麼這就是領先同類產品的亮點。但是將全部的精力都投入到新技術的開發，這是不可取的。新技術存在不穩定行，很有可能會...
軟體開發中，做產品與做專案有什麼區別？
無缺草 廣義來講，做產品也是做專案，做專案也是做產品。通常來講，在專業人士眼中，做產品 狹義 的層次比做專案 狹義 更高一些。技術要求 研發規範性 企業規模 待遇相對都較高一些。因為廣義上兩者概念相同，所以很容易混淆。產品公司做產品的過程中，也是專案制管理的。所以，要根據語境自行甄別和體會。 核心區...