我看到过很多离谱的现象。比如:
我知道他们接手了一个烂摊子。
我能理解他们在维护这个烂摊子时表现出的愤怒、咒骂和无奈,但我不明白为什么他们要强调“接手之前就这么烂”,为什么这个烂摊子没有变好的迹象?
烂摊子可能来源于一个或者多个目光短浅不够专业的同事或者前同事,就如我在《速度与质量》中写到的那样,他们走了捷径,牺牲了质量。
但是,接手这个烂摊子的你,是可以有不同选择的。
是鄙视前面所有人,然后搞一下试一下,用尽可能省事的步骤搞定,将烂摊子搞的更烂一点?
还是
正视烂摊子,去重构、去微调整,让烂摊子一点一点变好,直到脱胎换骨,更容易的面对变更?
你应该有所追求,毫不犹豫的选择后者,你应该立即着手改进烂摊子。
我们都希望维护的代码是清晰的、可测的、高质量的,但这要依赖于前人栽树。
那么什么时候是种树的最好时机1?
春天?秋天?
都不是。
种树的最好时机是在 10 年以前,这样你现在就可以在树下乘凉。
看看周围,很明显,你错过了这个时机。
那么,什么时候是种树第二好的时机?
今天,现在!
摘自《测试驱动的嵌入式 C 语言开发》 ↩︎