博客推行版本更新，成果積累制度，已經寫過的博客還會再次更新，不斷地琢磨，高質量高數量都是要追求的，工匠精神是學習必不可少的精神。因此，大家有何建議歡迎在評論區踴躍發言，你們的支持是我最大的動力，你們敢投，我就敢肝 ...
什么是重构
重构是指在不改变代码行为的前提下，重写代码，使其更加简洁，易于服用
这是核心技能，并且经常我们在自己没有意识到的情况下使用
什么是软件架构
就像生物一样，软件系统通常由很多较小的部件组成，每个部件擅长做一件事。将这些部件组合起来，一起工作，可形成更大的软件系统。术语软件架构用来描述软件项目的各个不同部件之间的组合方式。
笔者的理解就是软件架构就是在拼装高达
优秀架构是可预测的
软件架构可预测是指可以对软件的工作方式和结构做出准确的假设。可预测性表明预先的规划是合理的，并有助于节省开发时间，因为可以避免下列问题：
- 组件的功能是什么
- 某一段代码在何处
- 新代码加到何处
在可预测的架构中，人们可以做出精确的假设，不熟悉代码的开发人员也能够更快地理解该架构。
优秀架构可提升代码复用性
代码复用是指在多处使用同一代码而无需重写。代码复用优势明显，不用重写已有代码，可以加快开发速度。同理，解决某一问题所需的代码越少，维护所有用该代码实现的功能
所需的时间就越少。
优秀架构可扩展
跟可扩展性非常类似，可维护性对于架构也很重要。对于可维护的优秀架构，修改其现有功能很容易。随着时间的推进，需求也许会发生变化。迫于需求变动的压力，你将修改代
码。可维护性软件是指你修改一处代码时，没必要大规模改动其他代码。
软件架构和重构
重构有助于维护和提升软件架构。
重构就是指调整代码结构、使其更具意义的一套技术。重构可使代码可预测、可复用、可扩展和可维护。
当你的软件架构具备了上述特点时，它对目标用户而言将更可靠，你在其上继续开发也会更加愉快！
需要重构的原因
- 需求变更
- 架构设计不合理
- 低估困难
- 忽视最佳实践
什么情况下应该重构代码
结合代码的上下文重构代码会更加容易。
因此，如果你修复的 bug 或开发的新功能用到了已有代码，重构是最好的选择。
处理小任务时顺便重构代码，不至于把一切搞乱，他人若修改你重构过的代码也能从中受益。
不断坚持重构代码，代码质量将达到卓越，前提是你的改动符合优秀架构的特点。
然而，有时你会遇到一段有很多依赖的代码，也许需要决定是否对其重构。
重构有很多依赖的代码，就像抽衣服上的线：抽得越多，散开得越多。
类似地，对于具有很多依赖的代码，你改动得越多，需要更新的依赖就越多。
遇到这种情况，如果时间很紧，先把工作完成也许更适合，然后再匀出些时间，回头审视并重构代码。
然而，如果开发过程中重构某些小功能不至于严重影响到开发计划，你也许可以考虑及时重构它们。
什么情况下不应该重构代码
知道什么情况下不应该重构，甚至比知道什么情况下应该重构更为重要。
重构名声不太好，因为有时看起来软件开发人员只是为了重写而重写。
代码也许是别人写的，没必要重构，但患有“不是我写的症”的开发人员一定要对其重构，因为他们认为不是自己写的代码就不是好代码。
或者，有一天开发人员心血来潮，不再喜欢之前的代码编写方法（也许之前类名使用下划线而不是连字符，现在想改过来），因此他们钻入重构的兔子洞以求止痒。
很多情况下，这些工作被视为“磨洋工”，它让人们感觉效率很高，事实上并非如此。
在黑夜里梦想着光，心中覆盖悲伤，在悲伤里忍受孤独，空守一丝温暖。 我的泪水是无底深海，对你的爱已无言，相信无尽的力量，那是真爱永在。 我的信仰是无底深海，澎湃着心中火焰，燃烧无尽的力量，那是忠诚永在
