背景：
現狀的問題：
1、客戶端**整合度高
目前客戶端的整合度非常高，地區的整合，不同功能的整合，都在一起，說是叫平台，但是實際上隨著規模的擴大，**變得越來越耦合，越來越不可控，修改起來極其困難，開發起來及其難受，中間是乾溝河的，並沒有約定的介面，也沒有約定的通訊流程，導致開發效率極低
2、打版本成本高（時間，金錢，人力）
無論是c++語言的特性也好，還是打本的機器不夠給力也好，無論是開發**太多還是拆分的不夠徹底，從打版本的角度上來看，至少效率不能比q4差（單台機器15-20分鐘），無論你要用什麼樣的方式。先說下打版本慢的缺點，第一，交付周期長，遇到問題等待時間太長，浪費開發效率，測試效率；第二，依賴高配置機器，導致沒有高配置，玩不轉；第三，維護成本高，維護這麼一套大版本工具，花費的精力太大。打版本成本高的最根本的原因，我個人認為就是**的問題，還是乙個辦法，那就是中國特色的拆~（後邊繼續討論這個問題）
3、結構組織有問題
（待定）
4、研發管理跟不上生產力
從開發的角度上看，第一：自測不夠充分，沒有衡量自測的乙個硬性標準（寫自測列表之類的不靠譜）；第二：開發不了解整個**的框架，也沒有機會和時間去了解；第三：**的質量純粹靠經驗；第四：**的執行效率完全靠猜測，也沒有給出內部依賴產品的乙個效率文件，反正方法很多，就隨便寫吧；第五：**結構有問題，耦合度太高，容易互相干擾。
從測試的角度上看，第一：沒有進行分層測試，現狀是開發簡單測試（跟沒有一樣），手工測試進行功能驗證（ui測試），自動化冒煙（ui測試），然而整合測試，效能測試，一概沒有（掐表測效率的那種不算，實在是太low了。。。。）；第二：手工測試只是進行功能驗證，他們對計算機，軟體，**的知識不夠明白（舉個例子：當前明白10%，需要明白40-60%），導致在測試的時候，只能看到功能測試的部分，對其他地方覆蓋不到；第三：測試的覆蓋率低，就當前的軟體來說，基本上只有ui測試，隨著多執行緒，多程序的使用，有些情況，ui是無法進行測試的，導致覆蓋率越來越低，問題越來越多
研發管理跟不上當前的生產力，導致的後果就是開發和測試無盡的加班，軟體無盡的不穩定，無限的bug
我思考的解決辦法（不全，也不一定對，只是想表達出來）：
1、降低客戶端**整合
解耦，拆分當前的客戶端**，在拆分的時候，要有有乙個整體的構思，比如，我們有自己的約定，有自己的配置，各個模組之間如何進行配合，我們的配合規範是什麼，這個非常重要，不是說把dll簡單的查分出來就ok了，這樣是解決不了根本問題的
約定優於配置，現在連配置都沒有。。。。
2、打版本成本高
根本解決辦法還是從**的角度上來，做功能模組的拆分，做類似於網際網路微服務的結構，不要全量進行，分布式的優化等等，這些全部都要進行考慮
3、組織結構問題（待定）
4、研發管理問題
按照功能模組拆分出的**，進行持續整合，跑自測用例，自動化冒煙，每日構建；功能測試協助開發進行自測，功能測試進行功能驗證；開發可以測試效能的工具，使用工具進行新能測試（如果有第三方的自然更好），以**作為維度，不要說幾秒鐘，避免扯皮現象；模組之間的測試需要進行整合測試，可以使用自動化手段或者人工手段均可以，這個要看如何進行**的拆分。進行**測試覆蓋率的檢測，有針對性的提高**覆蓋率。總的來說就是，模組拆分，持續整合，分層測試（自測，整合測試，功能測試，效能測試，其他等），這樣提高測試覆蓋率，提前發現問題，把風險前移。
未完待續。。。。。。
關於胖客戶端
目前his系統由於業務複雜，要進行大量的運算，而且his系統在執行一段時間後，資料量激增，資料庫占用空間增長很快，導致his投入執行一兩年後，反應速度急遽下降，在進行乙個簡單的儲存或刪除業務時都要花較長時間，甚至讓使用的醫務人員也難以忍受，這時就應該考慮採用胖客戶端了。所謂胖客戶端，這裡是指將常用的...
關於胖客戶端
目前his系統由於業務複雜，要進行大量的運算，而且his系統在執行一段時間後，資料量激增，資料庫占用空間增長很快，導致his投入執行一兩年後，反應速度急遽下降，在進行乙個簡單的儲存或刪除業務時都要花較長時間，甚至讓使用的醫務人員也難以忍受，這時就應該考慮採用胖客戶端了。所謂胖客戶端，這裡是指將常用的...
關於獲得客戶端ip
在 asp 中使用 request.servervariables remote addr 來取得客戶端的 ip 位址，但如果客戶端是使用 服務 器來訪問，那取到的就是 伺服器的 ip 位址，而不是真正的客戶端 ip 位址。要想透過 伺服器取得客戶端的真實 ip 位址，就要使用 request.se...