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