标签：状态 思路 市场 计算机 引擎 独立 慢慢 测试的 odi
在这篇blog中，我将记录和描述我阅读计算机软件行业经典书籍《重构》过程中的思路和阅读后的总结。整体而言，阅读《重构》是一个美好的过程，但是，可能个人期望过高，导致我觉得这本书有些盛名之下其实难副。下面的文章中，将从三个角度进行描述，分别是
在我们编写大型项目的过程中，由于市场压力，deadline的存在，作为程序员经常听到的一句话是：我不在乎你是怎么弄的，告诉我什么时候可以搞定。作为boss和市场侧，这句话是完全没有问题的。但是，作为一个程序员，这样的语言很可能造成一个恶性循环，我们不妨称之为”老板循环“。紧张的时间，导致架构设计和测试设计不足，从而导致虽然前期功能实现快，但项目和产品质量欠佳。而到了项目的后期，项目进度和产品质量都成了项目瓶颈。新功能难以加入到现有的架构。加入的新功能测试不足，导致大量的时间和人力投入到了debug中。《重构》这本书，则是通过简单的例子，向我们一步步的展示，如何可以跳出这样的”老板循环“。
当”老板循环“出现的时候，所有的人都会十分痛苦。对底层程序员来说，功能难以完善，项目质量差，debug时间多而无聊。对PM来说，项目进度和功能要求与程序员的工作时间成了严重的冲突方，程序员十分痛苦，但是项目进度严重落后，新功能无法交付客户。对老板和客户来说，项目进度差和项目质量糟糕，会逐渐消磨投资人与客户的耐心，从而转向其他团队或者公司的产品。
可能有人说了，既然这么痛苦，我们是不是应该重新设计，重构我们的项目，从根本上解决我们的问题？答案似乎是显而易见的，我们需要”重构“。可是，摆在我们面前的问题是，老板、投资人、客户的deadline不会向后延期，毕竟，他们可不管程序员们具体是怎么解决问题的。针对这样的问题，作者提出来的思路是：
《重构》的行文架构较为程序员化。整个第一章节，作者举了一个戏剧团收入计算的程序作为例子，向我们一步步展示了如何将一个长函数进行抽象拆分，最后变成互相独立的模块，从而友好的增加一个新功能的过程。在读的过程中，我们完全可以跟着作者的思路同时进行编码和修改。这个例子基本展示出了作者的思路。第二章中，承接第一章，作者介绍了重构的原则，包括了什么是重构，为什么重构，如何进行重构等。第三章节中，作者展开描述了什么时候需要重构这个问题，非常具体的说明了很多”代码中的坏味道“。第四章节中，则是阐述了我们测试的价值以及如何进行测试。后续章节则是逐个说明了如何进行重构。
在我看来，阅读了前四章节就能明白作者的核心思想，了解什么是重构，什么时候需要重构，当我们真正开始重构的时候，完全可以像查字典一样，参考后续的重构手法。
如同文本中”核心思想“那部分的描述，我也是”老板循环“中的一员。在团队中，我体验过的角色包括了：普通开发者，模块负责人，项目经理（PM）。当我是一名开发人员的时候，我每天都在de不是我写的bug。无穷无尽的bug掩埋住了我，以至于对coding产生了负面的厌恶情绪。当我是一个模块负责人，我仍然没能逃离循环，大部分时间我在尝试进行bug的预定位，之后分配给小组的成员。这样的过程持续时间长了，慢慢的对技术角色都产生了厌恶。而当我逃离技术岗位，成了一名年轻的项目经理，我发现，我仍然在循环中，只不过换了一个角色。每天都生活在程序员说的不可能和老板说的必须之间。项目进度落后同时质量欠佳。所以，我渐渐开始思考问题到底出在了哪里。从搜索引擎和博客中，我发现了《重构》这本经典书籍。虽然不能说这本书让我跳出了循环，但我至少学到了一些基础知识点，在以后如果我再回到技术岗位，我觉得我可以试试能不能跳出循环。从一个更高的角度去解决困扰的问题。
具体来说，我从书籍中学到的关键点包括：
作者的行文思路非常的清晰，甚至有些公式化。无论是大的文章，还是小的章节，基本都遵循：举例，是什么，为什么，怎么做的四段轮逻辑。只需要按照作者的思路，逐段阅读即可。当然了，针对代码示例，自己照着来一遍肯定效果更佳。
标签：状态 思路 市场 计算机 引擎 独立 慢慢 测试的 odi
原文地址：https://www.cnblogs.com/liwbeijing/p/12283808.html
