入职的第四个月，我写下了这篇日志，记录一些开发中的思考，简称瞎几把想。
关于敏捷开发、快速迭代
上一周的开发中，一个Tag机制的不明确性，导致了同事在开发中付出了大量的时间和精力，用于解决非技术性的问题。在我看来，这个机制本来应该是一个非0即1的定义方式，但却做了数学意义上的排列组合，简单复杂化。
稍微了解一下原因，大概是因为早期没有给所谓的Tag以明确的定义，导致不同的人用了自己的方式去定义它。
而后，在后续的迭代开发中，不知是为了减少工作量还是其他原因，对这个Tag机制赋以明确的使用方式之后，没有对之前遗留的数据问题做相应的处理，而是让研发在业务逻辑上对其进行兼容。
这在早期业务逻辑较简单的时候，确实是最方便的做法，可能也是成本最低的做法，还能美名其曰快速迭代、敏捷开发。
但我大致翻阅了大学时代的敏捷开发教科书，猜想是某些人对敏捷开发有什么误解。敏捷开发的最初意愿，应该是快速地完成一个产品的原型之后，在后续的迭代中不断地去完善、优化它，而不是对早期遗留的错误加以忽视，为了简单方便而使用不正确的处理方式。
忽视遗留问题而进行新的迭代，一个早期不算严重的错误，是不是也会在一轮轮的产品迭代中进行自身的错误迭代呢？
个人感受很明显，该项目才刚刚一脚踏入中期，而我们仅仅为了给这个项目做一点额外技术支持，就因为前期积累的一些问题而碰壁累累。经常听到有些大项目，在进行到一定时间之后，就不得不进行一次大规模的重构。
重构可能是不可避免的，因为随着技术的更新，总有些东西是需要舍弃的。
我的问题是，在这些重构中，有多少是因为技术的原因而推动的项目大规模重构？
而那些因为早期的问题不及时纠正，对产品迭代的同时也对错误进行迭代，错误的雪球越滚越大，这样的原因引发的项目重构是不是更多呢？
敏捷开发不应该是忽视问题的借口才对吧？
