为什么新来的技术很难接手维护一个系统

为什么开发功能变得越来越慢?

 

某天来一个技术，他跟老板说：这个系统太臃肿了。很乱，我很难开展工作下去，至少很难按照我的经验和设想来实施。如果想让我顺利干下去，办法就是对系统进行重构一次(重构代码,或者开发新的系统替代原来系统)。

 

 

我们让项目变得可维护性有很多。对公司，对接手的技术，都是有利而无害的。

 

自己做的成果没法让下一任衔接。就像官员上任，任期满了后。这个烫手的山芋丢给下一任去解决。我这一任期内，维护稳定不出事情就可以。

 

片面追求gdp指标，就好像片面追求功能的完成，不管功能完成的质量。外行也没法评价功能完成的质量，他们只能说：这个功能达到我的预期了。就是质量好。

 

这就好比，gdp达到预期指标了。就是质量好。可是会忽略掉一些重要的东西。

 

 

我发现非常像系统一样：只要保证我在这公司干这段时间内，系统是稳定的，可以继续加功能完成上面的任务即可。至于定时炸弹什么时候爆发，只要不在我任期内爆发就可以了。

于是我在任期内，明明知道这里是一个坑，都懒得去做代码优化，做重构了。干嘛要浪费自己时间做这种事情。

 

 

 

为什么招聘经验丰富的技术投入和产出很值得。避免了很多坑，留给以后的技术债务。

 

我觉得，至少要招聘经验丰富的技术作为领头羊带领下面的人，有一个正面的能量。

 

俗话说，上梁不正下梁歪，下面的人都是看领导是什么水平的。领导是一个什么样技术思想，下面的人就能够很好的施展开来。

 

 

 

 

命名是可维护性的第一步，代码的功底倒是其次，因为每个人的技术经验不一样。

用拼音命名带来接手人员的阅读成本。比如用拼音命名变量或者程序文件

zhuanti
pt
其实是拼音的缩写，看不懂在干嘛

我们第一眼看不出这个要表达的意思，维护一个系统只能靠看代码来沟通了

好的命名，就是减少误解、减少沟通


比如，以前有code，后来有app跳转到网页时也有一个code，但是是app_code

命名上没有区分开，造成了一些沟通障碍。

开源组件amqp扩展，一个函数原来用的命名是：AMQPConnection::setTimeout():设置超时时间？读还是写，还是连接超时时间？

后来他们就改为了：AMQPConnection::setReadTimeout() ，好的命名看到就知道，噢，这是设置读的超时时间


哪怕是刚毕业的技术，没啥经验。这种风格也是很容易学的。这样他写的代码，就可以让别人好接手维护。