你永远都不知道成年人的崩溃往往只在一瞬间！！！！
有的人会说我不过就是动了一点点，为什么会翻车，往往自己的一点点想法，都有可能成为压死骆驼的最后一根稻草。
针对祖传代码，我总结一下我的人生感悟，就是四个大字：
=================================================================
作为一个经历过几次祖传代码的过来人的建议。
相信大家都听说过这么一句话。十年程序员血与泪，千万别重构代码!
别把重构的路想得太容易走了，因为，重构可以出乎你意料地简单，也可以出乎你意料地复杂
对屎山为什么不重构？
比较年轻的程序员往往会有重构屎山的冲动，这种想把代码写好的意愿是极好的。但是重构并非只是把烂代码删掉后简单的再写一遍。如果在重构之前没有深思熟虑，再写一遍的代码不见得会比“屎山”更好。要不要重构
第二条：代码精简祖传代码有很多没用的代码，全是前辈们在走成仙路的时候留下来的坑
你可以把它们全删掉，有的时候能起到优化祖传代码的目地的，这是最简单直接的优化手段，简单干脆直接暴力，可能会提高后期代码的编译速度。
作为一个程序员，你应该感谢屎山代码，以及大公司必然屎山代码的工程本质。
如果代码工程跟造桥打灰一样是可以用工具集约化规模化，
用仪器保证精确性，从而保质保量的……缝缝补补又一年。如果不想再努力内卷，这么做那么可以长长久久的在公司过下去。
其实这个很好办，开启慢查询，找到查询慢的地方，做减法，如果是多联表的查询，进行数据冗余，减少查询量。检查索引（既然是祖传屎山了，我就不相信数据库索引就一定会建得很完美），重写SQL语句。这种改法非常实用，从源头解决慢的问题。比如你一个页面祖传代码有100句SQL查询，你优化了一下，变成50句，速度能不上去？可比改代码方便多了。或是你加一个索引，原来一句SQL要查20秒的，现在就变成5秒了，真的是不要投入的买卖。
第五条：第五条是从内部改良，或者是从外部改良。
狗屎山都是一点点堆积的，没有code review的公司格外容易，不说这种杜绝方案，新人无论如何不要留下这样的代码，自己写自己注释了留下还提交到协作平台，没那么金贵，提上去等队友围观吗
所以避无可避，总会碰到需要重构代码的时候。只是尽量写得好懂些，写好测试，这样重构代码的时候不会特别痛苦。千万要写注释之类的，一个好的习惯会拯救许许多多的可怜人。比如我，已经在跑路的边缘了。
就算你写代码的时候觉得自己是神一样不可能出问题，过了几个月一看还是会觉得屎一样。
以前我一直想写一个逻辑分明，没有多余代码的项目。
第一天：产品经理把项目给我了，然后说一个月之后要上线，一般，呵呵，小意思
第二天：产品说要小小的改动一下，嗯嗯，没问题，小意思
第三天：产品说，要加一个功能，嗯呐，妹儿难题，小意思
第四天：产品说，这个功能需要这么改一下，嗯？
有点难度啊，但是还是可以改的，产品没说要延期上线。
第五天：这里，还有这里，还有这里这里都需要改一下，我一看代码，头疼了，但是还是上手去改了。…
最后
手去改了。…
最后
[外链图片转存中…(img-UtZ7b7DR-1714283530997)]
[外链图片转存中…(img-s8epgvBP-1714283530998)]
[外链图片转存中…(img-IrAeS9lO-1714283530998)]
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
