[重构心得] 接一个烂Project怎么办
在软件行业对于做项目的公司来说，接手一个别人做的project（通常你会认为很烂）是很正常的，本篇文章简单的谈一谈接手project（以.NET，JAVA为例）的几点心得。
当你接手一个project时，目的只有一个，如何使它变得可控。
1. 理解所有功能点，并知道如何测试每一个功能点（使用工具如Postman），对于没有单元测试的project来说，需要手动测试。
2. 阅读代码。在阅读过程中，可以用resharper这样的重构工具来正确的命名变量，函数等等。
3. 如果代码是过程式设计，需要使用抽象代替过程。需要使用抽象手段（抽象类和接口为出发点）对业务逻辑部分建模。找出可封装部分，考虑使用流畅接口等技术进行封装。
4. 如果代码烂到直接把SQL写在了C#或JAVA里，或者上百个存储过程。这时就要用ORM重写（我接到了不止一个这样的project）。另外，我个人的观点，任何逻辑都不应该放在数据库里（存储过程，数据库函数，触发器等等）。
5. 如果需要的话，对表示层（Presentation）重构，MVC，MVP都可以，看团队的技术偏好。
6. 依赖注入（DI）。重构差不多了就要可测试性了。确保整个project的核心功能都是可测试的，考虑使用xunit，nunit这样的框架来写测试。
7. 系统健壮性。对web服务层定义一套的错误码（如200-299表示正常，300-399客户端错误，400-499身份验证错误，500-599服务器错误等等）。log信息：多加入系统业务的描述，而不是每次都把整个Exception的stacktrace放进去就完了。
以上步骤做完，项目的代码逻辑，测试以及错误追踪方面基本都可控了。当然，在一些糟糕的情况下重构难度会更高，例如project功能还没做完，还在赶还在改，还需要给客户展示。这时
1.继续现有的project，切勿一次重构太多，每改一点做一轮测试。
2.考虑创建一个新的（可以理解为重做）项目。一个是rush版本，一个是clean的。
当你接手一个project时，目的只有一个，如何使它变得可控。
1. 理解所有功能点，并知道如何测试每一个功能点（使用工具如Postman），对于没有单元测试的project来说，需要手动测试。
2. 阅读代码。在阅读过程中，可以用resharper这样的重构工具来正确的命名变量，函数等等。
3. 如果代码是过程式设计，需要使用抽象代替过程。需要使用抽象手段（抽象类和接口为出发点）对业务逻辑部分建模。找出可封装部分，考虑使用流畅接口等技术进行封装。
4. 如果代码烂到直接把SQL写在了C#或JAVA里，或者上百个存储过程。这时就要用ORM重写（我接到了不止一个这样的project）。另外，我个人的观点，任何逻辑都不应该放在数据库里（存储过程，数据库函数，触发器等等）。
5. 如果需要的话，对表示层（Presentation）重构，MVC，MVP都可以，看团队的技术偏好。
6. 依赖注入（DI）。重构差不多了就要可测试性了。确保整个project的核心功能都是可测试的，考虑使用xunit，nunit这样的框架来写测试。
7. 系统健壮性。对web服务层定义一套的错误码（如200-299表示正常，300-399客户端错误，400-499身份验证错误，500-599服务器错误等等）。log信息：多加入系统业务的描述，而不是每次都把整个Exception的stacktrace放进去就完了。
以上步骤做完，项目的代码逻辑，测试以及错误追踪方面基本都可控了。当然，在一些糟糕的情况下重构难度会更高，例如project功能还没做完，还在赶还在改，还需要给客户展示。这时
1.继续现有的project，切勿一次重构太多，每改一点做一轮测试。
2.考虑创建一个新的（可以理解为重做）项目。一个是rush版本，一个是clean的。