今天我讀了構建之法第一章，軟體工程到底是什麼，原本懵懂無知的我只知道軟體工程就是編**，寫工程，但是我讀了構建之法之後，我發現不是這樣的。
首先書中大體概括軟體工程是把系統的、有序的、可量化的方法應用到軟體的開發、運營和維護的過程，它包括軟體需求分析、軟體設計、軟體構造、軟體測試、軟體維護等等，這是我當初選擇軟體工程所不知道的，當初的我只是為了學習**而進入的軟體工程，為了能夠找到好的工作而學習軟體工程。
現在我讀了構建之法這本書，我感受到了軟體工程不只是做軟體寫工程，雖然說我們在開發過程中，就是磊**的過程，但是我們應該更加注重一些東西，比如說團隊的合作，**的儲存，軟體工程更加側重短期的實際結果，對各種因素的折衷，對不確定性和風險的管理，足夠好，具體的應用，關注和應用各個相關科學的知識，解決問題，百花齊放的實踐方法，在實踐中建立起來的感覺和直覺，比較可靠等等。
2023年，ieee發布了swebok，提到了15個軟體工程涉及到的知識領域，足以證明軟體工程涉及領域之廣，有人說，作為軟體工程的學生就該編出足夠好的軟體，所謂的足夠好，就是沒有bug，使用者足夠滿意等等，但是這些還是空談，軟體都有bug，沒有足夠好的軟體，只能一步一步的做得更好。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...