關於軟體設計的心得：
之前做過乙個投資管理系統
甲方負責的專案經理是公司的管理層，可以說一輩子都是在做公司的投資管理活動；對這一套流程和各方面的把控都非常瞭如指掌，用他自己的話來說：我其實自己腦子裡面有一套系統的，只不過現在是結合貴公司的實施能力，把它具現出來了。
最後的結果是，系統按照預想的完整的投資管理流程，實現，對投資管理的事前事中事後都進行了管控，特別是事前和事中，進行了非常詳細的管理，顆粒度也很細。但是由於客觀的原因（軟體過於複雜，使用者需要很大的學習成本；系統管理顆粒度過於明細，實際的管理過程缺乏的靈活性；管理水平沒有達到要求），系統之後沒有使用（後續還做了一套比較簡單的，粗顆粒化的投資管理系統）
就單個專案而言，這個投資管理系統是失敗的，絕對失敗了，他連成本都沒有回。
不過我現在聊的是她好的地方。
這個系統設計的真的很細，幾乎把投資管理的全流程都考慮到了，同時也對控制住了各個環節。這樣乙個新業務系統的搭建，是需要非常多的時間和精力的。在這之後，我陸續接觸到了幾家做sass產品實施的公司，雖然各子業務不同，但是策略很相似，而且在獲得了一定的市場。他們的實施難度不大，但是卻獲得了成功，讓我開始對軟體設計有了自己的思考。
這幾家sass產品的實施，承載著的是業務，但是產品偏協同作業方向。給使用者帶來的是溝通協調的便利，業務其實很簡單，或者說有意做的非常簡單，考慮到影響工作效率最大的是溝通（srm和工程管理，參與方不是乙個公司內部，而是**鏈上的各方）。
1、其實無論是本地化的實施，還是sass 產品，我們都需要有乙個特別懂業務的專案經理或者是甲方負責人。他們對業務的理解是方方面面的。在了解自己要做什麼系統之後，才去考慮怎麼去組方案。目前很多sass 產品的小夥伴，方案和業務能力真的很弱。
2、在梳理了業務流程的基礎上，我們要知道，資訊化最簡單，最原始的目的是為了提高相率，簡單的線下業務提到線上，就是為了提高效率，協同也是。
所以有乙個原則，設計是為了提高效率。涉及到人的工作，提高效率很重要的一點，就是靈活度。資訊化有乙個好處，可以讓線上流程嚴格按照邏輯設定的流轉。這也是乙個不好的地方，他太笨了，不知變通。
其實之前碰到過很多次，在保留業務完善度和靈活性之間，去做取捨。
很多的專案經理或者產品經理，會說，我的業務非常完善，我的流程考慮了所有的情況，但是，實際是，這個業務流程特別複雜和僵硬。其實可以非常簡單，讓參與的雙方溝通，給他們不同的選項，給他們不同選項的原因，就夠了，複雜的流程，得簡單化。
我們不是做數學題，是為了提高效率 。
3、最近學習新的業務時候，發現工程管理的內容，要複雜真的很複雜（可以看一下下面的流程圖）。
如果要按照之前做投資管理的方式，對他做事前事中事後的管理，這個不工程量太大了，而且也不會適合每個工程專案。
我能預想的是和如果按照投資管理一樣去做，也會像投資管理一樣，碰到相同的「客觀問題」。
總結一下任務：初始化，任務定義，然後是使用者使用。
使用的方式再說一遍，就是協同，各方按照簡單的業務先後，在系統中協同，保證業務流程進行下去，也給了各方很大的操作空間，我覺得這個是好的想法，也是軟體設計的可取之處，軟體，就應該簡單
流程圖：雲建工程寶：收藏 | 工程建設專案史上最完整的全流程圖，必收藏備用！
自動軟體設計
在1973年，美國人peter freeman在他的文章 自動軟體設計 automating software design 中有這樣的假設 如果有這樣一台機器 當我們告訴它我們需要什麼軟體的時候，它立刻就會滿足我們的要求，自動生成我們需要的程式。這台機器我稱之為萬能機。當我們提出需求的時候，需要關...
軟體設計原則
開閉原則 ocp 軟體設計的最大原則 這個原則說的是 對擴充套件開放，對修改關閉。其實意思是說，給系統新增新的功能，但不修改原有 如果能做到呢，關鍵在於抽象化，也就是封裝變化，抽象層不變，讓具體實現依賴抽象隨需求變化。使得系統具有很強的擴充套件性和可維護性。黎克特制代換原則 任何基類可以出現的地方，...
軟體設計原則
高內聚 低耦合 乙個軟體系統要有乙個穩定的架構，不會隨需求的改變而發生巨大的變動。因此，高內聚 低耦合是乙個軟體系統設計中必須遵循的基本原則 面向抽象程式設計 在面向過程的軟體開發中，上層元件呼叫下層元件，就意味著上層元件依賴於下層元件，當下層元件發生劇烈變化時，上層元件也要跟著一起發生變動，這將導...