日本排放的核污水就像软件项目迭代中的技术债

日本最终还是排放了核污水

2023年8月24日，日本最后还是排放了核污水。网上的讨论很多，有说不应该排放的，也有说污染其实不严重，不需要担心的。首先说明，我是反对排放的。不是因为核污水超标，即使没有超标，我也不认为应该排放到海里。

为什么呢，因为这些辐射元素排放到海水中后，会通过食物链富集效应，最终大量的集中到人类身上。即使排放时的指标是安全的，最终，辐射污染富集到人体身上后，迟早要超标的。

关于日本排放核污水的事，我觉得和软件开发过程中的技术债很像。所以今天就蹭个热点，聊一聊项目中的技术债。

软件项目的迭代过程

我记得大学的时候，课本上学的软件迭代还是瀑布流的迭代方式。这个就比较简单，提出一个大项目，然后细化各个功能。架构师拿到十分完善的需求文档后，开始架构设计。然后开发，测试，上线，验收，完成整个项目。在这个过程中，需求是明确的，按照需求去实现就行。

可是后来出现了敏捷开发。老板们一看，这个好呀，敏捷开发，不就是快速开发吗，大大提高开发速度。尤其是互联网公司，讲究的就是一个唯快不破。然后，，，很明显就感觉到，项目中的技术债越来越多了。

原先项目需求明确后，即使开发过程中有需求变化，也都是在代码上线前修改，可以把看到的不合理代码设计给改掉，影响可控。敏捷后，项目需求是逐步迭代上线的，有时候需求间是相互影响的，再加上互联网的人员换的也勤快，需求时间也短，这前后的代码越来越不融洽。

技术债的积累

技术债是怎么积累的呢，其实是项目过程中，为了短期的收益(上线时间)而做出的技术上的妥协(怎么快怎么来)，这些妥协可能会在未来导致更多的工作，或者可能的线上问题。可以看出，技术债务并不总是坏事。有时，为了满足紧迫的市场需求或截止日期，团队可能需要做出一些妥协。关键是要意识到这些妥协，并在适当的时候偿还这些债务。如果需求上线了，就不管对应的技术债了，这个技术债可不就是越来越多吗。

就像文章最开始的日本排放核污水。从当年日本核电站地震出事，日本采用了注水冷却并储存核污水的方案，我们就能意识到，这个核污水一定要处理掉的，不然越堆越多，最后就只能排放出来的。10几年了，日本就没想过要解决核污水，现在说要排放，我觉得吧，这个估计是10几年前就确定的方案了，只是没有往外说，最后就看什么时间排放。最后，我们就这样又一次见证了历史。

重构

技术债不断积累后，会导致新需求越做越慢，bug还多。这个时候，老板就会觉得做这个需求的人不行，做的又慢，bug又多。但是只有做需求的人才知道，真的改不动呀。

所以，当你做一个需求，感觉改不动，或者明明没有改多少代码，但是bug特别多。 那么一定要想一想这个项目是不是存在了很长时间了。如果存在了很长时间了，那么大概率需要解决技术债的时候到了。怎么解决，重构！！

怎么重构，这个话题很大，一两句说不清楚。不过，一旦你成功重构了一个老项目，那么大概率你的技术水平能有一大步的提升。

就像有人说的，一个文明的衰退等于一个新的文明的诞生。