《大道至簡》讀後感

歷經半個月讀完這本《大道至簡》，這本軟件工程實踐者的思想介紹讓我不單單瞭解的是軟件工程，還有一些實踐的經驗和現實中軟件工程的真正意義。其中分爲八章：精義、方法、管理、溝通、過程、工程、實踐、思想等，每章又分出幾個小節，可謂是很詳細。它讓我瞭解到軟件工程者真正的思想。

編程其實源於生活，愚公移山的例子就如編程。這是編程的精義所在，它確實反映了循環這個實例。愚公移山鑿之，而李冰以薪燒之。懶人創造出新的方法，正是由於他懶，因此他會動腦子想出更快的方法：去燒山。事事都講究方法，學習方法更爲有效。人們能夠開始分工，有告終構化編程的新方法。咱們學習編程不僅是把知識一股腦的灌輸大腦裏，應該將學習的東西分類、概括，梳理用途‘將經常使用的拿出來，這也是講究方法這一用途。

團隊的存在是軟件工程必不可少的。團隊至少以三我的爲規模，三人隊伍中的領導並不爲功績最高的，而是須要有勇氣去承擔責任的，這是最基本的素質。咱們須要的是更好的明確分工，進度和發展，合理定位團隊中的每個角色。溝通的方式和方法決定着咱們的成敗，在軟件開發的過程當中必然存在着溝通交流，有效的溝通能夠達到事半功倍的效果。溝通是存在目的性的，而不是僅僅的交流感情。溝通存在於客戶與開發團隊、項目角色與角色之間，溝通無處不在。用與不用UML在於溝通方式的選擇，選擇有效、通用的溝通方式是最佳的。

工程不能是「虛有其表耳」而應注重其實實在在的過程。軟件工程的成熟是瀑布模型的出現。而過程模型的問題是從實際工程中提煉出來的，亦步亦趨的按照前人提出的模型去作工程並不必定能夠成功，咱們的過程不是作工程的精義，也不是目的。用好的模型一步一步作出來的過程完美，但又有何用，它不是咱們實現工程的目的，作很差工程是必然的。一項工程須要去組織，就如前幾章中提到的同樣，明確組織各個角色，使得工程有條不紊的進展，這纔是完成一個工程的實際所在。咱們要去實質的去作過程，失敗的過程也是有意義的過程。

語言只是開發的工具，咱們不用批評語言的好壞，語言只是咱們進行工程的工具，沒有笨與不笨之說。正視軟件工程，看清楚代碼、方法、過程、工程、組織的關係只須要明白「語言只是工具「。纔會真真正正的知道工程。從最初的編程，到組織開發，實現目標是軟件開發的本質需求。有了需求，纔有了模型。模型在實踐中不斷精進，又產生了不一樣的模型。模型語言也只是一種工具。軟件工程體系，「實現」是軟件開發的本質需求和基本動因，推進着軟件工程理論體系的造成。

談論再多的理論也不如實踐現實中的軟件工程。正如《戰國策》中的「王不如遠交而進攻，的寸王之寸；尺，王之尺」，現代軟件工程中各個大公司的競爭也是如此。大公司在標準、理論、語言上的爭奪，未必處於「軟件實現」的考慮，他們的目的實在整個軟件工程體系中的全面勝出。理想狀態下的模式很美好「軟件工程=過程+方法+工具」，但現實中咱們又不得不考慮一些實際的問題，咱們不可能像愚公那樣的用笨方法花費個幾百年作出一個項目，因此說現實須要用更多的方法去實現項目。應該明白開發的真正須要和方法工具在工程中的實用價值，這樣才能發現現實軟件工程的真諦。

「此郎亦管中窺豹，實見一斑」告訴咱們思考問題不能只看片面，而應觀察全面。工具、方法、過程並非孤立的，實際上他們有着相互做用。在每一個環節上它們密不可分。工程的總體問題仍是「實現」。在編程過程當中咱們該如何思考，遇到一個複雜的問題，須要咱們的是將複雜的問題簡單化，將問題分紅幾個簡單的問題，而後再將問題綜合起來考慮，這就是咱們在編程中的思想。軟件工程是一個靈活的工程，並不像古代的詩經同樣，講究平仄，可是他們的變通是基於音律的；若把這種律解釋爲規律，那麼就適用於軟件工程了，死讀一本軟件工程不會作真正的軟件工程。靈活變通，使軟件工程真真正正的活起來。

總的來講，這本軟件工程實踐者的思想告訴咱們，一切不能只講理論，紙上談兵終究會失敗，瞭解到實踐者的工做思想，在實踐中活學活用，會使咱們終身受益。