日本终究仍是排放了核污水
2023年8月24日，日本最终仍是排放了核污水。网上的评论很多，有说不应该排放的，也有说污染其实不严峻，不需求忧虑的。首要阐明，我是反对排放的。不是由于核污水超支，即便没有超支，我也不认为应该排放到海里。
为什么呢，由于这些辐射元素排放到海水中后，会经过食物链富集效应，终究很多的集中到人类身上。即便排放时的指标是安全的，终究，辐射污染富集到人体身上后，早晚要超支的。
关于日本排放核污水的事，我觉得和软件开发进程中的技能债很像。所以今天就蹭个热点，聊一聊项目中的技能债。
软件项目的迭代进程
我记住大学的时分，课本上学的软件迭代仍是瀑布流的迭代方法。这个就比较简单，提出一个大项目，然后细化各个功用。架构师拿到非常完善的需求文档后，开端架构规划。然后开发，测验，上线，验收，完结整个项目。在这个进程中，需求是明确的，按照需求去完成就行。
可是后来出现了敏捷开发。老板们一看，这个好呀，敏捷开发，不便是快速开发吗，大大提高开发速度。尤其是互联网公司，考究的便是一个唯快不破。然后，，，很明显就感觉到，项目中的技能债越来越多了。
原先项目需求明确后，即便开发进程中有需求改变，也都是在代码上线前修正，能够把看到的不合理代码规划给改掉，影响可控。敏捷后，项目需求是逐步迭代上线的，有时分需求间是相互影响的，再加上互联网的人员换的也勤快，需求时刻也短，这前后的代码越来越不和谐。
技能债的堆集
技能债是怎样堆集的呢，其实是项目进程中，为了短期的收益(上线时刻)而做出的技能上的退让(怎样快怎样来)，这些退让或许会在未来导致更多的工作，或许或许的线上问题。能够看出，技能债务并不总是坏事。有时，为了满足急迫的市场需求或截止日期，团队或许需求做出一些退让。关键是要意识到这些退让，并在适当的时分归还这些债务。假如需求上线了，就不管对应的技能债了，这个技能债可不便是越来越多吗。
就像文章最开端的日本排放核污水。从当年日本核电站地震出事，日本采用了注水冷却并储存核污水的计划，我们就能意识到，这个核污水一定要处理掉的，不然越堆越多，最终就只能排放出来的。10几年了，日本就没想过要解决核污水，现在说要排放，我觉得吧，这个估量是10几年前就确认的计划了，仅仅没有往外说，最终就看什么时刻排放。最终，我们就这样又一次见证了历史。
重构
技能债不断堆集后，会导致新需求越做越慢，bug还多。这个时分，老板就会觉得做这个需求的人不可，做的又慢，bug又多。可是只要做需求的人才知道，真的改不动呀。
所以，当你做一个需求，感觉改不动，或许明明没有改多少代码，可是bug特别多。 那么一定要想一想这个项目是不是存在了很长时刻了。假如存在了很长时刻了，那么大概率需求解决技能债的时分到了。怎样解决，重构！！
怎样重构，这个话题很大，一两句说不清楚。不过，一旦你成功重构了一个老项目，那么大概率你的技能水平能有一大步的提升。
就像有人说的，一个文明的阑珊等于一个新的文明的诞生。
扯一句
最近新弄了一个公粽号：写代码的浩，求个重视。
后面会逐步把掌握的前端常识以及职场常识沉积下来。 假如还有什么疑问或许建议，能够多多交流，原创文章，文笔有限，孤陋寡闻，文中若有不正之处，万望告知。
