We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
程序员最喜欢做的事情就是看旧代码不顺眼,特别是新人喜欢推翻重写。那么推翻到底有没有必要呢?
通常推翻重写是非常不明智的做法,并且经常会造成项目的失败与可用性的缺失。 原因如下: 1、旧代码的是可用的,新代码还无法证明可用 2、推翻重写导致逻辑关系无法吻合,虽然旧代码的逻辑可能存在问题。 4、推翻重写的时间通常会很长,并且不能保证推翻重写的代码一定会比原来的代码更好。 3、完全理解旧代码的业务逻辑需要时间 4、软件开发过程并不是一个确定的过程,中间存在很多变数,存在工程风险。 5、开发是一个消耗金钱与时间的过程,推翻项目重做也许可能会让一个企业直接倒闭。
所以推翻旧代码通常是一个错误的决定,那么正确的做法是什么呢?
Make it work, make it right, make it fast. -- Kent Beck
软件最根本的是要能运行,如果你的软件根本无法运行,再多的设计,架构都是扯蛋,是无根之木,无源之水。 当你的项目可以运行时,不要去破坏它。
如果这个项目可以运行,但是仍存在大量的问题时,我们要做的就是持续的改进项目。 一方面要不断的抽象化,模块化,即所谓的重构 另一方面要始终保存程序的可运行,即持续集成
任何自称的优良架构相比于代码的可运行都是欠重要的。
代码可运行的价值就相当于你是活着的。 而架构就是你的长相是不是好看。 所以活着重要,还是长的帅重要呢?
而软件开发是可以不断的改进的,就象人可以整容一样。 并且软件的改进是比整容要容易很多。
1、代码通常都是很丑陋的 2、通常开发者对于别人的代码都是无法赞赏的,类似于文人相轻 3、对自己过度的自信,总觉得自己的东西才是好的 4、理解原来代码的代价大。理解别人的代码的代价通常并不小,并且开发者通常会有:“如果这些代码最终会被推翻,我为什么要学习他呢?”这样的想法。
不要轻易的推翻一个可以运行的代码,持续集成对于大多数项目来讲是比较可行的解决方案。通过小部分替换的方式来重构与改进代码是一个良好的已经为实践所证明的策略。 关于旧代码,最后送给所有开发人员: 推翻有风险,重写需谨慎,改进可重构,运行必持续。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
程序员最喜欢做的事情就是看旧代码不顺眼,特别是新人喜欢推翻重写。那么推翻到底有没有必要呢?
推翻不应该被鼓励
通常推翻重写是非常不明智的做法,并且经常会造成项目的失败与可用性的缺失。
原因如下:
1、旧代码的是可用的,新代码还无法证明可用
2、推翻重写导致逻辑关系无法吻合,虽然旧代码的逻辑可能存在问题。
4、推翻重写的时间通常会很长,并且不能保证推翻重写的代码一定会比原来的代码更好。
3、完全理解旧代码的业务逻辑需要时间
4、软件开发过程并不是一个确定的过程,中间存在很多变数,存在工程风险。
5、开发是一个消耗金钱与时间的过程,推翻项目重做也许可能会让一个企业直接倒闭。
所以推翻旧代码通常是一个错误的决定,那么正确的做法是什么呢?
正确的做法
软件开发的最基本的原则
软件最根本的是要能运行,如果你的软件根本无法运行,再多的设计,架构都是扯蛋,是无根之木,无源之水。
当你的项目可以运行时,不要去破坏它。
持续的改进(持续集成)
如果这个项目可以运行,但是仍存在大量的问题时,我们要做的就是持续的改进项目。
一方面要不断的抽象化,模块化,即所谓的重构
另一方面要始终保存程序的可运行,即持续集成
可运行压到一切,架构与可用权衡
代码可运行的价值就相当于你是活着的。
而架构就是你的长相是不是好看。
所以活着重要,还是长的帅重要呢?
而软件开发是可以不断的改进的,就象人可以整容一样。
并且软件的改进是比整容要容易很多。
产生推翻重写冲动的原因
1、代码通常都是很丑陋的
2、通常开发者对于别人的代码都是无法赞赏的,类似于文人相轻
3、对自己过度的自信,总觉得自己的东西才是好的
4、理解原来代码的代价大。理解别人的代码的代价通常并不小,并且开发者通常会有:“如果这些代码最终会被推翻,我为什么要学习他呢?”这样的想法。
结论
不要轻易的推翻一个可以运行的代码,持续集成对于大多数项目来讲是比较可行的解决方案。通过小部分替换的方式来重构与改进代码是一个良好的已经为实践所证明的策略。
关于旧代码,最后送给所有开发人员:
推翻有风险,重写需谨慎,改进可重构,运行必持续。
The text was updated successfully, but these errors were encountered: