隨着時間的不斷推移,咱們的java課程也快接近尾聲了,已經開始進行java的備考時間了,雖然時間是這麼的緊迫,但我仍是在百忙中抽出了這點時間,來寫大道至簡第六章的讀後感。
過程伴隨工程而生。過程解決的是工程中角色的關係問題。過程當中的問題就是角色、溝通和環節的問題。過程是怎樣的,客戶不關心,他不會由於你對技術的遠景描述而憧憬,他要的 只是實質性的程序。工程,工程的實現須要用到工具,須要實現方法,有一個團隊協做的過程,並最終實現出對象。項目的「複雜」可能要求不一樣的知識領域的角色參與, 而「龐大」則要求更多的(人力、技術與管理)資源。「團隊」做爲開發行爲的模式,是軟件規模和複雜度漸次累積的結果。
工程和組織最好分開來說,項目經理在關注工程細節的同時還要關注人力資源、項目資金以及多個項目之間的協調等等。這些與工程自己並無直接關係,而是「組織」方面的內容。這些都在試圖說明一個項目經理必須有一部分甚至是絕大部分非技術性的工做。項目經理要創建計劃,制定目標,培訓員工,協調工做,準備資源,決定項目某個環節的的進度,還要常常開會來總結、激勵甚至是懲罰員工,還不能盲目樂觀。若是你作不到這些,你頗有可能會犯錯誤,而後失去員工的信任,接下來等待着你的就是收拾東西走人。
正如「模式」是一種方法,而模式就是你昨天書寫代碼的那個行爲。你看不到你作事的行爲,也就不能理解「模式」做爲一種方法的價值。因此大師們衆口一詞:模式須要必定的編程經驗才能理解。同理,理解過程也須要編程經驗,理解對象也須要編程經驗,這可能就發生在你去回顧你上一行代碼編寫的通過,或者上一個項目失敗的經歷的那一瞬息。經驗來源於回顧、理解與分析,而不是你將要寫的下一行代碼。
工程,是對目標的描述和成果的檢測,實現就須要工具來幫忙。軟件規模的不斷增大是根本緣由。然而,幾年前並不須要工程。即便有一我的願意用20年的時間去寫一個任意龐大和複雜的操做系統軟件公司也不會給他機會。複雜須要不一樣知識領域的角色參與,可是龐大則須要更多的人力、技術與管理。「團隊」是軟件規模和複雜度逐次積累的結果。團隊愈來愈龐大意味着軟件規模愈來愈複雜。
不少人覺得老闆是給本身發錢的那我的,這實際上是錯誤的。發錢的決策一般是由 部門團隊經理,紀效經理, 財務經理來作出的。老闆在公司中解決的是「經營」問題。從做者的敘述中,我明白了,咱們要明確本身被僱來的緣由,本身的工做是面向哪 一個層面的,以及你或者你的上司有沒有權限來決定是一 個項目是否應該立項,或停止,這也很重要。
我仍是要繼續的去學習java這門課程,踏着朝陽,迎着但願,共創美好將來java