tdd（test driven development），即測試驅動開發的基本思想就是在開發功能**之前，先編寫測試**，然後只編寫使測試通過的功能**，從而以測試來驅動整個開發過程的進行。這有助於編寫簡潔可用和高質量的**，有很高的靈活性和健壯性，能快速響應變化，並加速開發過程。
測試驅動開發的基本過程如下：
① 快速新增乙個測試
② 執行所有的測試（有時候只需要執行乙個或一部分），發現新增的測試不能通過
③ 做一些小小的改動，盡快地讓測試程式可執行，為此可以在程式中使用一些不合情理的方法
④ 執行所有的測試，並且全部通過
⑤ 重構**，以消除重複設計，優化設計結構
簡單來說，就是不可執行/可執行/重構——這正是測試驅動開發的口號。
可想而知，測試驅動開發會極為有效地控制開發中的bug，但是這種先寫測試**的方式可能讓開發人員有很大的不適應。學習適應tdd的成本會不會比它帶來的收益更高呢？這就有待我們在實踐中摸索了
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...