昨天测试提了个需求更改意见，我简单的了解了下，就答应了，以为是很简单的功能，结果发现改起来花了半天多时间，这是在预料之外，要是早知道要花这么长时间，我就不会答应改了。
以后的需求更改意见，自己要充分的评估工作量，主要是看要改的地方是不是操作和功能的集中区域，如果是这种地方的更改，往往会涉及到大量代码的改动，就比如这一次的，要修改主页输入和输出的切换方式，本来主页就是显示的核心区域，代码量是比较多的，而且修改前和修改后的逻辑是有大不同的，所以这种修改是有很大的工作量的，因此要充分评估了工作量之后再决定要不要改，不能想当然。
再一个，有一些需求，能不改的就不要改，能少改的就少改，尽量不要去做大的改动，尤其是功能逻辑完全改变了的，自己也不要想当然觉得很容易，因为光靠前期的评估，有时也不是能很准确的预估耗时，所以说，能少改的就要少改，除非是领导下任务，否则一切从简。
费力不讨好的事情，尽量少做。
