設計到底需要考慮什麼by：
kangtian0
c++
的具體背景知識、物件導向和設計模式經典書籍的閱讀、軟體開發技術管理者的精心結晶薰陶。一直認為做物件導向的軟體設計，自己的能力已經完全沒有問題。但是總歸還沒有做乙個真正專案的設計，還是有點心虛。自己很自信，但是別人問用沒用這些學過的知識的時候，還是啞口無言。
軟體工程有這樣一句名言：軟體工程是做出來的，不是學出來的。至於出處我已經忘記了。可能出於一種學生的銳氣，或者一種對理論本身的崇敬，總認為不可能技術的經驗也能算學問。
這個方面我真的很難遇到知音。直到去年，終於算遇到了乙個知音
bigben
turing
、knuth
、早期bell
實驗室中
c語言發明的一批人。我對
c方面的名人都不知道名字，但是說到做的事情，我倒是都知道一些。我則喜歡和他說說
c++方面的名人，當然不是
stanley lippman
這種人物。而是
koenig
這種設計人物和
chunk
這種務實主義者。提到
bjarne stroustrup
的時候，他總是會批判說：
c++語法搞的太複雜了。我也是這種觀點，雖然我對
c++包含的設計思想總是持肯定態度，但是我評價
c++時，總是說不該看哪些沒有用的細小的東西，而應該看大局。我還經常說的一句話是：《
c++程式設計思想》的第一卷只有兩頁紙對我有用，就是操作符過載的宣告和後面的參考數目。我和他在很多地方的觀點都是大方向上一致，但是有小小出入。從他那裡我知道了很多還值得我去認真看的書，例如麻省理工學院電腦科學的入門書籍《計算機語言的構造與解釋》。說到這裡，真覺得中國教育的悲哀，我到研二才知道有這麼好的一本書，而且我還是計算機的科班出身。他那裡真的有太多我值得學習的地方。不過他知識很雜，不像我看的書雖然也很雜，但是都是乙個方向上的，偏離的雖然很多，但是一般都不那麼理解著看。所以我有一段時間一直覺得不在有好書可以看了。和他談那麼多後，我才又認識到還有大批的好書我還不曾知道。還有，他好像比我還小，比我純真，比我有修養，性格也比我好，從他的名字和
qq上的「心中那自由的世界，如此地清澈高遠」這句話，就讓我羨慕不已。他真的很讓我佩服，雖然他有很多時候太理想化（當然這是我的觀點了）。
好，說遠了，我在說回來。
這次，就是幫老闆做乙個專案。年前和其他兩個人做需求，我自己寫了乙個實現指導手冊。因為我那段時間一直看極限程式設計，並且這個專案的時間開發很短，所以覺得應該使用這種的方法，少設計，多迭代。當然，那時候我還沒有今天的見識。
現在，架構、設計以及技術問題都解決了，我覺得有些東西得說說。先說說我從需求到設計實現的狀況。說實話，我對自己一向要求很嚴格，所以這次帶著幾個人做估計他們也會覺得有些事情很不爽，但是不敢說。但是，我真的對自己的這次技術上的表現而陶醉，或者說自豪。這個系統其實非常簡單，第一步做的就是
mis（資訊管理系統）。做這種系統沒什麼好自豪的，因為太沒有技術含量。但是我用的和設計結果我自己很滿意。說要把網路上併發請求的難點避免，因為我不敢做，做到了。說要將物件模型和介面分離，做到了。說要把網路端做成面向服務的，做到了。說要把物件模型設計成完全物件導向的，做到了。說要讓客戶端盡量使用漸進的方式獲取資料，做到了。說要有清晰的系統概念，做到了。說要用
mvc的框架思想，也做到了。並且僅僅為實現，沒有任何刻意的想，自然用到的設計模式就有：
composite
、singleton
、iterator
、adaptor
、observer
、factory
、proxy
。裡面很多並不完全就是書面上的模式，稍許變化是因為應用的需要。例如
observer
模式，所有的
subject
也是observer
本身。還有繼承的層次結構我也沒用，覺得沒有需要。因為我是寫應用程式，不是寫庫，所以暫時不需要浪費時間在這種靈活性上。說到這裡，中間也打擊了我一下，曾經有一次，我把物件模型和關聯式資料庫中的資料混淆了，導致改錯了一次資料庫。這算是我的很大教訓。還好，不到六個小時，我就發現錯誤了，且中間沒有人工作，當然除了我。因為那天我要加班，盡快建完物件模型，好讓他們快點編碼。用
rational
畫圖的時候，剪下或者複製的時候總是報
0x00000004
位址不能訪問，也浪費我很多時間。不過，好在按時搞定物件模型，並且還畫了兩個時序圖，作為典型的例子。很爽，工作的時候沒有緊張，雖然有些不妥之處，也在周一大家開始工作的時候搞定了。
說到這裡，都是我的事情記錄，那麼這個設計到底需要考慮到什麼呢？特別是這個設計實現我所有想法的時候，我真的很高興，也發現很多人不曾說的核心思想。
現在，設計主要是兩種：
1、強調先設計，不管實現，然後編碼；
2、強調**就是設計，直接就該編碼。當然，這是兩個極端，多數現在的觀點就是將這兩者結合，用快速迭代的開發方式。所以現在大量開發模型出來了，什麼極限啊、迭代啊，什麼什麼的都出來了。但是好像大家都遺漏了一點，到底是什麼問題導致了兩者的不同？
是什麼讓他們各有優缺點？？？是資訊遺失的多少，這才是問題的核心。
我們可以這樣來看問題。不管實現的設計，優點在於：不用考慮實現細節，專心了解需求，做到需求準確；直接設計，優點在於：直接用乙個實現方式表達需求，能夠立即知道時候數學化結果和想象的不同。
如果用物件導向的思想來說：純粹的設計就是乙個抽象類，而純粹的實現就是乙個具體物件。那麼這兩種方法和資訊遺失有什麼關係呢？第一種方法因為沒有實現，抽象的過程中容易偏離使用者需求，並且通常使用者本身就不完全知道需求，所以這個過程更容易遺失資訊了。的二種方法因為直接實現，所以容易準確的表達當前的需求，但是他沒有揭示可以允許的其他實現，也就是說他沒有揭示那些處理的資料之間的真正關係，而只是這個關係的乙個特例。這樣，這種方法就沒有包含真正的模型中允許的變化，所以這種方法會很頻繁的被修改。
所以現在的軟體工程強調的方法確實是很科學的，但是具體情況的時候，應該那個偏重一些呢？？？為什麼要考慮這個問題？這是因為沒有考慮實現的設計其實是一種最快速的迭代，他的迭代是在設計者的思維中進行的。他只要想一下，有可能就進行了幾次迭代，比一次實實在在的迭代少說也要快千倍吧。但是考慮到這種純粹思想上的迭代容易偏移正常的軌道，所以還是需要實實在在的迭代來證明。這時候，就存在乙個計算問題：到底在哪乙個比例範圍才是最好的呢？每人解決這個問題，因為這個問題的解決需要輸入資訊，至少需要設計者是否了解目標領域，設計者時候熟悉待使用的實現技術，設計者思想的縝密程度，當然還會有很多。
我這個專案開始是
2023年12
月做需求，
2006
年春節後才開始設計和實現，當然春節年前我寫了乙份實現指導手冊，當時自己說的是將系統遍歷了
3遍。不是沒有遺漏，但是遺漏的部分沒有影響設計和實現。我最後的設計讓自己很滿意，並不是我乙個人能做到的。
我自己對網路服務和物件模型都有充分的理論和經驗，但是
gui卻是我的弱項。我知道
gui如何訪問物件模型來獲取資料，但是卻不知道
gui上的操作如何對應到物件模型上去。這一部分就是在別人的幫助下做的，最後發現其實做
gui框架的人在這個問題上考慮得很漂亮，寫框架和庫的人就是厲害，我真是由衷得欽佩。既然框架設計者早考慮到了，所以其實很簡單就搞定了。
寫這篇文章，作為自己的紀念。這是我第乙個帶隊的專案，我對自己能做到這樣，真的很自豪，當然這和我用來如此長的時間吸取別人的教訓和經驗是分不開的，說到底，上公升到理論的東西才能體現出應用的價值。
以此紀念我：物件導向設計、經典設計模式、外科手術和無私奉獻型團隊在我第乙個帶隊專案中的成功。
沒有什麼比看一本好書能帶給我的愉悅更多了，所以謝謝
bigben
，謝謝我看的所有好書的作者，他們應該已經超過了
30人。雖然他們很多名人也很多不是名人，但是他們才是真正的學者。還有謝謝告訴我很多網路麻煩的師兄們和小老師們，他們告訴我應該避免的麻煩和怎麼避免。
快取設計需要考慮的問題
前言 沒有一種快取方案可以解決一切的業務場景或資料型別，我們需要根據自身的特殊場景和背景，選擇最適合的快取方案 一.是否需要使用快取 需要使用快取的業務場景 比如前台頁面展示，購物車 二.快取物件的粒度 一種資料乙個物件，簡單，讀取寫入都快，但是種類一多，快取的管理成本就會很高 多種資料放在乙個集合...
資料庫軟體架構設計到底需要設計些什麼
1 可用性 2 讀效能 3 一致性 4 擴充套件性 概念一 單庫 概念二 分片 分片解決的是 資料量太大 的問題，也就是通常說的 水平切分 一旦引入分片，勢必有 資料路由 的概念，哪個資料訪問哪個庫。路由規則通常有3種方法 1 範圍 range 優點 簡單，容易擴充套件 缺點 各庫壓力不均 新號段更...
測試乙個紙杯需要考慮什麼？
如何測試乙個紙杯？功能度 用水杯裝水看漏不漏 水能不能被喝到 安全性 杯子有沒有毒或細菌 可靠性 杯子從不同高度落下的損壞程度 可移植性 杯子在不同的地方 溫度等環境下是否都可以正常使用 相容性 杯子是否能夠容納果汁 白水 酒精 汽油等 易用性 杯子是否燙手 是否有防滑措施 是否方便飲用 使用者文件...