为什么题目中的“重构师”三个字加上了引号呢？因为在大多数的团队中，并没有提供这个一个岗位名称。重构在编码过程中，无时无刻的发生着。每一个程序员都是重构师。今天来聊聊在敏捷开发中我们常用的重构思想。
理念：重构本身是没有价值的，重构本身是为了服务业务。
敏捷开发的特点是，高速开发，在开发中，程序一直处于可使用的状态。高速开发，持续交付是敏捷中强调的。我们细品敏捷开发的定义，我们没有看到它告诉我们什么时候重构，甚至是要不要重构。
高速与重构其实并不矛盾，我认可设计一个框架会花费一定的研发时间。在高速开发中，要拿捏好“度”。既不能因一套框架设计，造成项目不能如期上线，也不能不加思考，想到哪写到哪。想到哪写到哪，第一期是高速了，可后面就不一定了。持续的高速产出，才是我们追求的。
这个“度”很难拿捏。我是做客户端开发的，来分享一些我在客户端开发中的经验。这里要引入我的“承压期”感念。什么是“承压期”呢？假设你设计了一个框架，版本的发布是一个月发一版，那么在不优化框架，只做需求开发的情况下，这个框架在三个月内，性能、可扩展性、程序员的开发速度都达到优秀指标。第四个月，因各种可能的问题，框架的扩展性下降，代码出现混乱的现象，甚至影响开发速度。那“3个月”说的就是承压期了。
一个框架的设计，承压期的时间设置，要参考一下几个因素，1.项目本期的开发周期。2.项目需求的发展，通过与PM聊，基本可以把掌握产品3-6个月内的需求走向。
在掌握以上两点，则可制定出承压期。在重构方案设计中，切记，不可过度设计。
第一优先级，要保证如期交付，重构是服务于业务的。有代码才能重构。
承压期具有延长的特性，随着在告诉迭代的过程中，开发者应优化代码，延长承压期。小部分的优化代码，不会影响开发速度，反而能提速。
理念：地铁模式（质量把控）
程序员在自己的岗位中，不单单充当着”产出者“的角色，还充当着”质检员“的身份。也是质量的把控着。在敏捷开发中，需求的变更，需求的插入是最常见的。插入需求，修改需求都是可以的，但是要控制度。项目需求容量就像地铁车厢的容量。在已经定好deadline的情况下，如果PM提出延迟发版，多插一些需求再发，我们应学会拒绝。地铁到时发车，乘客可以等下一趟。要严守发版的DeadLine防线。加大发版频率，给PM总有可预期下一班列车。
情怀：以同等的热情护卫代码
我们努力的完成工作，参与需求讨论，认真的制定执行方案，及时交付产品。但我们也层碰到以下的问题?
(1) 遇到过某种严重到要花费数天来做“本来只要数个小时"即可完成的混乱情况。
(2) 遇到本来只要做一行修改，结果却涉及到上百了模块的情况。
为什么好代码这么快就变质成糟糕的代码了？
这时候，我们会想到很多原因。
如：需求变化背离了原有的设计、时间太少，进度太紧张。
难道作为程序员的我们，就不应该付一点责任吗？
外部因素获得或少，算是诱因，但代码确实是我们自己写的。我们与项目规划脱不了关系，对失败富有极大的责任。特别是，失败与糟糕的代码有重要的关系时。
假如你是为医生，病人请求你在做手术之前别洗手，因为那会花费太多时间，你回照做吗？本该病人说了算，但是医生应该拒绝服从。为什么，因为医生比病人更了解疾病与感染的风险。如果听了病人的话，那就是一种不专业的态度。
同理，如果程序猿遵循不了解混乱风险的人的意见，或者懒于告知未来可能存在的风险，异或者程序能跑就行，不管以后。这也是不专业的做法。
在这个过程中，有可能会遇到"来源于个方向的"压力，每个岗位上的人，都有自己要维护的东西，而作为程序猿的我们，应以同等的热情护卫代码。
