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

[thinkniht (不下棋=.=)]

首先 我先就效能重不重要來講
所謂的重不重要 要看是以誰的角度來看
如果是對不懂的使用者、業務、顧問、主管等等
程式只要跑起來感覺順、或者有解釋為何不順的理由(藉口)就算效能不錯
就算執行速度原本可以提升幾倍甚至百倍都一樣
這些人對效能好不好的認定...常常可以決定開發者要不要對效能做調校
而通常...都會有人為效能不好找些藉口
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:在需要你時,無所不用其極講好話,就是這個樣子.
推 flylover:效能高低與能力優異，他們不會懂..他們只在意下次可以端
→ flylover:什麼新菜去給上頭爭寵，看會不會升官加薪..
→ YunJonWei:調效能這件事情真的很容易被人忘記，因為看不到，
→ YunJonWei:使用者又很容易忘掉舊的體驗。(忘了你做的改善)
我記得以前也講過類似的事情
效能這種事情 要看需求
大家都覺得慢 提升才會讓人覺得你的產出有價值
(雖然我很清楚 提升效能的事情 最後都會說是主管自己想到辦法提升的 不會提到我)
※ 編輯: thinkniht       來自: 114.42.226.13        (06/13 22:26)
→ leiyan:一般還是維護性擺前面 效能再說啦
→ thinkniht:維護性...(我忍不住嘴角上揚了) 但你說的是一般
→ thinkniht:我覺得我遇到的是特例...(不過正常不是正確性擺前面嗎)
→ thinkniht:雖然我在正確性上也做了很大的拯救...不過維護性啊...
→ thinkniht:太恐怖了XD
→ leiyan:好維護的話就比較容易修正 不過最終目的都一樣啦
一支程式 維護性差到讓人能不動就不動...
相信是很常見的事情
而且...
主管也對我說過 未來不太會動那個程式
之後會拿另一個新版本的核心模組當主力
主管都這樣說了...我去改那個恐怖的東西做啥XD

其實該說 覺得一般而言...
都是跑的結果正確程度可以見人就好(趕著驗收咩)
之後才會想到維護性與正確性那些
這時可能就會說...
"先驗收 之後再來提升維護性那些"
根據我對人性的了解...
結果通常都是沒有使用者或客戶要求
之後都不會再改XD
※ 編輯: thinkniht       來自: 114.42.226.13        (06/13 22:57)
推 CRPKT:我覺得你舉的例子算演算法啦, 廣義來說
廣義上...好像是吧
但這樣的例子...需要去學甚麼演算法相關的東西嗎?
※ 編輯: thinkniht       來自: 114.42.228.54        (06/14 10:28)
→ yauhh:任何一個牽涉到有步驟可完成事情的方法都叫演算法,並沒有說
→ yauhh:特定某範圍中的討論才稱為狹義演算法.
→ yauhh:就好像資料結構,就資料結構,不會有什麼要廣義才稱資料結構.
推 CRPKT:我看法和樓上一樣, 我覺得很難找到一條界線可以說哪邊才算
→ CRPKT:「真正到演算法層級的問題」, 以你的例子來說, 更廣泛的型式
→ CRPKT:是, 有一個很耗資源但在某個環境下無 side effect 的操作 A,
→ CRPKT:散佈在運算中的各處, 那解法之一就是 cache, 拿一點 memory
→ CRPKT:去換回時間, 而「把 A 從迴圈內抽出來」的方法只是它的特例
→ CRPKT:即使它看起來很平凡, 但很難說它不是演算法的一環
→ yauhh:討論演算法是有個原則是要講明輸入,輸出,以及明確的步驟.
→ yauhh:那所謂廣義的是稱為方法沒錯,但談到明確的步驟才是演算法.
→ yauhh:而你說把一個快取組合到迴圈中,這只是一個系統描述而已.
推 CRPKT:這個是名詞定義的問題, 不然叫它演算方法好了
→ CRPKT:我回的是針對原文的問題, 資料結構和演算法到底重不重要
→ CRPKT:當然這樣馬上就碰到名詞定義問題, 而我想說的是, 與其討論
→ CRPKT:演算法重不重要, 不如來看「演算方法」重不重要比較有意義
→ yauhh:不不,原文演算法就叫algorithm,不會因為你這樣討論就講成
→ yauhh:像algorithmic methods之類擴充字眼. 演算方法,演算法,差一
→ yauhh:個"方"字,意思會差到哪裏去?
推 CRPKT:我知道你的意思啦, 我指的原文是原po的文章, 不是英文
→ CRPKT:我只是提議調整原題, 沒有要挾持名詞的意思
→ CRPKT:但是如果覺得沒必要的話我就打住好了 :)
→ yauhh:我沒跟你核對所謂"原文"二字的意思. 我講的原文當然跟你講的
→ yauhh:不一樣,而不是像你這樣二個字眼一下子混為一談了.
→ yauhh:我的意思其實只有個懷疑. 過去從來沒聽過所謂廣義狹義演算法
→ yauhh:因為什麼是演算法,其實是不言自明的.