有许多不同的不良做法,例如内存泄漏,很容易在事故中进入程序.有时候,他们甚至可以将您的计划一起评审.
我正在研究一个项目,如果我故意在我的代码中放入内存泄漏,它就可以工作了.如果我把漏出,代码崩溃了.显然这很糟糕,需要很快(并将会)修复.
我的问题是,你什么时候决定在这种状态下交付代码,如果没有这些糟糕的做法就不可能及时发布代码？
如果问题对系统实际使用的影响可以合理地预期为无或可忽略不计,并且交付日期不能被推迟,并且可以在问题的影响变得可以忽略不计的时间范围内修复,则运送它.
显然这不是理想的甚至是推荐的,但是你现在明显被推到了一个角落.有时候没有好的选择,但实用主义必须胜过正式的正确性.如果应用程序有内存泄漏,但我们可以合理地预期应用程序将被回收或重新启动机器或在泄漏成为真正问题之前的任何事情,这有时可能比迟到更好.这取决于协议的条件和客户.
最好至少尝试推迟交货日期,但我假设你已经尝试过,这不是一个选择.
一旦申请被发运以忽略技术债务并继续前进,这是典型的.开发商有责任向利益相关者清楚地告知偿还部分债务的重要性,特别是在这种情况下.
然而,鉴于客户似乎更关心交货日期而不是正确性,因此一旦您上线,任何人都不太可能会相信偿还任何债务.这是一个糟糕的情况.只有拥有所有事实的人才能做出正确的选择.
"我的问题是,你什么时候决定在这种状态下交付代码,如果没有这些不良做法就不可能及时发布代码？"
决不.
你做了什么:优先考虑和集中精力.
如果您正在进行的工作确实是高优先级的,并且您错误地设计了它,则必须牺牲一些低优先级的东西.通常,某些功能必须延迟,以便您有时间专注于无效的高优先级功能.
如果你正在做的工作真的是低优先级,你必须问为什么你没有在更高优先级的事情上工作.而你仍然需要关注并优先考虑.有时必须牺牲优先级非常低的东西.
当你不能做"一切"你必须选择你可以做的事情,这将是合理的无错误.
| 归档时间： |
|
| 查看次数： |
329 次 |
| 最近记录： |