很多的时候，我们一直在讲写代码最先讲的是把功能实现，然后再是优化等等问题。在一个人编写代码的时候这是可以的，但是在一个实际的项目中，这往往是会带来问题。

一、项目的需求变更迫使你改变原有的设计

在项目开发的中期，已经完成了系分设计，编码也进行到一半的时候，需求方提出需求变更。虽然可以拒绝接受需求的变更，但是由于功能点的重要性，接受了变更。但是面临的问题就是还有半个月，项目就有上线，为了能够在规定的时间内完成项目，并且实现变更的需求，我们采取的方案是尽量不改动原有的设计，以最小的代价来实现新的需求。最后我们的项目是按期完成了，满足需求方的第一期需求，但是我们付出的代价就是改变了我们原有的设计，使得设计变得丑陋了。

二、项目的deadline使得你不得不提交丑陋的实现代码

设计变得不完美的时候，实现的代码就会有bad smell了，但是项目的deadline就在眼前，你只得提交你不甚满意的代码，虽然这些代码已经实现了最初的功能。也许你会觉得，将来我再重构这些代码好了，但事实上，这几乎成了很困难的一件事情。首先、你改了代码就意味着测试那边需要进行一次回归测试，人力上的投入不是我们能说得算的，得boss同意。其次，你真的敢改已经运行的很正常的代码吗？没有良好的单元测试配套，没有良好的设计上的重构，想要对代码进行重构，那几乎是不可能的事情。

三、项目的二期、三期会让代码的bad smell越来越多

既然你没有办法去消除一期项目的bad smell，那么在二期、三期的时候，你的设计和变更不得不基于原有的丑陋的代码，那就出现了bad smell蔓延的情况，最后代码也就变得很难维护了。

以后还是要对自己写得每一个类，每一个方法都写好相应的tese case！