Re: 程式效率

[micklin (Mick@Tucson)]

※ 引述《haryewkun (Har)》之銘言：
: ※ 引述《micklin (mick)》之銘言：
: : 因為我要寫的程式是Genetic programming,
: : 程式在執行時需要的時間是training的時間,
: : 我要在不長的時間內寫出一支GP程式讓它training的時間儘量短,
: : 然後老闆要看的是test之後的結果如何....
: : 「我慢慢寫＋它快快跑」, 加起來的時間會不會等於「我快快寫＋它慢慢跑」?
: : 沒辦法評估啊....所以才開始胡思亂想 orz
: : 最理想的情況當然是我快快寫, 它也快快跑啊....
: 如果有多餘時間的話……可以做一個實驗。
: 下一次，老闆有新要求的時候，你就用最快的方法寫給他，不要管程式
: 會不會慢慢跑。然後，記錄下實際 Training 的時間是多少。
: 實驗重復五次以上。
: 找出空閒時間，把上面的五支程式，用你認為最優化的時間重寫一次，
: 記錄寫程式的時間 + Training 的時間。
: 所以總開發時間 = 寫程式的時間 + Training 的時間。
: 拿這幾次實驗的數值拿來比對一下，你就可以知道，假設你當初快快寫，
: Training的時間大概會慢多少。如果你當初用把程式優化到最佳，那麼
: Training的時間又會降低到多少。
: 如果你多用五分鐘寫程式，Training的時間可以減少一小時，那麼就是
: 劃算的投資。
: 如果你多用一小時寫程式，Training的時間只降低半小時，那就不見得
: 是一個劃算的做法。
: 當然真正嚴謹地分析下去，還會有你個人的時間成本，和電腦的時間成
: 本，事情會變得更複雜。（甚至可以算出機會成本）
: 基本上這種做法的原則，就是用數據來說話，實際測試看看就知道了。

如果可以用你說的方法來測, 那我的選擇是用一個小時又五分鐘去換取一個半小時。

反正時間都花下去了, 效果是可以合起來的。

而且, 等一個小時寫完, 程式跑完, 即使發現不划算, 也來不及了啊,

我已經花一個小時下去了, 除非程式花費的時間不減反增,

不然我還是會把程式碼放進去。

現在的作法是先給粗略的版本, 再自己調整。


也許該把這個主題改為, 如何評估一個程式(軟體)的開發時間?

即使有了架構, 設計了一堆函式原型, 但是在實作這些函式或物件時,

實作的時間是怎麼評估的呢?

很多軟體公司都面臨過上市延期, 對一個營運正常沒有倒閉危機的軟體公司而言,

除了requirements產生變更所引起的延誤,

或是突發的人才離職事件, 還有什麼原因會造成產品的難產呢?


--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 70.171.224.50
推 kola12:這個主題可大了，不過有很多書在討論
推 micklin:所以有討論的價值啊~
推 ankasc:communication