軟體,很矛盾

2022-03-06 07:27:57 字數 2512 閱讀 8650

寫軟體,很多時候都讓我感覺很矛盾,經常顧此失彼。寫的太靈活了,專案時間不夠,寫的不靈活,客戶一反饋,改的又很慘。

以前想看看什麼設計模式的,可是,看不太懂,感覺懂了,也不知道怎麼用。複習複習了什麼軟體工程,什麼瀑布模型,簡直就不太

搭邊。最近寫了乙個中文分詞系統,裡面我懂了不少東西,希望和大家分享。

這個分詞系統,和普通的分詞系統差不多。就是一篇文章,用一定的演算法把詞切開了,還有可能要計算關鍵字,詞頻。tf idf 等等。

接到這個專案時,我就想要好好寫這個軟體。初期的準備也很足,現在執行了一段時間,需求也改過一些,個人感覺還不錯。

1. 劃分模組的原則。我的乙個原則是,事情能夠大事化小,小事化了,軟體也一樣,必須把問題劃分成幾塊。對結構化設計 和 物件導向設計,說實話,

都沒有仔細去理解過,我的乙個個人原則是,按照功能快。先粗略劃分。

比如,分詞,我把這個分為:

1. 字典模組

2. 計算最有可能的分詞結果

3. 詞性標註

4. 分詞介面

基本上就是按照需求的流程圖來劃分。

這樣劃分,也不是說,四個部分 都是獨立的。開發四個獨立的模組。

1. 確定每個模組的介面:

1.1 呼叫關係

1不呼叫其他的模組

2 要呼叫1

3 要呼叫 1

4. 要呼叫2,3

這樣看來,字典是做基礎服務的,在第一層。

2,3 是 中間層。

介面在第三層。只有這裡是使用者能直接訪問到的。

這樣大概的關係就出來了,下面要看看每個模組要提供什麼功能,或者說介面。

確定的方法很簡單,從第三層的介面就老闆要的功能了。然後,倒推到第二層的介面。再從第二層,倒推字典的介面。

2. 基本的介面出來了,就是要實現每個模組。

當然,這只是腦子裡面的設計,不是直接獨立的去實現每個模組。我的習慣還是從 資料結構 + 演算法

的角度去設計。構造出演算法,然後,設計資料結構。

3. 實現乙個公用類庫

在設計的時候,發現,很多資料結構 是可以重複使用的,很多函式和具體的業務邏輯無關。我把這些公共的東西都放到第0層。

這一層的東西,和具體的業務邏輯無關,主要是實現一些資料結構。

比如,排序鍊錶啊,排序佇列等等。這個類庫,估計以後以後的專案也能用。

4. 實現第0層, 實現第一層,然後是第二層,第三層。這保證,在開發的每乙個時刻都能測試。

基本上是這樣設計的,當然其中也存在很多問題:

1. 老闆希望盡快的看到效果,也就是第三層要盡快的出來,但是,按照我們的想法,第三層不可能這樣快就出來。因為這是最後的一步。

我開發的時候,是這樣的原則:測試階段,效率,效能問題暫時先不考慮過於充分,但是,核心的演算法一定要實現。這樣就大大加快了開發的

進度。比如,字典查詢樹的問題,為了盡快的出來效果,我採用者的設計方法如下:

主要的想法是,對外的都是乙個字典的介面,具體實現可以有多種。就像你可以用sql 查詢mysql 也可以查詢mssql。要實現乙個複雜的查詢樹,比如b樹,進行查詢還是要點時間的,但是,你用個陣列,然後用二分法查詢,幾乎半天時間就可以搞定了。

測試階段,可以用陣列。效率低很多,但是不會影響分詞的效果,開發時間也快。

發布階段,寫好b樹查詢,加入新系統,系統的效率就馬上上去了。

開發中的 n-short path 問題,在測試版本裡面,我也採用了乙個簡單的演算法(n^2 速度),很快就實現出來了。

也就是說,有簡單的演算法,越簡單越好,效率不要優先考慮。但是,要為以後更換演算法,預留空間。

這樣,老闆在兩個星期內就看到了測試版本,雖然速度非常慢,一篇文章要1s鐘,但是,基本效果有了。這時,老闆就會有新的需求了,想法也就會改了,一般你做出個東西,

老闆的需求才會越來越明確。所以,測試階段的開發周期要很快,結構要夠靈活。

2. 要不要加入自己的想法?很多時候,你可能突發奇想,或者仔細考慮後,還有些1%的可能性會發生的問題,建議做好備忘錄,在測試版本出來以後再做調整。

3. 業務邏輯盡量分離。下面的結構是我經常用的結構,乙個抽象類,或者乙個介面。然後,下面一些子類。這些子類代表各種情況,或者代表不同的演算法。基類裡面我一般放些通用的,和具體業務邏輯無關的類,到了,子類裡面才加入業務的邏輯。但是,我面試的大多數人的作品,很多就是要牽一髮而動全身的。乙個需求改下來要改好幾處。

4. 是不是什麼都要統一起來?很多人,特別是像我這樣數學類出身的程式設計師,都喜歡把所有的東西統一起來,把任何類都寫的很通用。就想物理定律一樣,什麼樣的問題都能解決。把專案當類庫來寫。其實這樣的東西要適當。畢竟,我們做的是乙個專案,裡面有一些人為的很特殊的需求。很多,情況也不可能發生。

5. 不要用太多的技巧。 很多人,經常用些什麼位運算啊,非常複雜的表示式。其實,這沒有必要。平平淡淡才是真。

總之,寫**不能太過,不能太不靈活,也不能太靈活。適可而止。

軟體要有一種層次感。同時,介面的概念要深入每行**。

寫了三年**了,就這次,感覺寫了一點結構比較良好的**。

問與答 其實我很矛盾

問題 其實我很矛盾,到底該怎麼活?我從小到大都很,怎麼說話,不喜歡上學,因為要做作業,而且非常叛逆,非常懶,很對不起大家,以後我該怎麼做?我真的很累,真的很想去闖一片自己的天地,我才十幾歲就這b樣了,以後肯定完蛋了,我的回答 你就是想做些什麼,但是總要由你自己的計畫和規劃吧?學習不上可以,但是你總要...

做基礎軟體很悲壯?

這幾天中國資料庫界出了一件悲傷的事情,南大通用創始人崔維力先生突然因病去世。我和崔先生神交已久,但卻未曾謀面,一直希望有機會當面溝通討教,這一下就成永遠的遺憾了。崔先生的英年早逝 60多歲的年紀而已 又引發乙個話題 做基礎軟體,特別是做國產基礎軟體,是個苦行僧的活。相比於應用軟體,基礎軟體的技術含量...

矛盾的生活

酒吧也許是乙個讓人脫離現實的一種地方,離爍的燈光,雜亂的dj,和那些形形色色的陌生人,構成了乙個虛幻的世界,在這裡可以讓自己忘記一切,只能感覺到酒精帶來的興奮和菸草味帶來的刺激,跟著刺耳的dj狂亂的舞動著不屬於自己靈魂的軀體。那一刻,靈魂在那裡。我是誰,我在那裡,我不知道。如果愛注定是一種痛苦,為何...