bat*_*tta 8 language-agnostic refactoring shipping
在大多数出货日期由业务需求决定的世界中,程序员通常会提供有效的代码.通常,当您知道代码工作时,发布的代码的结构和效率都没有实际意义.除非指定了生产质量(例如api到算法),否则对于运行到几百行的代码,可交付代码等于有效的代码.
我的问题是:给一个功能的ETA,你会编码直到功能工作并完成吗？或者你会让它尽快工作并重构发布质量？
我倾向于后者虽然听起来更像是工作.当拆开的作品码算法的效率和模式,它是把他们放在一起欢乐体验.此外,它得到所有非功能性的爱 - 更少的错误,高性能,可扩展的,安全的.我不认为我很擅长写最好的代码第一次.所以这种方法适合我.
我想知道哪一个更受欢迎,为什么？我不是在寻找全行业的做法,只是个别的倾向,所以我可以衡量的思想相似.
我更喜欢在发货之前和之后进行重构.
推迟任何重构直到发布后听起来非常像你可能永远不会真正去做(通常情况下,会出现更具商业关键性的东西).但即使你在发货之前这样做,也不是说你的代码是完美的,而且你的东西也没有改进.所以之后也是(只要代码保持到任何程度).
对我来说,将代码重构为更简单,更清晰的代码是任何软件开发工作的持续和自然的一部分.
编辑:显然,在决定在给定时刻重构多少和多长时间时,您需要考虑业务约束.
编辑2:关于"如何让我的经理说服重构"这个问题(参见评论),这里有一些可能有用的资源: