真正糟糕的程序员都有哪些共同的特点？

Nick Bailey, Engineering Manager at Rally Health
“All happy families are alike, every unhappy family is unhappy in its own way”
Anna Karenina, Leo Tolstoy
There are many ways to be a bad programmer, and no traits that are common to all, but I think I can break down bad programmers into four broad categories:
The narrow minded. This is I think the most common kind of bad programmer. They know one language, one tools set, and don't know how to move beyond that. They can only program if it followsthe patterns they learned in school. These are the developers who call MySql ‘SQL’ or try to write websites that work like Swing apps because they can't think outside of one way of doing things.
The indifferent. These are the developers who don't see the problem with a hack solution. They never refactoring and never improve. They don't look for better processes or tools. They don't give a damb if the company goes under. They're fine plugging away at their 10 year old ASP app.
The arrogant. These are developers who think they're hot shit. They don't write , cause their code ‘has no bugs.’ They don't take feedback. They write hard to read, hard to manage code, because ‘if you don't understand it you must not be smart enough.’ They take their favorite language or paradigm and try to jam it everywhere. These are the most dangerous of the bad developers, because they are often quite smart, and can get stuff done, until Thierry hubris brings the whole system crashing down.
The just plain incompetent. Some folks, are just bad. The devs who put comma delimited strings in SQL databases, write empty catch blocks and use all global variables. They're rarer, but you see them.
I'd say, if I were giving advice, watch out for becoming narrow minded. The fact that you are asking this question means you aren't indifferent or arrogant. But it is very easy to get complacent. Constantly try to talk with developers who do different kinds of programming from you. Learn a weird language like Haskell or Prolog or Clojure. Learn about the alternatives to the tech you use. If you use Java, learn about .NET. if you use jQuery, learn ReactJS. No matter what, learn the implementation details. Don't ever stop running!

幸福的家庭都是相似的，不幸的家庭各有各的不幸——安娜·卡列尼娜，列夫·托尔斯泰。
成为一个糟糕的程序员有很多种方式，并没有什么所谓的共同特征，但我认为我可以将糟糕的程序员分为四大类：
第一类： 思想狭隘的程序员。这是我认为最常见的糟糕的程序员。他们只懂得一种计算机语言和一套工具，还不想着该如何去超越它，不知道要去多学一种语言。他们只有套用在学校里学到的那套模式，才能编程。这些开发者称MySql为“SQL”，他们尝试编写像 Swing 应用程序一样工作的网站，因为他们无法跳出这一种做事方式进行思考。
第二类：对什么都漠不关心的程序员。这些开发人员从不想着去解决黑客制造的问题。他们从不重构，也从不改进。他们不去寻找那些更好的程序或工具。如果公司倒闭了，他们也一点都不在意。他们可以继续使用他们已经用了10年的 ASP 应用程序。
第三类：傲慢的程序员。这都是些自以为自己很了不起的程序员。他们不改代码，是因为他们觉得自己的代码“没有任何的错误”。他们也不接受别人的反馈。如果你觉得他们写的代码很难读懂，而且还很难管理的话，那肯定是因为你自己不够聪明。他们采用的代码都是他们自己最喜欢的语言或范式，并试图将这些语言用到任何地方。这些糟糕的开发人员都是非常危险的，因为他们通常都很聪明，而且他们能够完成你交代的任务，但是他们的狂妄自大最终会导致整个系统都崩溃。
这些程序员简直就是无能，毕竟有些人就是很糟糕。有些开发人员会将逗号分隔的字符串放入SQL数据库、编写空的catch块并使用所有全局变量，虽然这些程序员并不常见，但你有时候还是会看到它们的。
我想表达的是，如果你让我给你提建议的话，那我要提醒你，不要变成一个心胸狭窄的人。事实上，当你问这个问题的时候，就意味着你并不是一个冷漠或傲慢的人，但人们很容易沾沾自喜。你可以试着去和不同编程风格的开发人员交流。你可以去学习一门与众不同的语言，比如Haskell、Prolog或Clojure。去了解你所使用技术的替代方案。如果你使用的是Java的话，那你可以去了解一下NET。如果你使用的是jQuery，那你可以去学习一下ReactJS。不管怎样，去学习一些新东西。永远不要停止进步！

Hans Brinkhof, Senior Java Developer (2017-present)
A few examples
They consider themselves the only person who’ll ever read their code.
Why bother using variable names that explain what the variable does, if you can just call them a1, a2, … After all, I know what they do, right?
They don’t or hardly document their code. Whether they do it in the code, or in some wiki/external documentation doesn’t matter, but somewhere there should be an accessible documentation about the project, both functionally, as technically.
They believe refactoring is a dirty word.
Why changing the code as it is now? It works. It always worked.
Well, chances are you’ve been using deprecated methods, which have been replaced by better alternatives by now, and, which might be removed from the language altogether soon enough, which would lead to problems when updating the language.
When they do refactor, they believe every change they do in code is “refactoring”. No, only actual improvements without changing the functionality is refactoring. Changing the code into something that has the same functionality, but is ten times as hard to read, not to mention maintain, is not refactoring, it’s called “screwing up”.
They understand the code they write, but they don’t (try to) understand the context of the project they’re working on.
It’s nice being able to write small snippets, and implementing them. It’s crap if you have no idea what the impact of them on the entire project might be.
They consider themselves good programmers. “If I wrote it, the code is good” kind of mentality. Usually, it isn’t, but if the code review is done by someone equally bad, it might actually make it into production. If it’s done by a good programmer, it might be a repetitive waste of his time.
They either don’t test their code, or only for a (very) limited number of scenario’s, leaving the most untested
And the list goes on …

我来举几个例子：
有些程序员认为自己是唯一一个会解读他们代码的人。
为什么要用变量名来表达这些变量的作用呢，如果你可以将它们命名为a1、a2的话，那我就会知道它们是做什么的了，对吧?
他们几乎从来都不记录他们自己的代码。无论是在代码中，还是在某些wiki或外部文档中，他们都不会记录自己的代码，虽然在这些地方不记录并没有什么关系，但是在某个地方应该有一个关于这个项目的可访问文档。无论是功能上的还是技术上的文档，都应该准备一个。
他们认为重构自己的程序就是在侮辱他们。
为什么要像现在这样更改代码呢？因为从它的工作原理上来说，更改代码是有效果的。
好吧，可能你现在一直在使用的方法已经被弃用了，他们已经被更好的方法所取代了，并且可能很快就会从语言中完全删除，如果还不更改的话，可能会导致更新语言时出现问题。
当这些程序员进行重构时，他们相信他们在代码中所做的每一个更改都是“重构”。但其实不是，只有在不改变功能的前提下，实际所进行的改进才是重构。仅仅只是把代码修改成具有相同功能的代码，但读起来要难十倍，而且维护起来更困难，这并不是重构，这叫做“搞砸”。
他们只理解自己所编写的代码，但他们从不试图理解他们正在处理的这个项目的上下代码。
能够编写小片段的代码并实现它们是很好的一件事。但如果你不知道这些小片段对整个项目的影响，那就太糟糕了。
他们认为自己是优秀的程序员。他们的想法通常是“如果这个代码是我写的，那肯定很好”。但通常情况下并不是这样，如果代码评审是由同样糟糕的人完成的，那么它可能真的会投入生产。如果它是由一个优秀的程序员完成的，那么这么做可能是在做重复地工作，是在浪费时间。
他们要么不测试代码，要么只测试数量非常有限的场景，剩下很多未测试的场景。
这样的例子不胜枚举……

Sam Penrose, Software Engineer
They don't manage the complexity of the total system they're working in.
Competent management will take care of them. More interesting to me are the hardworking, generally respected developers who slowly bury their employer under technical debt with a series of defensible decisions -- Guilliame's 2nd and 5th points, and Pankaj's 3d.**
Working code of any significant length is an intellectual artifact whose complexity lies within range of the limit of a single mind to comprehend. Maintaining that comprehension is difficult; using one's comprehension to make changes that reduce system complexity (or entropy, if you prefer) is harder still and, by definition, doesn't deliver any immediate value.
Managing employees whose job exists to deliver direct value but which requires significant labor whose value is essentially invisible is a vexingly difficult problem. Per Clayton Christensen, many organizations fall into the "get a measurable win in a short time frx" trap, and incent their developers to buy small chunks of value with small or not-small chunks of technical debt. It takes a certain perversity of spirit to realize that this approach must be resisted at times, and some skill to effectively do so.
Steve Yegge's "Done, and Gets Things Smart" remains my favorite discussion of these themes. The Dunning–Kruger Effect is a first-order issue whenever reasoning about technical skill (including when attempting to parse Yegge's essay).
(upxe: I like http://www.quora.com/Computer-Programming/What-qualities-do-really-bad-programmers-share/answer/Kyle-Bahr better than this one.)
** The points, in order: "They don't care about how they go about coding - best practices, methodology, modularization, architecture...", "They don't care about putting in the work that's needed to build things the right way - they'll take shortcuts just because "look, it works like this!"", "Starts coding without thinking the total structure of the code."

他们工作的整个系统都太复杂了，以至于他们管理不了。
但更让我感兴趣的是那些努力工作且受人尊敬的开发人员，因为他们会通过一系列合理的决策，慢慢的将自己的雇主拉入技术这个大环境中。
任何长度的工作代码都是一种重要的智力产物，对于他复杂性的理解是在单个大脑所能理解的范围之内的。因为保持这种理解是很困难的，所以利用自己的理解去做出能够降低系统复杂性的改变就变得更加困难了，并且从定义上来说，这种改变并不会带来任何直接的价值。
管理员工是一个非常棘手的问题，因为他们的工作是直接提供价值。所以需要大量的劳动力，而这些劳动力的价值基本上是无形的，所以这是一个令人烦恼的难题。克莱顿 · 克里斯滕森说，许多组织陷入了“要在短时间内获得可衡量的胜利”的陷阱，并鼓励他们的开发人员用小量或大量的技术债务来购买小量的价值。要意识到这种方法有时必须要加以抵制，需要一定刚愎自用的精神，还需要一些技巧才能有效地做到这一点。
Steve Yegge的《Done, and Gets Things Smart》仍然是我对这些主题最喜欢的讨论。邓宁克鲁格效应在对技术技能进行推理时是一个首要问题（包括尝试解析Yegge的文章时）。
（更新：我更喜欢http://www.quora.com/Computer-Programming/What-qualities-do-really-bad-programmers-share/answer/Kyle-Bahr。）
“他们并不关心他们是如何编码的，不管是最佳的实践方法、模块化还是架构，他们都不在乎”,“他们不认为工作是需要以正确的方式来构建事物的，所以他们最终会走捷径，因为他们会说：“看，它就是这样工作的！”，“他们经常不考虑代码的整体结构就开始编码。”

Raviteja Chirala, I write code for fun
A lot of uncovered test cases while writing unittests or no unit tests at all :(
Solution : Test Driven Development
Poor or no documentation
Write comments while writing code. Prepare ReadMe before you write code and upxe progressively
Less or no logging
Same like above. Should be written while writing code
Improper use of variable names. Names should say what it’s doing. i =1 doesn’t help often
variable names can be verbose
Not ‘catch’ing exceptions when you’re supposed to.
Not catching exceptions will end the workflow when it doesn’t need to
Not seeing a vision of how your code will be consumed by end user or application. It should be simple for a user to use. If it’s too hard to plugin your code, time to revamp the design.
Engineer has to think like a user. “It’s really complex to make something simple”. users care for simplicity.
IDE’s can help you avoid this.
Writing big chunk of code. Ideally it should be modularized and generic so it can be reused. Writing a function more than 10 lines can be split into two.
Building classes, abstracts, interfaces or traits whatever can save a lot of work
Hardcoding parameters while they can be configured
Easy to maintain and manage
Hard stop at first solution that comes into the mind first and then later spend a whole day again for so called optimizations.
Saves a day

在编写单元测试或根本不编写单元测试时，有大量没有被发现的测试用例。
对此的解决方案是：测试驱动开发。
文档不足或根本就没有文档时：在编写代码的同时还编写注释。在编写代码和逐步更新代码之前先准备好自述文件。
对于较少的或没有日志记录的情况：像上面一样，应该在编写代码时编写。
对于变量名使用不当的情况：名称应该就能说明它在做什么。像I =1这种的变量名并不能很好的说明他的作用。
变量名可能会很冗长。如果变量名很长，那么会导致在应该“捕获”异常的时候无法“捕获”到异常。
如果不捕获异常，就会提前结束工作流程。
我们看不到最终用户或应用程序会如何使用您的代码。但用户使用起来应该是简单的。如果你觉得你的代码很难插入的话，那你就需要重新设计了。
工程师必须要像用户一样思考。虽然“把东西变的简单真的很难”，但用户喜欢简单。
IDE可以帮助您避免这种情况。
在理想情况下，它应该是模块化和通用的，这样就可以重复使用它。写一个超过10行的函数可以分成两部分。
构建类、抽象、接口或特征都可以节省大量的工作。
当参数可以配置时，对其进行硬编码，这样易于维护和管理。
当脑海中浮现第一个解决方案时就停下来，然后再花一整天的时间进行所谓的优化。
这样可以节省一天的时间。

Paul Wicks, studied at Center for Creative Studies
The first mistake you should learn to avoid is believing that programmers are either good or bad.
Let’s imagine, for a moment, that you’d asked: “What qualities do really bad words share?”
Well, one quality that bad words share is that they’ve been used in the wrong place, at the wrong time. A particular bad word might have been exactly the word you needed, in another situation, and you’d have been grateful to have it at the ready.
Of course there are some unredeemable words, but opinions about even the worst words change over time, and may have a very different connotation within different groups of people.
If we could over-clock Time itself, we’d see our words changing what they impart, and watch people’s opinion of their utility evolve.
Software developers must constantly strive to do exactly the right thing in the context of a given project, (or a given phase of a project).
We must adapt, as what’s required of us changes. We must determine what to alter about what we think and do… and when.
A reasonable decision, in one context, may be perceived as idiocy, in another.
You may excel in almost every aspect of the job, but get caught failing to make the appropriate choice, at the appropriate time, and you may be perceived as a bad programmer. A momentary lapse of attention could tarnish years of diligence and success. Are you bad? No? No, probably not. What should you do now?

你应该学会避免的第一个错误就是认为程序员要么好要么坏。
让我们想象一下，如果你问：“真正糟糕的程序员有哪些共同的特质？”
那么这些特别不好的词就有一个共同的特点，那就是它们在错误的时间、错误的地点都使用过。在另一种情况下，一个特别不好的词可能恰恰是你需要的词，你会很感激能随时准备好它。
当然也有一些不可挽回的词，但即使是最糟糕的词，人们的看法也会随着时间的推移而改变，而且在不同的人群中可能会有不同的含义。
如果我们能超越时间本身，我们就会看到我们的语言改变了它们所传递的信息，并会看到人们对其所表达意思的看法在逐渐演变。
软件开发人员必须不断的努力，在给定项目（或项目的给定阶段）的环境中做正确的事情。
我们必须适应，因为对我们的要求在发生变化。我们必须决定在什么时候改变我们的想法和行为。
在某种情况下，一个合理的决定在另一种情况下可能会被认为是愚蠢的。
你可能几乎在工作的每个方面都表现的很出色，但如果你没有在适当的时间做出适当的选择，那你可能会被认为是一个糟糕的程序员。一时的疏忽可能会损害你多年的勤奋和成功。难道你真的就不好吗？不，并不是这样的。那你现在应该怎么做呢？

I recognize that you’re only asking for list of common errors to avoid, such failing to scope a variable to avoid stepping on another, or when not to use recursion. But that list is too long, and too variable, to function as a useful rubric.
Software development tools and languages are logical and precise. We use them correctly or they don’t work. At this level, it’s science. While this is perfectly true, from this narrow perspective, it also creates a mistaken impression.
The process of working together, to apply software tools and languages, is punctuated by a series of *judgements*, all of which depend on where and when the work is being done, and by whom. Such decisions are never 100% right or 100% wrong. This lies slightly beyond the reach of science, and resists being reduced to a list of dos and don’ts.
But, I’d be letting you down, if my response didn’t adapt to meet your expectations.
So here’s a list of things that someone thought of as a bad programmer might fail to do:
Look for styles in the codebase you’re working on, and either follow them, or suggest a new direction.
Look for established practices among your peers, and either adopt them or offer improvements.
Do your homework. Being prepared isn’t a state you ever actually arrive at, it’s one you continually strive toward.
Don’t assume that established requirements won’t change. Requirements emerge or change as development proceeds. Things change, others are discovered.
Approach your work like your modeling in clay; not carving something out of a block of marble. Work a bit, show a bit , change a bit.
OK, that covers the obvious. Now let me offer some chewier food for thought. An ostensibly bad programmer wouldn’t:
Be aware that today’s valued skill is often the basis of tomorrow’s derided anti-pattern. Skills are disposable. Talent is the ability to apply only relevant skills, and develop new ones as needed.

我看到您只是在要求列出一些常见的错误，例如对变量进行调整以避免踩到另一个变量，或者什么时候不使用递归等。但是这个列表太长了，而且变化也太大了，所以不能作为一个有用的标题。
软件开发工具和语言都具有逻辑性和准确性。所以我们要正确的使用它们，否则它们就不起作用。从这个层面上来看，这就是科学。虽然这样做是正确的，但从一个狭隘的角度来看，它也会产生一种错误的印象。
在应用软件工具和语言工作的过程中，会经常被一系列的“判断”所打断，而这些判断都取决于在何时何地以及由谁完成。这样的决定永远不会 100% 正确或 100% 错误。这是科学所无法企及的，也不应该被简化为一系列该做和不该做的事情。
但是，如果我的反应没有达到你们预期的那样，那我的回答可能会让您感到失望。
所以我在这里列出了一些被认为是糟糕的程序员可能不会做的事情：
从您正在处理的代码库中寻找样式，然后要么遵循它们，要么提出新的方向。
在你的同行中寻找已建立的实践，要么采用它们，要么改进它们。
做好准备。准备状态并不是你真正要达到的状态，而是你应该不断去努力的状态。
不要假设既定的需求不会发生改变。随着不断的开发，需求就会发生改变。
要像在粘土中建模一样仔细的处理您的工作，而不是要在一块大理石上雕刻出什么东西一样。努力工作，表现多一点，改变多一点。
好了，这是显而易见的。现在让我来提供一些需要思考更多的信息。一个表面上很糟糕的程序员不会做的事：
要知道，今天有价值的技能往往是明天被嘲笑的技能。因为技能是一次性的。

Know when to back away from the keyboard and stop thinking about it. Focus cannot be sustained for hours on end, without compromising your effectiveness. Your powers of intellect, creativity, and judgement are exhausted more quickly than you’re able to perceive, and must be refreshed with rest, nutrition, and distraction.
Remain calm when things go wrong. The worse the situation, the calmer you need to be. While in absolute terms, this is probably unrealistic, doing what *is* possible to avoid panicking will help avoid making it worse. In practical terms, this is difficult to achieve. You can only do your best. Take 5 minutes. Rehydrate. Close your eyes. Breath. Use your words. (A bad word might be helpful, at this point, as long as you don’t believe it, and quickly harness some good ones.)
Know when to ask for help, and how. Other software developers need to be able to focus, at times, and will not always welcome distraction. Accept the promise of an asynchronous response, if necessary.
Don’t necessarily ask for an answer. Ask someone to simply listen to you explain your problem. When you hear your own words, more or your mind will be engaged to process the issue. More often than not, you’ll find your own answer. You may also get some good advice, which might improve on your solution.

你要知道在什么时候离开你的工作岗位，并不再思考它。在不影响你的效率的情况下，可以不用持续专注好几个小时。你的智力、创造力和判断力耗尽的速度比你想象的要快，所以你必须通过休息、吸收营养和分散注意力来恢复活力。
当事情出错时要保持冷静。情况越糟，你就需要越冷静。虽然从绝对意义上讲，这可能是不现实的。但尽一切可能避免恐慌将有助于避免使情况变得更糟。实际上，这是很难实现的。你只能尽力而为。（在这个时候，只要您不相信这些不好的词并迅速利用一些好词，可能就会对你的恢复有所帮助。）
知道何时寻求帮助以及如何寻求帮助。其他软件开发人员有时需要能够集中注意力，所有并不是要一直通过分心来恢复活力。
不要去问答案。通常，您会自己找到答案。您还可能会得到一些好的建议，这些建议可能有助于改进您的解决方案。

Now let’s get to the heart it:
Don’t use a constant, to label yourself or others. If you’ve done well today, and delivered good work, that does not make you a ‘good programmer’. If you’ve caused havoc in the system, Today, and your teammates are not pleased with you, that does not make you a ‘bad programmer’. If allowed, those labels tend to have have a prolonged life-cycle, living in a zombie process. They constitute a bug in the system. Don’t believe them, and do what you can to release that label and avoid it’s use in the future.
Once you recognize that no programmer is simply bad or good, you may be able to shed defensive behaviors. This helps, by giving you access to introspection.
You asked what bad programmers had in common, and I’ve failed to give you the answer you asked for.
That doesn’t make this a bad answer.
Once you let go of the premise that “becoming a bad programmer is something that happens to people if they make some number of common mistakes”, and focus instead on adapting to each situation as you see it, you become something much more useful than a *good* programmer; you become an *evolving* programer.
best_behavior_models = [Think, Speak, Learn, Solve, Deliver, Rest, Recharge, Grow]
Welcome to this life of ours.

现在让我们进入正题：
不要使用一个常量，来给自己或他人贴上标签。如果你今天做得很好，并且很好的完成了工作，那并不意味着你就是一个好程序员。如果你今天严重的破坏了系统，而且你的队友还对你不满意，那并不意味着你是一个“糟糕的程序员”。通常这些标签往往具有较长的生命周期，它们成了系统中的一个错误。
一旦你认识到程序员并不只是一个简单的好人或一个简单的坏人，你就可以摆脱这种行为。这有助于您进行自省。
当你问我糟糕的程序员有什么共同点的时候，我并没有给你想要的答案。
但我这个回答并不是一个糟糕的答案。
一旦你放弃了“人们成为一个糟糕的程序员是因为他们犯一些常见的错误”这种想法，转而专注于适应你所看到的每种情况，你就会成为一个比好的程序员更有用的人，你还会成为一个不断进步的程序员。
欢迎来到我们的世界。