※ 引述《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