推 ykjiang:有理 09/13 09:35
※ 引述《haryewkun (Har)》之銘言：
: ※ 引述《haryewkun (Har)》之銘言：
: : 推 ykjiang:把它想成程式要跑很久才會得到結果就好了， 09/11 10:17
: : → ykjiang:很多模擬實驗都有類似的性質，而且還要調各種參數後重跑 09/11 10:18
: : 推 ankasc:第一段他意思應該是反正兩個都是同樣的功能，都寫也都拿用 09/12 00:48
: : 推 haryewkun:我是問什麼叫做"用一個小時又五分鐘去換取一個半小時" 09/12 08:30
: : 推 ankasc:就是說兩種程式他都寫，那麼都run，就只需花1.5hr 09/12 13:44
: : → ankasc:更正，應該說他寫兩種，且兩種的程式一起跑，可省1.5hr時間 09/12 13:46
: 我重復看了 n遍，還是搞不懂m大的回應是在說什麼。
: 兩個程式都寫，重點不是這一次的程式，而是要決定下一次開發的時候所要
: 花費的時間。這應該算是一種適應（Adaption）的技巧。
: 並不是說每次都要寫兩份程式……只要能夠達到平衡（投入和支出的比例最
: 大化），那就可以停止了。
: 當然如果每一次要寫的程式都極端不一樣，那就不適用這方法。但是正常情
: 況來說，不大會出現這麼極端的例子。
我猜，這可能就是開發的軟體觀點不同吧...:)
依照一般的軟體開發過程來講，
每次接不同的專案或軟體，總還是會找出一絲絲可再利用的，
所以就算是兩種不同架構的程式都想寫好了，第二次那一次總會比較少花一點時間，
（假設第一次寫的東西有做適當模組化，就算沒有，邏輯上總會有些東西可再利用的）
所以在獨立估計時間的情況下，可能會猜寫第一種程式需要5min，
寫第二種程式要1hr，但如果依序先寫第一種、再寫第二種，
在開發第二種程式時的時間，就會少於1hr，
所以寫兩支程式，並不一定會花上1hr5min。
好吧，就算分成兩個不同的人寫好了，這個時間的估計就又不一定相同了，
且也不一定可以直接拿來比較。
（這又牽扯到專案中的人力成本問題）
又更何況，在開發專案、軟體的情況下，
通常時間這個東西，也不太會允許程式工友去寫兩次一樣的東西，
所以寫兩種不同架構、但相同功能的方式，在軟體開發上有一種很奇怪的衝突，
通常也都是如前面所談的，先求有，有空再求好，（前後都是基於修改第一個版本）
因為趕上市或趕廠商需求的東西，是不太可能隨你高興改寫就改版的。 XD
但如果這個軟體開發的原因？是為了論文內類似有training機制的東西？
因為一般來講，有training機制的軟體，要跑的時間會長得很嚇人的，
如果寫這個程式的原因，只是想要得到結果，附加一項需求，
更希望training時間縮短的話，
那寫兩種不同架構、但相同功能的程式好像也沒不可的，
（但重點是在於寫的人，反正要等training的data出來，閒著也是閒著，不如寫的情況）
因為花在寫第二種架構程式的時間，搞不好真的會值得，
（這是基於如果可以改善其中一小次的training time，
對最後的training time就會聚沙成塔，產生大效果）
這種情況，應該有時候也是發生在自己不確定哪個架構會比較好吧，
所以才會選擇寫兩種，否則應用在training的情況，
通常會比較希望寫可以增進效率最多的那種（假設沒人在趕你時間），
畢竟等待training結果和再度調整參數、再train，是一項很累人又大量浪費時間的事。
只是既然兩種都寫了，在自己比較兩者效率後，應該最終還是只會跑其中一種程式吧，
效率不佳的架構自然就會被淘汰了，
是不太可能會發生花1hr5min去得1.5hr效果的情況。
最後再論，在實務上，
我覺得很少人有辦法在開發前，就估計出準確的軟體開發時間和未來效益的，
這跟人的專案經驗、過去相關專案經驗都有關，
一次性的軟體開發的話（我是指過去沒開發過、未來也不太可能開發類似的），
通常不確定性只會更大的。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.187.12.44