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

为何开发功能变得愈来愈慢?

 

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

 

 

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

 

本身作的成果无法让下一任衔接。就像官员上任，任期满了后。这个烫手的山芋丢给下一任去解决。我这一任期内，维护稳定不出事情就能够。

 

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

 

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

 

 

我发现很是像系统同样：只要保证我在这公司干这段时间内，系统是稳定的，能够继续加功能完成上面的任务便可。至于定时炸弹何时爆发，只要不在我任期内爆发就能够了。

因而我在任期内，明明知道这里是一个坑，都懒得去作代码优化，作重构了。干吗要浪费本身时间作这种事情。

 

 

 

为何招聘经验丰富的技术投入和产出很值得。避免了不少坑，留给之后的技术债务。

 

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

 

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

 

 

 

 

命名是可维护性的第一步，代码的功底却是其次，由于每一个人的技术经验不同。用拼音命名带来接手人员的阅读成本。好比用拼音命名变量或者程序文件zhuantipt实际上是拼音的缩写，看不懂在干吗咱们第一眼看不出这个要表达的意思，维护一个系统只能靠看代码来沟通了好的命名，就是减小误解、减小沟通好比，之前有code，后来有app跳转到网页时也有一个code，可是是app_code命名上没有区分开，形成了一些沟通障碍。开源组件amqp扩展，一个函数原来用的命名是：AMQPConnection::setTimeout():设置超时时间？读仍是写，仍是链接超时时间？后来他们就改成了：AMQPConnection::setReadTimeout() ，好的命名看到就知道，噢，这是设置读的超时时间哪怕是刚毕业的技术，没啥经验。这种风格也是很容易学的。这样他写的代码，就可让别人好接手维护。