开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《摸了 Thief-Book-VSCode》
今日推荐英文原文：《Death By Technical Debt》
今日推荐开源项目：《摸了 Thief-Book-VSCode》传送门：GitHub链接
推荐理由：人生想摸鱼，十有八九。摸与返工，二者不可得兼，欲摸，则这个项目甚善也。这是个在开着 VSCode 的时候假装自己在工作实际上却能够偷偷看小说的摸鱼项目，摸鱼项目该有的巧妙隐藏和老板键等等自然都是有的。当然了，摸鱼虽好，可不要忘了 DDL 哦。
今日推荐英文原文：《Death By Technical Debt》作者：Kevin Pimentel
原文链接：https://medium.com/swlh/death-by-technical-debt-31b5b085c8ea
推荐理由：简单概括技术债务——出来混迟早要还的

Death By Technical Debt

It’s possible that our generations debt crisis has made me more sensitive to technical debt than I should be. As software developers, we are always faced with time constraints and it’s these situations that cause us to introduce technical debt.

I think a lot of the time technical debt is caused by one of three things: pure laziness, lack of knowledge, or a lack of care.

Writing code is a form of art and our readers, or consumers, are other fellow software developers. Because of this, it’s very important to implement things as best as possible. No developer wants to work with developers who make their life more difficult than it should be. It’s important to demand some level of professionalism from fellow developers.

I’m not saying code has to be perfect but there are obvious times when you are dealing with code that just isn’t meeting any sort of standard. I want to touch on a few real examples that I have come across. These examples illustrate each of the technical debt causes that are at the root of all bad code. First, we should talk about what technical debt is.

What is technical debt?

Technical debt occurs when you choose the “easy way” or the “fast way” instead of spending the extra time or effort to implement a more appropriate long term solution. We’ve all heard. Just do xyz, no one will know. It’s true, the client will not know. But we the developers, always end up being the ones that suffer the consequences.

I have seen developers burn out over bad coding practices or lack of coding structure. It always starts when a programmer becomes distant and eventually toxic to the team. This leads to high churn rates which is extremely negative for teams.

When you spend time and resources training developers that leave it’s a huge loss for the company and team. You’re losing an asset and an unquantifiable amount of knowledge.

When technical debt builds up, developers get fed up, they get burnt out, they eventually become toxic, then they get lazy and stop caring, and eventually they leave.

Lack of Knowledge

This is probably the only time when introducing a quick fix is acceptable. As long as you plan on revisiting this type of technical debt, I have absolutely no problem with it. A good example of this kind of situation is when a bug is found in a legacy application that you don’t know much about. In order to implement a quick workaround you hard-code xyz and get it working fast, while you dive deeper into the code.

I think this is totally acceptable, especially in fast paced work environments.

Pure Laziness

Lack of knowledge can quickly become the bad kind of laziness when the quick-fix is not revisited and is left to rot over time. It’s important to be the kind of lazy developer that wants to automate everything and never have to do a task twice, but that’s not the kind of developer that I am talking about here.

The kind of lazy that I am referring to is the kind that has a history of hard coding, commenting / uncommenting code based on data, copying pasting code because it works, and so on.

Recently I was dealing with a legacy application that centered a video on a page depending on the number of videos. If there was a video alone in a row it needed to be centered. I discovered that a fellow developer was updating the centering code by commenting it on or off based on the amount of videos in the database.

He was actively making the bootstrap offset class available based on how many videos were in the system. This type of laziness is remarkably infuriating. Think about this:

Every time a client updates their videos the code will need to be turned on or off based on the amount of videos.

Now let’s say the client updates the videos once a month. The client will have to contact development every time it doesn’t look right. Let’s be generous and say that this can all be accomplished in 15 minutes each time. Let’s say this goes on for a year, that’s an hour every four months, 3 hours a year.

So you’re wasting 3 hours a year, when you could of taken 15 minutes to implement a: 
videos_count MOD 3 === 1
And called it a day for the rest of humanity. This is the type of thing that makes me want to choke a baby llama.

Lack of Caring

Lack of caring is easy to detect in the code. It’s usually a bunch of copy and paste with variables that make no sense, and changes that have to be implemented in 15 different places. There’s no attempt to follow the coding standard at all.

When a developer stops caring his code becomes very toxic and it’s extremely hard to follow what is going on. You never want to work with a developer that doesn’t care, this is the worst kind of developer and they will make your life more difficult.

Whenever I get involved in the interview process I am looking for what kind of effort this developer puts into their code. This will tell you a lot about the type of person they are. You want to keep developers that don’t care about code, and only care about it “working”, as far away from your team as possible. These types of developers will destroy your team and make everyone frustrated in the process.

Conclusion

The best way to deal with technical debt in my opinion is to get everyone to buy in and own the code. When you feel that you own something and are invested in it, you naturally want to do a better job. The second thing is to implement a coding standard. A coding standard should be such that you can’t tell the difference in who authored a line of code.

The final thing is code reviews. If you lack the knowledge to implement a fix, having fellow developers looking at the code might trigger the feedback needed to improve the code. Also, when you know other people are going to look at your code you tend to do a better job.

If the code is still a dumpster fire, you can always reject it. Which is why we version control.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/