Re: [閒聊] 資料結構不重要 ?

看板Soft_Job (軟體人)作者thinkniht (不下棋=.=)時間13年前 (2012/06/13 18:37)推噓6(6推 0噓 32→)

留言38則, 6人參與討論串4/4 (看更多)

首先我先就效能重不重要來講所謂的重不重要要看是以誰的角度來看如果是對不懂的使用者、業務、顧問、主管等等程式只要跑起來感覺順、或者有解釋為何不順的理由(藉口)就算效能不錯就算執行速度原本可以提升幾倍甚至百倍都一樣這些人對效能好不好的認定...常常可以決定開發者要不要對效能做調校而通常...都會有人為效能不好找些藉口 EX: 這程式用的程式語言本來就效能較差、這程式的運算邏輯比較複雜、資料量太大、這程式會用到XX XX的效能太爛...諸如此類基本上... 相信都不會隨便對外說自己資料結構和演算法太爛有時候...也不是資料結構或演算法的問題而是些設定或者開發者的問題舉例來說： "動作A"是一件很耗效能的事情是純做計算或者查詢不管做幾次都不會有副作用在跑某個Method的過程中 "動作A"的執行結果不管跑幾次都是一樣的也就是跑一次Method，"動作A"做一次即可但是呢有人把"動作A"放進迴圈中迴圈如果要跑1000次做1000次明明結果都一樣的"動作A"就要跑1000次如果把"動作A"拿到迴圈外就能省下跑"動作A"999次的時間之前也說過 "動作A"是一件很耗效能的事情... 那這能算資料結構或演算法的問題嗎??? 有時效能慢...就是這樣造成的一.一+ 我之前某份工作就在一個程式中遇到一堆這樣的狀況... 通通處理掉後... 原本每個人都覺得慢的執行時間... (資料量不大時要跑10分鐘以上資料量大時可以跑幾小時) 縮短到超乎所有人所能想像的程度 (我後來還沒遇過資料要跑超過1分鐘的) 執行時間很慢的狀態...起碼維持超過半年都沒有人能處理(汗) 至於資料結構或演算法到底重不重要... 我想... 遇到需要大量資料的運算或處理或者有超時的限制時...就很重要了 P.S: 我離開那份工作的原因很多其中一個原因是...效能調再好 (那些程式片段是"動作A" 其實我也是花了不少時間追) 在要求我調效能之前　就答應會視表現調的薪水...都沒有調，也沒有相關的獎勵就那份工作而言效能對我重要嗎??? 事實證明... 對主管重要 (應該吧雖然他曾經說過"速度太快不好會讓別人覺得這程式很簡單"...Orz) 對我這個開發者而言...(請大家自行想像XD) ※ 引述《AvatarH (Avatar Hsieh)》之銘言： : 就工作經驗分享： : 一、資料結構知識只是基本，如何運用於實務上才是重點。 : 如果曾管過將近百萬筆資料分散於數百個資料表，也許就會知道資料結構的重要了。 : 曾經，我在在類似汽車翻修廠的資訊部門待過，上面要求要將所有的車輛結構資訊化。 : 在每台車中，可以大略分為底盤，車身，電系，油系及液壓系。 : 這五大系統，每一個系統是由總成所構成，每一個總成可以再分為次總成， : 次總成可以再分為次總成，次總成分到不能再分時，就稱為零件。 : 所以，每一個總成要分幾次（層）才能成為零件都不相同，而且不知道。 : 而每一次分解都會產生次總成及零件。 : 在一個總成中相同的零件會用在不同層的次總成中，且數量不一定。 : 不同系統中的總成也有可能會使用相同的次總成及零件。 : 其中的一個商品展開成為零件時有八萬多個零件。 : 對於這個問題，我們是使用樹狀結構來解決的。但是我敢保證， : 即使翻遍了所有的資料結構的書，沒有一本會告訴你怎麼處理這個問題，怎麼寫程式。 : 我們是用 Java 來完成這個系統的，Java 所提供的 container 和 Collection : 都用了，但是只是拿來裝類別而已， : 如何使用將零件組成車子的演算法，則是資料結構的應用。 : 如果有人說，那我只要知道資料結構的知識就好了，不需那麼辛苦重新發明輪胎。 : 我想，有實際寫過資結構程式的人感受會比較深切些。 : 例如，資料結構中的排序，就有泡沫、選擇、插入、謝爾...等，就經驗來說， : 並沒有一種排序方法適用於所有的資料特性。例如隨機產生100個 0 ~ 100 之間， : 或 0~10^6 之間的整數，由於演算法的不同，我們就會用不同的排序。 : 第一種情形，我們用100個箱子裝隨機亂數的個數，就算用泡沫排序時， : 複雜度也不過 n^2。但第二種情形如果用 10^6 個箱子，那麼系統效能必定不好， : 所以勢必要換演算法，所以也會用不同的排序方法。 : 二、SQL 查詢命令最好根據資料庫特性撰寫。 : 把車子結構樹狀化的目的是為了申請零件，由於常發生零件申請量不足的問題。 : 這是由於每個總成都有專門部門負責維修的，一個部門可能要修很多種不同的次總成。 : 然後，相同的零件可能會用在單一部門所維修的不同次總成中， : 或不同部門維修的次總成。所以零件的需求量常估錯。 : 因為每個部門底下還有不同小組，每個小組只知道自己的需求， : 還有修護人員為了修護方便常常會私屯零件，所以超量申請。 : 例如一台車子只有四個輪胎，卻申請五個。 : 為了處理這個問題，我們從前面的結構系統中跑出這個部門的已申請、待撥、 : 、欠撥、已撥，及申請時的申請數上限。 : 這些都需要對資料庫做查詢，由於系統的資料筆數非常多，所以有時查詢非常慢。 : 所以我們發現到，資料庫查詢指令必須依照資料庫特性來寫。 : 例如，查詢結果的資料有循序性，或部分連續性，或沒有連續性，相同的 SQL Statement : 將會造成不同的執行效能。 : 所以後來，雖然都是查詢，但 SQL 語法卻不盡相同，都會上系統調教才確定。 : 通常 DBA 都是資深的 Coding 人員轉的。 : 當然資料庫效能和資料表的正規化和關聯性也有很大關係，但不多贅述。 : 三、系統演算法的效能很重要 : 由於開發系統的通常是資訊部門，所以擁有最好的電腦是理所當然的， : 在開發過程中，硬體效能的瓶頸是幾乎感受不到的。 : 但是，系統總有一天會上線，只要系統夠大，硬體瓶頸就會感受到了， : 我原來的公司有將近百台電腦，如果因為系統要上線，所以建議老闆要將公司 : 的所有電腦更換，我想下場會很慘吧。而且使用者給太好的設備其實意義不大， : 只會被拿來做對工作產能沒有幫助的事。 : 也不能要求老闆買一台超級伺服器來跑系統吧。再說再強的伺服器也有極限的。 : 所以在系統開發的過程，我們就不斷的修改演算法，以增進系統效能。舉例來說， : 第一部分的樹狀結構，我們從第一版的30秒以上產生樹狀結構，到定版的5秒以內 : （從按下瀏覽器的按鈕到結構圖顯示完畢），才達到一個可接受的系統效能。 : 希望這些經驗能有所幫助。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.42.226.13 ※ 編輯: thinkniht 來自: 114.42.226.13 (06/13 18:39)

推

yauhh

06/13 19:05, , 1^F

06/13 19:05, 1^F

推

flylover

06/13 21:12, , 2^F

06/13 21:12, 2^F

→

flylover

06/13 21:12, , 3^F

06/13 21:12, 3^F

→

YunJonWei

06/13 21:57, , 4^F

06/13 21:57, 4^F

→

YunJonWei

06/13 21:57, , 5^F

06/13 21:57, 5^F

我記得以前也講過類似的事情效能這種事情要看需求大家都覺得慢提升才會讓人覺得你的產出有價值 (雖然我很清楚提升效能的事情最後都會說是主管自己想到辦法提升的不會提到我) ※ 編輯: thinkniht 來自: 114.42.226.13 (06/13 22:26)

→

leiyan

06/13 22:02, , 6^F

06/13 22:02, 6^F

→

thinkniht

06/13 22:27, , 7^F

06/13 22:27, 7^F

→

thinkniht

06/13 22:28, , 8^F

06/13 22:28, 8^F

→

thinkniht

06/13 22:29, , 9^F

06/13 22:29, 9^F

→

thinkniht

06/13 22:30, , 10^F

06/13 22:30, 10^F

→

leiyan

06/13 22:47, , 11^F

06/13 22:47, 11^F

一支程式維護性差到讓人能不動就不動... 相信是很常見的事情而且... 主管也對我說過未來不太會動那個程式之後會拿另一個新版本的核心模組當主力主管都這樣說了...我去改那個恐怖的東西做啥XD 其實該說覺得一般而言... 都是跑的結果正確程度可以見人就好(趕著驗收咩) 之後才會想到維護性與正確性那些這時可能就會說... "先驗收之後再來提升維護性那些" 根據我對人性的了解... 結果通常都是沒有使用者或客戶要求之後都不會再改XD ※ 編輯: thinkniht 來自: 114.42.226.13 (06/13 22:57)

推

CRPKT

06/14 09:51, , 12^F

06/14 09:51, 12^F

廣義上...好像是吧但這樣的例子...需要去學甚麼演算法相關的東西嗎? ※ 編輯: thinkniht 來自: 114.42.228.54 (06/14 10:28)

→

yauhh

06/14 10:40, , 13^F

06/14 10:40, 13^F

→

yauhh

06/14 10:40, , 14^F