en，爭取做乙隻豬或乙隻雞，而不是做乙個鸚鵡，o(∩_∩)o。
歡迎使用並提意見，因為老闆在外出差，現在暫停了業務上的推廣，但是2.0版本已經在開發日程上了。
在看書過程解決的問題
15.1.4 招數：設計變更（design change request）
經過alpha/beta階段，移山團隊收到了不少使用者的反饋，有些是意料之中的，有些是意料之外的。大家都看到，原來的設計也有不少要改進的地方。有了使用者反饋，大家也能夠取得比較一致的意見。另外，大家也有了很多新想法。一時間，眾說紛紜，很多人都嚷嚷著——dcr，dcr！
重寫或重構
小飛：我們的某某模組真是太爛了，我覺得必須重寫，而且現在又有了新的技術叫「我佩服」（wpf）[或插入任一最近時髦的技術]，它能做很酷的效果，為什麼不呢？
大栓：另外，是重構，還是重寫？重構——在盡量保持原有介面的基礎上優化部分**。重寫——重新實現原有功能，同時，要分清是全部重寫原有功能，還是偷偷加上許多新的功能（feature sneak）？
小飛：咱們找領導去，超總，看看我新寫的功能。
阿超：你不是在修復這個模組的bug麼？怎麼開始寫新的功能了？
小飛：對，不過你是不是覺得我加的這個新功能很酷，嗯……現在是有點慢，但是如果資料庫再做一些對應的修改，比如增加緩衝之類的，那就更好了。
阿超：使用者提到了這個功能麼？這和我們專案的遠景有什麼關係？資料庫修改後，原來的使用者資料要如何遷移到新的schema下面？
小飛：嗯，但是使用者如果看到了，就會喜歡的。
阿超：很多程式設計師有這樣的衝動，在做修改的同時，想到自己還能做更多的事，有乙個「東西」一直想做，但是提出幾次都沒人重視，那現在有機會，就「加進去」算了。或者還有很多靈機一動的想法。打個比方——本來是要修廚房頂上乙個有時漏水的水管，結果修理工來了，修好了水管，同時靈機一動，加了乙個帶淋浴的豪華衛生間。
小飛：但這畢竟是新的想法，我以為你會喜歡的。
如何提出dcr？
1）在提交乙個dcr時，選用任務作為工作件型別，並在標題中標明dcr。
2）在dcr的描述文字中，說明：
a. 問題在**，問題的影響；
b. 如果不修改，會有什麼後果？
c. 幾種修改方案，各種方案的優缺點和成本。
除了這個問題在看書中解決之外還有很多，就不一一枚舉了
還沒有解答的困惑
對乙個要去找工作的學生來說，專業成績和實踐能力哪個更被企業看重？
開源的**有必要附帶測試**和開發文件嗎？
資金和人力有限的創業公司需要嚴格的執行軟體開發流程嗎，還有分工上，有時候並沒有產品經理，也咩有測試人員，這時候有什麼適用的軟體開發流程嗎？
在需求分析中，可以不通過使用者，直接從現有市場的競爭軟體中取長補短嗎？
怎麼看待網際網路或者說軟體只是把傳統搬到電腦上或者網路上這種說法？業務有時候並沒有變動，這算是行業創新嗎？
測試人員的技術需要比開發人員厲害嗎？
在現實的小公司中，產品經理一般都是兼任開發職責的，利會大於弊嗎？
管理 != 技術，面對不會技術的管理要怎麼協調工作？
我在開發的過程中發現，有很多的時間都花在了分析業務流程上（兼職流程），但是如果不理解業務，開發出來的產品壓根沒法使用，在實際的企業開發中，寫**的時間和不寫**的時間（需求分析、設計等）哪個比較多？
《構建之法》讀後感 二
構建之法 這本書是很長時間以來讀到的第一本能夠吸引我的專業書。草草讀完整本書，我發現 構建之法 的作者文筆十分幽默風趣，書中把很多專業名詞或者專業知識用十分通俗的語言表達出來，甚至我們可以在書中看到很多對話形式的文字，通過這些對話，我們可以學到很多專業知識。相比於市面上很多其他專業書，這是唯一一本能...
《構建之法》讀後感二
構建之法 二 這一章提到的 規範，我們編寫 時要注重 風格規範和 設計規範，無論是類名，物件名，縮排還是行寬什麼的，在結對子程式設計時都要有所規定，不然到後面出現的類或是物件多了，就很容易混亂，分不清楚誰是誰。要學會封裝，編寫函式，將功能模組具體化，減少主方法裡面的 避免大規模的出錯。除此之外，複審...
構建之法讀後感二
我知道了乙個合格的工程師在開發時需要同時考慮質量和效率，與之同時需要具備的技能包括 單元測試 效能分析 個人研發流程 psp 並且學到了單元測試，即讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質量能得到穩定的 量化的保證 單元測試應該測試程式中最基本的單元 如在c c...