今日推薦開源項目：《摸了 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
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/
今天的項目摸魚指南….真不錯。