軟體=程式＋軟體工程
擴：軟體企業＝軟體＋商業模式
軟體開發的不同階段：
1，玩具階段 2，業餘愛好階段 3，探索階段 4，成熟的產業階段
軟體業笑話 it's not a bug ,it's a feature!
單元測試
在這方面呢，自我感覺做的還不夠多，現在寫的程式還是比較簡單，通常也就是自己按照要求自己寫程式，直接執行，但是並沒有考慮到程式的健壯性，比如
#include int main()
,min=1,max=15,mid,n; //max為數列長度，a[0]作為第乙個陣列元素
printf("請輸入您要查詢的數:\n");
scanf("%d",&n);
while(min!=max)
{ mid=(min+max)/2;
if (n>a[mid]) max=mid;
else if (n這個程式自己只要不按照他的要求輸入就崩了，程式就不能用了。
因為水平有限，寫的**bug很多，自己的**質量不能過關，在團隊專案中很拖後腿，也學到了單元測試步驟：
設定資料，
使用被測型別功能，
比較實際結果和預期的結果。
同時也要明白好的單元測試的標準：
單元測試應該在最基本的功能/引數上驗證程式的正確性。
單元測試必須由最熟悉**的人（程式的作者）來寫。
單元測試過後，機器狀態保持不變。
單元測試要快（乙個測試的執行時間是幾秒鐘，而不是幾分鐘）。
單元測試應該產生可重複性、一致的結果。
獨立性——單元測試的執行/通過/失敗不依賴於別的測試，可以認為構造資料，以保持單元測試的獨立性。
單元測試應該覆蓋所有**路徑。
優化時要經過分析，不能盲目優化！
【課本p35】 psp資料比較
2.4實踐
寫有意義的軟體工程作業，這方面感覺系主任做得十分合理，不論是資料方面的擴充套件，還是 需求，使用者和軟體構建方面的擴充套件，都是經歷過的，這樣可以讓我們對工程有更深的理解，同時也注意自己的規範。
第三章 軟體工程師的成長
團隊的作用，團隊對個人的期望【51頁下】 ，
3.2軟體工程師的思維誤區【52頁】
3.3.1 職業發展—考級之路
想到老師讓我們去考一些證書，軟體架構等，就是提高自己的含金量，讓自己更有價值，在畢業的時候有更多的資本。
第四章 兩人合作
**規範，寫**要簡明，易讀，無二義性。
縮排四個空格，行寬以及括號，分行【格式d1】
命名，下劃線，大小寫（lowercamel方式），注釋
**設計規範，對函式，引數，類等做出規範命名。
主要感受就是，在兩人合作時就得注意**規範，其實自己開發也應該注意**規範，只是兩個人合作乃至乙個大的團隊合作，對於**的要求更是嚴格，如果沒有一定的規範，團隊中每個人都有自己的**規範，我寫我的，你寫你的，只顧自己不管團隊，那麼這個專案是不可能完成的，光和平合作都實現不了！所以要做**複審，說實話沒讀《構建之法》這本書的時候根本不知道開發軟體這麼麻煩，看了之後對其有所了解，也理解了點為何要做**複審。
對於**規範，【附圖p69**4-1】，相信很多人都看不下去，如果真的寫成這個樣子的話，那麼離被炒魷魚不遠了。
兩人合作，肯定涉及到分工，要分工肯定又涉及到了交流。團隊開發模式有很多種，各自有各自的特點，而團隊開發肯定是個複雜的專案，團隊內部也肯定要分工，有人寫文件，有人寫**，有人做設計，有人做測試等等，團隊交流很重要！
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...