?不知不覺已經讀到了大道至簡的最后兩章，在這本書中讓我學會了許多程序員必備的素質和技能，讓我對軟件工程這個專業有了根深的了解。在第七章作者著重講了現實中的軟件工程。從最早僅僅關注于軟件開發工具到現在，軟件行業中的巨頭們已經在層出不窮的思想中涅槃了一回又一回。大公司們在標準，理論，語言上的爭來爭去，未必全然出于“軟件實現”的考慮。對統一理論，統一工具，統一過程的企圖，其最終目的是在整個軟件工程體系中的全勝而出。算盤上的絕大多數人，只是用于計算勝負的一枚算子。所以，除了軟件本質力量的推動之外，商業因素也推動著軟件工程體系的發展。大公司們的爭奪戰的最終結果，已經開始把軟件工程，從原始的“自生演進”狀態，逐漸推進到“它激發展”的狀態上了。在“程序”與“方法”層面，是關注于“(具體的)實現”的；而在“過程”和“工程”層面，更首要考慮的是團隊問題。從角色的角度上來說：開發經理思考項目的實施方案和管理具體的開發行為； 而項目經理則保障團隊的穩定性和一致性。?然而這只是基本模式，或者說，是理想模式。這種它激發展可能會影響到軟件工程發展的速度，然而在各個工程層面上的關注點并不會發生變化。從角色的角度上來說：開發經理思考項目的實施方案和管理具體的開發行為；而項目經理則保障團隊的穩定性和一致性。然而這只是基本模式，或者說，是理想模式。

? ? ? 理想狀況下，“軟件工程=過程+方法+工具”。然而工程成功的真正關鍵，并不是在于你把你的團隊“組織”得非常好。即使在團隊中他們都顯示有條不紊，你一樣會面臨失敗。正如前面所說，如果你是一個軟件公司里的項目經理，你可能今天的工作是寫一份項目計劃案，或者聽測試部的報告，又或者是安排會議來聽取和分析一個新的產品需求。

? ? ? 過程伴隨工程而出現，工程又是如何出現的呢？根本的原因是軟件規模的不斷增大所導致的。隨著軟件規模的的增大，僅僅一個人的話花費的時間是巨大的，在現實中不會有軟件公司給這樣的機會的。項目的“復雜”可能可能需要不同知識領域的角色參與，而“龐大”則要求更多的資源。“團隊”作為開發行為的模式，是軟件規模和復雜度漸次累積的結果。團隊越來越龐大，因為軟件規模越來越復雜。沒有團隊意識的軟件公司將在高度過程化，通曉方法理論，擁有大量工具的集團軍面前一觸即潰。

? ? ?最后講的是思考，思考問題的方法可以是由點及面的，也可以是統攬全局的。換成業界最常用的詞匯，就是“自上而下”還是“自下而上”的區別。RUP是對前人在軟件過程思想方面的高度包容。它如同一個雜貨箱一樣放滿了各種稀奇古怪的東西。RUP能不能被用起來，將取決于你挑挑揀揀的行為。出于共同的必要，UML的象征意義在一個圖中應當被表述得足夠準確和詳細，乃至于針對于不同的閱讀者來說都能提供了充足的信息。所以在工程中使用UML圖，應該有相應的文字來描述它。而且這種描述與圖之間的對應關系要持續的維護下去。所以UML有了屬于它自己的規約。

?

轉載于:https://www.cnblogs.com/hyluckydog/p/4966630.html

總結

以上是生活随笔為你收集整理的《大道至简》第七八章读后感的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。