※ 引述《billyeh (bill)》之銘言： : ※ 引述《micklin (mick)》之銘言： : : 在硬體越來越發達的情況下, 假設先不考慮最慢的儲存媒體IO, : : 一個程式所需要的運算時間將會隨之減少, : : 這樣會不會造成對演算法與資料結構的衝擊呢? : : 平時在寫程式時總會先考量儘量好的資料結構, 再用儘量好的演算法來達到目標, : : 如果最後程式執行所需要的時間和無架構的程式比起來, 差距只在一秒以內, : ^^^^^^^^^^^^------------ : : 那麼還需要去計較演算法嗎? 還是以儘快完成project為優先呢? : 看你所謂的「最後程式執行」是什麼而定： : - 什麼時候會去執行這程式呢？一個月以內？半年後？一年後是不是還會在用它？ : - 預計的資料量有多大？幾個月之後會不會有大幅增加的可能？ : - 會在什麼地方執行？小實驗室跑跑數據就好了呢？還是對外上線服役之用？ : 如果在你可預見的未來, 這程式不需要那麼高效、對資源不需那麼斤斤計較, : 我倒覺得可以先著重在正確性（多做點 unit testing）, : 再著重於軟體架構, 最後再著重於最佳的資料結構及演算法。 : 畢竟只要 unit testing 骨架好, 即使事後調整軟體架構, : 也不會讓系統垮掉； : 只要把軟體架構弄好, 即使事後調整資料結構及演算法, : 也不會讓系統垮掉。 : : 在現實面上, 身為一個老闆當然會希望能儘快拿到成果, : : 但身為一個寫程式的工友, 漂亮的解決問題才是我想要的。 : : 如果花兩天弄出來的程式, 跟一天就弄的出來的程式在時間上差不多, : : 那版友會選那一種呢? : : 而這樣會不會讓人失去對演算法與資結的信心呢? : 你該學習 prioritize 你的工作項目。 : 某些時候, 盡快把無趣的工作交差, : 反而可騰出更多時間投入在更值得你錙銖必較的地方。 : 當然啦, 如果你是完美主義者, 眼裡容不下一絲一毫的醜陋, : 那就當我沒說。 :) 因為我要寫的程式是Genetic programming, 程式在執行時需要的時間是training的時間, 我要在不長的時間內寫出一支GP程式讓它training的時間儘量短, 然後老闆要看的是test之後的結果如何.... 「我慢慢寫＋它快快跑」, 加起來的時間會不會等於「我快快寫＋它慢慢跑」? 沒辦法評估啊....所以才開始胡思亂想 orz 最理想的情況當然是我快快寫, 它也快快跑啊.... --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 70.171.224.50