構建之法的讀後感
七月份讀完了構建之法這本書，粗讀，基本了解了軟體工程這個專業的工作，就業，和前景。目前有如**會（構建之法這本書正如前言所介紹，適合軟體工程的任何階段去讀，我現在只閱讀了一遍，還會繼續地讀下去）：
一， 原來，軟體工程並不是像我再選專業之前認為的那樣，只是一群人在一起敲**。軟體工程的定義是把系統的，有序的，可量化的方法應用到軟體的開發，運營和維護上的過程。（構建之法p8），而軟體工程這個專業裡細分了，軟體需求分析，軟體設計，軟體構建，軟體測試，軟體維護。以前只是簡單的構想，軟體只是乙個人寫完的，在讀完了構建之法後，覺得以前的想法很幼稚，軟體工程沒有個人英雄主義，而是乙個團隊，一同辛苦努力工作的結果。去寫任何乙個軟體，都要有規範的步驟，分析需求---生成設計文件---設計複審---**規範---具體設計---具體編碼---**複審---測試。成熟且實用滿足需求的軟體並不是一蹴而就的，而是一群人的成果。
二， 讀完構建之法後，簡單了解了軟體工程師的就業，和考證，第三章系統講解了軟體工程師的成長之路，引用p59頁的圖表，sde初級軟體開發工程師（入門。在學校裡學到了些技能，尚未在實踐中得到充分鍛鍊）---sdeⅱ中級軟體開發工程師（獨立。可以寫別人交給你的任何東西，不明白時知道去問誰）---senior sde高階軟體開發工程師（小組領導。影響著3-12名工程師，或者是他們的行政領導；或者是他們的技術帶頭人）---principal sde首席軟體開發工程師（團隊領導。影響著10人以上的大團隊，成為影響團隊成敗的關鍵人物）。書中還給出了有中國特色的好工程師的要素。
三， 通讀完整本書之後，要成為乙個善於交流，說到做到，接受團隊賦予的角色，全力投入團隊，融入團隊的軟體工程師。我認為，乙個優秀的軟體工程師，不管**寫的好與壞，首先要是乙個善於交流，懂的合作的人，善於同團隊交流，才有利於共同解決問題，才有利於**複審等後期工作的展開，我相信，當軟體公司在招聘人才時，首先會注重他的交流與表達，能否融入這個團隊，其次才是寫**的能力。我希望自己在以後的學習過程中，要多與人交流，不能是自己獨自一人閉門造車。
四， 第四個感悟就是規範化，讀完這本書後，看了看自己大一一年寫過的作業，如果不是自己單獨給每個vc檔案命名，有很多**自己看完了都不知道這個的功能到底是什麼，需要在重新執行一遍。在構建之法中，強調了團隊規範的寫**的規定，比如4個空格要優於tab鍵，其次在命名變數的時候要選取合適的單詞作為變數名，擷取我寫的**的片段，自己在沒有閱讀之前真的是太太太太太不規範了，太太太太太太太隨意了
void student::setstudent()
cin >> xuehao;
cin >> nianling;
cin >> name;
cout << "建立資訊函式被呼叫" << endl;
學號，年齡等資訊直接用拼音表示了出來，在寫**時雖然簡單明瞭，但是現在再反過來看時，真的有些看不懂，不利於後期的改進和他人的閱讀。自己第二個的缺點就是，沒有注釋！沒有注釋！沒有注釋！在作業中很多class類是幹什麼的現在在看已經忘了，再加上自己**寫得很不規範，導致了我寫的程式，連我自己都不明白這段程式是執行什麼的，是完成什麼功能的。
以上是我的部分感悟，構建之法這本書真的很好！正如前言所說，這本書就應該每個軟體工程專業的人人手一本，這本書給我的感覺就是適合一直去讀反覆地去讀，每個不同的階段去讀都會有新的感受。在小學期以後我回去讀第二遍，第三遍，獲益匪淺的好書!
構建之法讀後感
書中有提到一句名言 軟體 資料結構 演算法 但是，在真正進行軟體開發時，我們會發現 我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式，擴充套件...
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...
構建之法讀後感
第一章 軟體工程。寫軟體就是碼 寫出來，組合語句和演算法，實現需要的功能。但是軟體的開發需要一定步驟，有團隊合作精神，經過需求分析明白客戶需求，要什麼功能，並完成軟體的概要設計，再進行討論並與客戶溝通。然後進行軟體設計，然後程式 編寫，軟體測試debug，體驗版，後續維護等等。這樣才是乙個專案。軟體...