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