上周在食堂吃饭，遇到同事聊起最近的系统重构，她说这一批的新员工不如13年的一批，就一个看似简单的问题也是折腾很久，重构的周期越拉越长。我作为这次的重构的特性SE，可以说也是硬着头皮上。我是越来越反感重构，尤其是涉及到多个模块的重构。在新年的聚餐上，我说我给你挖了坑，你来填坑，让我感到非常惭愧的，即又不得做这些事。
在现阶段项目交付变得越来越难，一方面我们面对众多的需求，做还是不做并不是你能轻易决定的；而另一方面我们又想从架构上解决可以快速满足需求。但本质的是这几个月内，人的技能与意识没有根本性的变化。在大家没有主人翁的精神下，说来说去也是为了需求在垒代码。即使你想从代码结构上重新设计，让系统更松的耦合性，更好的扩展性。受于项目进度冲击，以及代码实现者的被动，最终也会变得让你不想回头多看一眼。
编程如果仅仅越考虑短期实现项目需求目的肯定是不好的，但想通过强制的管理手段，或重构手段来想延长它的生命周期也并一定能行得通。当同一份代码是多人开发与维护，并在领导眼中的谁有时间谁就上的话。本意可能是想通过多人的备份，或共同完成以期缩短工期。其实这种做法无疑更是加重了代码朝腐化之路上走的趋势。
重构有很多的手法或方法理论，其核心都会有提到不改变软件的外部行为，是对软件内部结构进行修改与调整。这实际上是非常难以做到的，我们是如何去评估不改变软件的外部行为，充分的测试能保证吗？显然就我们目前的测试能力来看，这简单是非常美好的梦想。尤其是具有一些年头的代码，或者又是人员变化较频繁的代码，看上去并不清爽的代码，至少还能正常的工作，一旦重构不知会丢失多少其中通过各种手段修改出来的小功能点。
今天的软件交付，可能说由于整体的需求是具有多变性，给软件开发带来不确认性。不确定就会产生怀疑和恐惧，我们经常会说，软件架构是要架构未来，不是解决当下问题。当不确定性还不算太多的时候，我们还在架构层面上来推演，整个软件系统的大致方向可以被预测，然后在此基础上不断地演化。而当不确定性实在太多的时候，对软件的要求就变成了可丢弃。换句话说，你开发的所有软件，从一开始，你就应该做好很快被丢弃的准备。
采用开源：尤其是Github让开源的推广与使用变得越来越简单，开源软件在商用软件领域成为了越来越主流。即使你开发的是非常重要的商用软件也不需要自己从头开始，自己实现并一定比开源实现的好。
平台框架：平台软件的目的是让通用的能力重用与沉淀。业务领域更倾向于采用面向领域的DSL描述简化开发，代码量要求是越来越少。目前各种基础框架越来越成熟，基于基础构架上构建，可以在最短时间内以最少代码量做出一个符合要求的软件。并且业务层不需要过多的设计，因为大部分设计已经蕴含在框架内。
职责单一：可以把系统拆多功能单一的服务，符合单一职责原则，做且仅做一件事。这样代码量就不会太多，也不需要频繁地添加新的功能，变化少就不不会导致不稳定，所以这样代码烂也烂不到哪里去。另一方面功能单一，在其上的工作团队成员也会很少，四五个人能搞定的代码，它的也不会因为多人的经手变得不可维护。
在面对需要快速迭代交付的项目下，软件开发变得越来越轻量化下。尤其是在微服务架构下，软件开发其实可以不需要重构，该烂的就让它烂掉。对于单个微服务或单个小的模块内的代码重构意义也变得越来越小。如果这个微服务真的到了无法满足需求情况下，那没有必要对它进行重构，重写一个就行了。所以在这样的情况下“重构已死”，其实又是系统中另外一种“重生”，就像人的身体一样，做换只手的手术可能影响非常地大，如果只是细胞不断地死去，新的又产生替换，你是感觉不到有什么影响。
