数据结构不好适合做程序员_程序员知道的6件事很不好但仍然要做

数据结构不好适合做程序员

Being a programmer comes with a lot of decision-making. Sometimes we make decisions that we know are no good, and yet we consciously make these bad decisions.

成为程序员会带来很多决策。 有时,我们做出自己认为不好的决定,但有意识地做出了这些错误的决定。

There can be various reasons why programmers choose to do these bad things — for the thrill, because of laziness, etc. One thing is certain: You shouldn’t do the things listed in this article too often. Granted, sometimes it just feels good to be bad.

程序员选择做这些不好的事情可能有多种原因-出于刺激,由于懒惰等。可以肯定的一件事是:您不应过于频繁地执行本文中列出的事情。 当然,有时候感觉不好就好。

Here are six things programmers do despite knowing they are bad.

尽管程序员知道这很不好,但这里有六件事。

1.快速和肮脏的解决方案 (1. Quick and Dirty Solutions)

Sometimes you know the solution you chose is suboptimal. However, this suboptimal solution gets implemented because it's quick and the code works. This leaves you with more time to fix other stuff. Nothing wrong with that, right?

有时您知道选择的解决方案不是最佳的。 但是,此次最佳解决方案得以实现,因为它速度很快且代码有效。 这使您有更多时间修复其他内容。 没错吧?

It feels good to fix a certain problem within a matter of time. But making your code work is only a tiny part of the job. The problem with quick and dirty solutions is that this approach brings some serious deficiencies that lead to more technical debt.

在一段时间内解决某个问题感觉很好。 但是,使代码正常工作只是工作的一小部分。 快速而肮脏的解决方案的问题在于这种方法带来了一些严重的缺陷,导致更多的技术债务。

Whenever you bring another one of your quick and dirty solutions to review, you should be aware of the fact that these “solutions” can be devastating for the morale of the team.

每当您提出另一种快速而又肮脏的解决方案进行审核时,您都应该意识到以下事实:这些“解决方案”可能会破坏团队的士气。

In your defense, there might be some cases where quick and dirty may not really matter. It might actually be the right way to go in certain situations (e.g. when code has a short lifespan).

在您的辩护中,可能在某些情况下快速和肮脏可能并不重要。 在某些情况下(例如,代码寿命短),这实际上可能是正确的方法。

But when you need code for the long run, fixing things in a quick and dirty way will come back to bite you. Don’t justify these solutions by saying that you’ll clean them up later. We’ve all heard that fairy tale before.

但是,从长远来看,当您需要代码时,以快速而肮脏的方式进行修复将再次使您感到痛苦。 不要说您稍后要清理它们来证明这些解决方案是合理的。 我们以前都听过那个童话。

2.误吞错误 (2. Silently Swallowing Errors)

Silently swallowing errors is a mistake I’ve seen plenty of times from inexperienced developers. However, seasoned developers tend to silently swallow errors as well. And unlike inexperienced developers, they do it on purpose.

我无经验的开发人员多次无声地吞下错误是一个错误。 但是,经验丰富的开发人员也倾向于默默地吞下错误。 与经验不足的开发人员不同,他们是故意这样做的。

When you’ve got loads of stuff to do and deadlines come into play, you don’t have time for every issue that comes rolling into the bug tracker. Instead of being disturbed by all the potential notifications, you sometimes choose to silently swallow the errors. This allows you to focus on all the remaining tasks you still have to do.

当您有大量的工作要做且截止日期到来时,您就没有时间来解决所有问题,这些问题都将流入Bug跟踪器。 有时您选择静默地吞下错误,而不是被所有潜在的通知所打扰。 这使您可以将精力集中在仍然需要完成的所有剩余任务上。

Other times, swallowing errors silently happens unintentionally. Some reasons for this can be a lack of experience or not knowing what’s going on in the code on a lower level.

其他时候,吞咽错误会无意间无声地发生。 造成这种情况的某些原因可能是缺乏经验或不了解较低级别代码的内容。

You can think of some use cases where swallowing errors would be preferable (e.g. when creating a log file fails for some reason since there is nowhere to report this).

您可以想到一些吞咽错误更可取的用例(例如,由于某种原因创建日志文件失败,因为无处可报告)。

However, as a rule of thumb, you don’t want to silently swallow errors.

但是,根据经验,您不希望默默地吞下错误。

3.过度工程 (3. Over-Engineering)

Implementing certain design patterns for the heck of it is something that most developers have done. Just because you see an opportunity to implement a design pattern doesn’t mean you should.

大多数开发人员都已经实现了某些设计模式。 仅仅因为您看到实施设计模式的机会并不意味着您应该这样做。

This is a classic form of over-engineering, and all you’re going to accomplish with it is add more technical depth to the codebase. Over-engineering tends to happen more often when developers aren’t getting challenged enough. When this happens, they start to look for challenges themselves.

这是过度工程的经典形式,您要做的就是在代码库中增加更多的技术深度。 当开发人员没有受到足够的挑战时,过度工程往往会发生。 当这种情况发生时,他们开始寻找挑战。

Another reason why over-engineering might happen is because of assumptions — the assumption that adding a certain piece of code might be helpful in the future. This additional piece of code gets added to the codebase, but it probably never gets used. Maybe the best way to explain over-engineering is that it is code that solves problems that don’t exist.

发生过度工程的另一个原因是基于假设,即添加某些代码可能对将来有所帮助的假设。 这些额外的代码片段已添加到代码库中,但可能永远不会使用。 解释过度工程的最好方法可能是,代码可以解决不存在的问题。

4.重塑车轮 (4. Reinventing the Wheel)

Building things from scratch is what every developer likes to do from time to time. The reason developers love reinventing the wheel is that it’s a great way to really understand how certain things work. Building something from scratch lets you go over the entire process, which will provide you with a lot of insight into how it works.

从头开始构建事物是每个开发人员不时喜欢做的事情。 开发人员喜欢重新发明轮子的原因是,它是真正了解某些事物如何工作的好方法。 从头开始构建某些东西可以让您遍历整个过程,这将为您提供有关其工作原理的大量见解。

Although reinventing the wheel is fun, more often than not, there’s no time for it. Deadlines have to be met, so reinventing the wheel is discouraged simply because it takes too much time.

尽管重新发明轮子很有趣,但往往没有时间。 必须满足最后期限,因此不鼓励重塑车轮,只是因为这会花费太多时间。

Sometimes that time cost can be justified, and sometimes there is no way to justify it. In other cases, the task is so critical that getting it wrong can have a terrible consequence, which means reinventing the wheel is not your best option.

有时可以证明时间成本是合理的,而有时则无法证明它是合理的。 在其他情况下,这项任务非常关键,以至于弄错它可能会带来可怕的后果,这意味着重新设计车轮并不是您的最佳选择。

5.编写错误的提交消息 (5. Writing Bad Commit Messages)

Writing bad commit messages is something a lot of developers do despite the fact that they know that it can hurt them in the long run. Every developer understands why you might not take the time to write a good commit message. You’ve finished that feature you’ve been trying to fix for days and now you’re finally ready to commit the final changes. The sooner you’re done with it, the better.

尽管事实上开发人员会从长远来看会伤害他们,但是编写很多错误的提交消息仍是许多开发人员的工作。 每个开发人员都知道为什么您可能不花时间编写良好的提交消息。 您已经完成了几天尝试修复的功能,现在您终于可以提交最终更改了。 越早完成,越好。

However, taking the time to write good commit messages that provide useful information about what has changed and why is crucial. When things really go south, the revision history is a great resource to quickly find out where exactly things went wrong.

然而,抽出时间来写好承诺,提供有关发生什么变化有用的信息的消息, 为什么是至关重要的。 当事情真的南下时,修订历史记录是快速找出问题出在哪里的重要资源。

If you want to read more about the importance of writing good commit messages, check out this article that I wrote.

如果您想了解更多有关编写良好提交消息的重要性的信息,请查看我写的这篇文章

6.拖延 (6. Procrastinating)

Procrastinating is something that you’ll see happening a lot. Developers tend to procrastinate whenever they’re stuck or “can’ t get into a project.” There might be moments when you find yourself procrastinating since you can’t see the forest for the trees. The amount of work that has to be done is so overwhelming that it results in not getting anything done.

拖延是您会经常看到的事情。 当开发人员陷入困境或“无法进入项目”时,他们往往会拖延。 有时候您会因为看不见森林而感到拖延。 必须完成的工作量如此之多,以至于无法完成任何工作。

You don’t want to procrastinate for too long since it’s a waste of time. Usually, breaking your work into smaller chunks helps get you going. When that doesn’t work, try to take a short break to freshen up your mind.

您不想拖延太久,因为这是浪费时间。 通常,将您的工作分成较小的块可以帮助您前进。 如果这种方法不起作用,请尝试片刻休息,以使您耳目一新。

“Action will destroy your procrastination.” — Og Mandino

“行动将破坏您的拖延。” — 奥格·曼迪诺

结语 (Wrapping Up)

There are a few things programmers do even though they know they’re no good. When it comes to coding, this varies from implementing quick and dirty solutions to silently swallowing errors, writing bad commit messages, and over-engineering. Reinventing the wheel is also worth noting since this can cost way too much time. That applies to procrastination as well.

即使程序员知道自己不好,也有一些事情要做。 在编码方面,从实现快速,肮脏的解决方案到默默地吞下错误,编写错误的提交消息以及过度设计,不一而足。 重塑轮子也值得注意,因为这会花费太多时间。 这也适用于拖延症。

I hope you’ve become more aware of these bad things so you can try to stop doing them (despite the fact that it feels good to be bad sometimes).

我希望您对这些不好的事情有了更多的了解,因此您可以尝试停止做这些事情(尽管有时候感到不好是件好事)。

Thanks for reading!

谢谢阅读!

翻译自: https://medium.com/better-programming/6-things-programmers-know-are-bad-but-still-do-anyway-45d9460ebde

数据结构不好适合做程序员

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值