Software archeology: your code live how long? -Programming, source code, code-IT information

The original title of the source of life, IT information Edit modify, as appropriate.

Look at your working code. How long has already run? How old is the code? Six months? A year? May have five years for such a long time, right? Ten years? 20 years?! How old is the code? Less than 10%-kilometer? Or half? Or you have 90%? In order to understand the answers to these questions, my code of survival time was doing some research.

(IT information with map)

Software archeology

Has been around for many years and already has its own set of source companies operating in, writing software is similar to software like archaeological practice, research applications as in an ancient city, layer-by-layer lift the veil of the past.

Once you start to dig into some packaged mini service, even have begun to study the past: may remain on the company's service-oriented architecture's first attempt now is to be accompanied by a whole complex business logic services and bundles the Spring's summary. Dig us back to the era of the EJB; because developers have lost their desire to understand, some beans that have been forgotten for a long time still cling to life. Further down is the place where the skeleton of the whole system.

If not broken, don't fix it

So what is bad code? No doubt about it with such a strong sense of purpose. At least some of it.

If you look at your one-year writing code and found that nothing can change, you is virtually no growth this year.

We have been learning: better understanding, better understanding of solutions in the field, new structure, new tools, new methods, new standards and new ideas. You write code a year ago can be improved in some places it is quite normal, but how much code you have go back and improve it?

Legacy code is becoming more and more difficult to change. If a business needs to change so that you have to go back to modify the original EJB, what would you do? You can modify the code you wrote more than 10 years ago? Or take the time to analyze which parts you need to modify? Or simply create a new small module to solve? These modifications are costly.

And now the question is: to repay this "technical debt" is the right thing, but modified the previous code will generally more than you wrote last week or last month wrote slowly. If the code should be amended, you didn't get to modify, which will affect the functionality of your new. The worst is that sometimes we will know something we did wrong, but still kept his long run. These methods at the time we thought it was right, but now appears to be wrong.

Life of our code?

I conducted a survey on a large amount of source code, including commercial and open source, and design a variety of languages (Java,C#,Ruby). On the whole, these codes follow a similar rule:

About 70% of the code, within 12 months after you wrote has been used without modification.

Perhaps not surprisingly, code completion for the first few months after changes are the most frequent. Further back, seems to have entered into a maintenance mode, changes the quantity is relatively small.

I find this stuff really interesting: 75% code after I finished about a year later is still the same. You can imagine that I understood how much on this issue now, imagine already forget design thinking, changed the architectural vision, new tools and is reconstructed using libraries. Imagine when writing lines of code today and there is much room for improvement. Moreover, those still left with a similar technology code base of the debt, even if we have been diligently repay, never to be seen how much old code new.

How do I do this analysis? Thanks to the magic of Git, it makes this analysis is very simple. As long as the entire warehouse to do a recursive git blame, can commit against each line of code in the branch are listed, the author, commit time. Combined with some shell scripting skills will be able to arrive at a monthly or daily statistics:

git ls-tree -r -rz --name-only HEAD -- | xargs -0 -n1 git blame -f HEAD | sed -e 's/^.* /([0-9]/{4/}-[0-9]/{2/}/)-[0-9]/{2/} .*$//1/g' | sort | uniq -c

Monthly statistics, as of today, this is the chart of the above output every line of code has recently been changed. However, I can easily push ahead of time, such as the start time by 2015:

git checkout 'git rev-list -n 1 --before="2015-01-01 00:00:00" master'

After pushing time again recursively run the git blame, by comparing the results of each month, I will be able to know how much of the code was written by 2015. After a more detailed analysis, I can draw a month later modified how changes over time in the number of lines of code, and know the code how fast the recession (slow).

Conclusion

Code is nothing more than to achieve at some point, some business data transmitted, but soon it becomes a liability. Era more long, original of code on more decay and more to modified , according to above of analysis, you is easy understand why a code warehouse can exists nearly ten years of long, inside of code for what are is some antique: annual of changes volume less of and less, they is lying in there didn't people tube, throughout we on just in constantly to to inside added new of heritage--they in the of most even to has next year you still also is can found of.

In this case, what can we do? Outdated code just piled up, this seems to be the nature of the software, in my personal experience, even if all the code refactoring, seems to have little. Can we do something else? Or we simply accept the more older code is more difficult to change this fact? Or do we need to find a way to encourage software has a much shorter half-life, faster to get rewritten.

软件考古学：你的代码活多久了？ - 编程,源代码,代码 - IT资讯

原标题《源代码的寿命》，IT资讯编辑酌情修改。

看看你现在日常工作中的代码。已经运行了多久了？代码有多老了？有六个月？一年？可能都有五年这么久了吧？十年？二十年呢？！这样的代码有多老了？不到10%？还是一半？亦或者已经有90%了？为了了解这些问题的答案，我对代码的存活时间做了一些调查。

（IT资讯配图）

软件考古

在已经存在很多年并且已经有自己的一系列源码运作的公司里，编写软件就像是类似软件学考古的一种磨练，深入研究应用就像在挖掘一个古老的城市，逐层的揭开过去种种的面纱。

一旦你开始钻研一些封装好的微型服务，就算是已经开始研究过去：也许残留着有对公司面向服务体系架构的第一个尝试；现在就是对伴随着复杂业务逻辑的整体服务并且捆绑了Spring的总结。深入挖掘后我们回到了EJB的时代；由于开发者已经丧失了对它们理解的欲望，一些已经被遗忘好久的beans仍然依附于生活。再往下就是整体系统骨架的地方了。

如果没有被打破，就不要去修理它

如此糟糕的代码是什么？不用怀疑它带有如此强烈的目的性。至少有一些是这样的。

如果你查看你一年期所写的代码并且发现没有什么可以改变的，你这一年算是没有成长。

我们一直在学习：更好的理解领域，更好的理解领域解决方案，新的架构方式，新的工具，新的方法，新的标准以及新的思路。你一年前的写代码在某些地方可以进行改进这是很正常的，但是，有多少代码你回过头去进行改进了呢？

旧代码是会变得越来越难修改的。如果一个业务需求的变更让你必须回头修改最原始的EJB，你会怎么办？你会去修改你十多年前写的代码吗？或者花时间去分析其中需要修改的部分？或者干脆每次都新建一个新的小模块来解决？这些修改的代价是很昂贵的。

而现在的问题是：偿还这种“技术债”是正确的事，但是修改以前的代码一般都会比你上周写的或者上个月写的东西慢。如果以前代码应该修改的地方你没有及时去修改，这将影响你开发新的功能。最糟糕的是我们有时会明明知道有些地方我们做错了，但是还是保持他长期运行。这些方法在当时我们认为是对的，只是现在看起来是错了。

我们代码的寿命？

我对大量源代码做过调查，其中包括商业以及开源的，设计各种语言（Java，C#，Ruby）。总体上，这些代码都遵循一个相似的规则：

大约70%的代码，在你写后的12个月内一直在使用，没有发生修改。

也许并不奇怪，代码完成之后的头几个月改动是最频繁的。再往后似乎就进入了一种维护模式，改动量变得相对较少。

我发现这玩意儿实在太有趣了：大约75%的代码在我完成一年后仍然是原来的样子。你可以设想一下我现在对于这个问题理解了多少，想像一下那些早就忘掉的设计思想，改变了的架构愿景，新的工具和仍能重构使用的库。想像一下当年写下的那一行行代码在今天又能有多大的改进余地。而且，在那些仍然遗留着类似技术债的代码库里，就算我们一直在孜孜不倦地偿还，也没见到老的代码新了多少。

我是怎么做的这项分析？这要归功于Git的魔力，它使这项分析变得很简单。只要对整个仓库做一次git blame的递归，就能够列出针对分支中的每一行代码的commit号、提交人、提交时间。配合上一些shell脚本技巧就能得出每月或每天的统计数字：

git ls-tree -r -rz --name-only HEAD -- | xargs -0 -n1 git blame -f HEAD | sed -e 's/^.* /([0-9]/{4/}-[0-9]/{2/}/)-[0-9]/{2/} .*$//1/g' | sort | uniq -c

按月份统计，截止到今天，以上输出的这个表格是关于每一行代码最近被改动过的时间。不过，我也可以很容易地把时间往前推，比如把时间推到2015年的开始：

git checkout `git rev-list -n 1 --before="2015-01-01 00:00:00" master`

把时间往前推之后，重新递归运行一次git blame，通过比较每个月得出的结果，我就能知道有多少代码是在2015年之前写的。经过更加详细的分析，我也能得出某个月中最新修改的代码行数量怎样随着时间变化而变化，进而知晓代码衰退得有多快（多慢）。

结论

代码写出来无非是为了实现某个意图，递送一些商业数据，但很快这就变成一种负债了。年代愈发久远，原来的代码就越腐朽而越难以修改，根据上面的分析，你很容易明白为什么一个代码仓库能够存在将近十年之久，里面的代码为什么都是些老古董：每年的改动量少之又少，它们就是躺在那儿没人管，自始至终我们就只是在不断地往里面添加新的遗产——它们中的大多数即使到了下一个年头你仍然还是可以找到的。

对于这种情况，我们可以做些什么？过时的代码只会不断堆积，这似乎就是软件的自然法则，依我个人经验来看，即使大家齐心协力对这些代码进行重构，似乎也收效甚微。我们还能做些别的么？或者我们干脆坦然接受越是年代久远的代码就越难修改的这一事实？还是我们需要找到一个办法，鼓励软件有一个更短的半衰期，以更快地得到重写。