@溪流
1.Bin里是所有生成的文件，包含了程序可以運行的最小資源，產(chǎn)品發(fā)布人員只需要將Bin里的文件打包就可以生成安裝文件。而默認的配置會在bin目錄里生成程序調試數(shù)據(jù)庫等一些非運行時需要的文件。Bin是面向產(chǎn)品測試與發(fā)布人員的，開發(fā)人員只是將dll和exe輸出到bin中進行調試。這樣使產(chǎn)品開發(fā)與產(chǎn)品測試、發(fā)布分開。
2.Project與Solution分開是因為每個成員都是獨立地開發(fā)一個或幾個Project的，他把Bin與SDK從SVN上checkout出來，就可以進行自己的代碼編寫，而不必關心與其他開發(fā)人員所同時進行的project的依賴關系。Solution里包含的是整個產(chǎn)品的所有project以及project之間的依賴關系。打開solution就可以生成一個完整的產(chǎn)品到bin里，而且bin里沒有任何多余的文件。

效果：采用了這套工程配置方法，整個團隊代碼與工程層面的交流明顯順暢多了，再也沒有出現(xiàn)拿到別人的工程半天build不過的問題。而且開發(fā)與測試、發(fā)布之間的卸接也很順利。開發(fā)人員每天都build后commit到svn。每周一開發(fā)部產(chǎn)品管理員用solution生成一個完成的bin并整理出track后發(fā)布到Svn上，測試人員用本周一的bin進行測試，到了Tag的時間點測試部產(chǎn)品管理員將bin打包成安裝程序發(fā)布到svn上并通知實施部門有更新版本。形成一個完整的流程。再用bugzilla與dotproject對產(chǎn)品的bug和人員進行管理。

總結：這套工程配置應該算是不依賴于第三方工具，進行基于Svn的代碼管理以及多個開發(fā)人員之間的合作開發(fā)。如果是一個人，或者project不多的時候就沒必要如此復雜。而且修改工程配置是一次的，不需要每次都修改。可以說一勞永逸。

謝謝你的評論。

@還要姓名？

瀑布汗~~~謝謝你。改過來了。

@陳梓瀚(vczh)

對啊。昨天晚上沒有睡覺，半睡半醒狀態(tài)下翻的。說實話很多英文的文檔看起來還是很費勁。雖然俺也過了CET6，不過是五年前的事了。

@新奧爾良土鱉

寒啊。竟然犯這樣低級的錯誤。也反映了平時我以靜態(tài)變量與常量沒有在意。

謝謝。馬上更新。

@autumnm1981

對啊。非常感謝！我馬上更新

@abettor

謝謝。

我是第一次試著翻譯一些自己認為比較好的文檔，一方面是為了增加自己的知識，另一方面也是為與大家一起分享。

有什么翻譯得不好的地方歡迎討論。我的email：phoenix8848@gmail.com

不錯的想法.

暈哦.我一同事寫了一個模塊,6K多代碼,沒有一行注釋,而且通篇是:
testID, devicenumber,Int? Long? Unsigned Long?....

我直接暈倒了.這樣下去真的會死人的

呵呵。比較贊同。

我感覺自己屬于后者。因為我不是學計算機的。

我更樂意用MATLAB這樣的科學計算軟件來表達我的思想。

@楊粼波


我覺得作者講的這些應該是針對那些沒有很好封裝的代碼吧?

lippman的代碼我就拿過來拜三拜..

remark了.

經(jīng)常來學習一下.

同意你的觀點.

有時候代碼的結構也是很重要的.每個人都有自己的編程風格.

對于那個copy過來的代碼進行重構,一方面是對其進行消化,用自己的風格表達.

更重要的一方面是在這個過程中對代碼進行深層次的分析,極有可能從中找出更容易更安全的實現(xiàn)方法

@jerry

我也不清楚是不是02年的數(shù)學建模題.

我不是純學數(shù)學的,感覺這個問題從思路上不是特別復雜.

關鍵是一些數(shù)學知識的運用,比如四元數(shù)\空間坐標框架的仿射變換等等.

然后就是一些線性代數(shù)方程組的求解與矩陣的運算

做了點C++又玩.NET

現(xiàn)在又回到C++

C++還是王道...

@flyman

呵呵.用極坐標系這個方法我還是真沒有想到.只想到用法向量坐標變換了.搞得很復雜.

主要是求那個插補圓的方程.

我找到問題了.就是在求角平分線向量的時候要先把角兩邊的向量化成單位向量,然后再計算.

@netcasewqs

能下啊,而且速度還挺快的.

謝謝了。不錯的書。下載了。好好學習一下。