真正糟糕的程序員都有哪些共同的特點(diǎn)？

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!

幸福的家庭都是相似的，不幸的家庭各有各的不幸——安娜·卡列尼娜，列夫·托爾斯泰。
成為一個(gè)糟糕的程序員有很多種方式，并沒有什么所謂的共同特征，但我認(rèn)為我可以將糟糕的程序員分為四大類：
第一類： 思想狹隘的程序員。這是我認(rèn)為最常見的糟糕的程序員。他們只懂得一種計(jì)算機(jī)語言和一套工具，還不想著該如何去超越它，不知道要去多學(xué)一種語言。他們只有套用在學(xué)校里學(xué)到的那套模式，才能編程。這些開發(fā)者稱MySql為“SQL”，他們嘗試編寫像 Swing 應(yīng)用程序一樣工作的網(wǎng)站，因?yàn)樗麄儫o法跳出這一種做事方式進(jìn)行思考。
第二類：對什么都漠不關(guān)心的程序員。這些開發(fā)人員從不想著去解決黑客制造的問題。他們從不重構(gòu)，也從不改進(jìn)。他們不去尋找那些更好的程序或工具。如果公司倒閉了，他們也一點(diǎn)都不在意。他們可以繼續(xù)使用他們已經(jīng)用了10年的 ASP 應(yīng)用程序。
第三類：傲慢的程序員。這都是些自以為自己很了不起的程序員。他們不改代碼，是因?yàn)樗麄冇X得自己的代碼“沒有任何的錯(cuò)誤”。他們也不接受別人的反饋。如果你覺得他們寫的代碼很難讀懂，而且還很難管理的話，那肯定是因?yàn)槟阕约翰粔蚵斆?。他們采用的代碼都是他們自己最喜歡的語言或范式，并試圖將這些語言用到任何地方。這些糟糕的開發(fā)人員都是非常危險(xiǎn)的，因?yàn)樗麄兺ǔ６己苈斆鳎宜麄兡軌蛲瓿赡憬淮娜蝿?wù)，但是他們的狂妄自大最終會導(dǎo)致整個(gè)系統(tǒng)都崩潰。
這些程序員簡直就是無能，畢竟有些人就是很糟糕。有些開發(fā)人員會將逗號分隔的字符串放入SQL數(shù)據(jù)庫、編寫空的catch塊并使用所有全局變量，雖然這些程序員并不常見，但你有時(shí)候還是會看到它們的。
我想表達(dá)的是，如果你讓我給你提建議的話，那我要提醒你，不要變成一個(gè)心胸狹窄的人。事實(shí)上，當(dāng)你問這個(gè)問題的時(shí)候，就意味著你并不是一個(gè)冷漠或傲慢的人，但人們很容易沾沾自喜。你可以試著去和不同編程風(fēng)格的開發(fā)人員交流。你可以去學(xué)習(xí)一門與眾不同的語言，比如Haskell、Prolog或Clojure。去了解你所使用技術(shù)的替代方案。如果你使用的是Java的話，那你可以去了解一下NET。如果你使用的是jQuery，那你可以去學(xué)習(xí)一下ReactJS。不管怎樣，去學(xué)習(xí)一些新東西。永遠(yuǎn)不要停止進(jìn)步！

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 …

我來舉幾個(gè)例子：
有些程序員認(rèn)為自己是唯一一個(gè)會解讀他們代碼的人。
為什么要用變量名來表達(dá)這些變量的作用呢，如果你可以將它們命名為a1、a2的話，那我就會知道它們是做什么的了，對吧?
他們幾乎從來都不記錄他們自己的代碼。無論是在代碼中，還是在某些wiki或外部文檔中，他們都不會記錄自己的代碼，雖然在這些地方不記錄并沒有什么關(guān)系，但是在某個(gè)地方應(yīng)該有一個(gè)關(guān)于這個(gè)項(xiàng)目的可訪問文檔。無論是功能上的還是技術(shù)上的文檔，都應(yīng)該準(zhǔn)備一個(gè)。
他們認(rèn)為重構(gòu)自己的程序就是在侮辱他們。
為什么要像現(xiàn)在這樣更改代碼呢？因?yàn)閺乃墓ぷ髟砩蟻碚f，更改代碼是有效果的。
好吧，可能你現(xiàn)在一直在使用的方法已經(jīng)被棄用了，他們已經(jīng)被更好的方法所取代了，并且可能很快就會從語言中完全刪除，如果還不更改的話，可能會導(dǎo)致更新語言時(shí)出現(xiàn)問題。
當(dāng)這些程序員進(jìn)行重構(gòu)時(shí)，他們相信他們在代碼中所做的每一個(gè)更改都是“重構(gòu)”。但其實(shí)不是，只有在不改變功能的前提下，實(shí)際所進(jìn)行的改進(jìn)才是重構(gòu)。僅僅只是把代碼修改成具有相同功能的代碼，但讀起來要難十倍，而且維護(hù)起來更困難，這并不是重構(gòu)，這叫做“搞砸”。
他們只理解自己所編寫的代碼，但他們從不試圖理解他們正在處理的這個(gè)項(xiàng)目的上下代碼。
能夠編寫小片段的代碼并實(shí)現(xiàn)它們是很好的一件事。但如果你不知道這些小片段對整個(gè)項(xiàng)目的影響，那就太糟糕了。
他們認(rèn)為自己是優(yōu)秀的程序員。他們的想法通常是“如果這個(gè)代碼是我寫的，那肯定很好”。但通常情況下并不是這樣，如果代碼評審是由同樣糟糕的人完成的，那么它可能真的會投入生產(chǎn)。如果它是由一個(gè)優(yōu)秀的程序員完成的，那么這么做可能是在做重復(fù)地工作，是在浪費(fèi)時(shí)間。
他們要么不測試代碼，要么只測試數(shù)量非常有限的場景，剩下很多未測試的場景。
這樣的例子不勝枚舉……
原創(chuàng)翻譯：龍騰網(wǎng) http://nxnpts.cn 轉(zhuǎn)載請注明出處

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."

他們工作的整個(gè)系統(tǒng)都太復(fù)雜了，以至于他們管理不了。
但更讓我感興趣的是那些努力工作且受人尊敬的開發(fā)人員，因?yàn)樗麄儠ㄟ^一系列合理的決策，慢慢的將自己的雇主拉入技術(shù)這個(gè)大環(huán)境中。
任何長度的工作代碼都是一種重要的智力產(chǎn)物，對于他復(fù)雜性的理解是在單個(gè)大腦所能理解的范圍之內(nèi)的。因?yàn)楸３诌@種理解是很困難的，所以利用自己的理解去做出能夠降低系統(tǒng)復(fù)雜性的改變就變得更加困難了，并且從定義上來說，這種改變并不會帶來任何直接的價(jià)值。
管理員工是一個(gè)非常棘手的問題，因?yàn)樗麄兊墓ぷ魇侵苯犹峁﹥r(jià)值。所以需要大量的勞動(dòng)力，而這些勞動(dòng)力的價(jià)值基本上是無形的，所以這是一個(gè)令人煩惱的難題?？巳R頓 · 克里斯滕森說，許多組織陷入了“要在短時(shí)間內(nèi)獲得可衡量的勝利”的陷阱，并鼓勵(lì)他們的開發(fā)人員用小量或大量的技術(shù)債務(wù)來購買小量的價(jià)值。要意識到這種方法有時(shí)必須要加以抵制，需要一定剛愎自用的精神，還需要一些技巧才能有效地做到這一點(diǎn)。
Steve Yegge的《Done, and Gets Things Smart》仍然是我對這些主題最喜歡的討論。鄧寧克魯格效應(yīng)在對技術(shù)技能進(jìn)行推理時(shí)是一個(gè)首要問題（包括嘗試解析Yegge的文章時(shí)）。
（更新：我更喜歡http://www.quora.com/Computer-Programming/What-qualities-do-really-bad-programmers-share/answer/Kyle-Bahr。）
“他們并不關(guān)心他們是如何編碼的，不管是最佳的實(shí)踐方法、模塊化還是架構(gòu)，他們都不在乎”,“他們不認(rèn)為工作是需要以正確的方式來構(gòu)建事物的，所以他們最終會走捷徑，因?yàn)樗麄儠f：“看，它就是這樣工作的！”，“他們經(jīng)常不考慮代碼的整體結(jié)構(gòu)就開始編碼。”

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

在編寫單元測試或根本不編寫單元測試時(shí)，有大量沒有被發(fā)現(xiàn)的測試用例。
對此的解決方案是：測試驅(qū)動(dòng)開發(fā)。
文檔不足或根本就沒有文檔時(shí)：在編寫代碼的同時(shí)還編寫注釋。在編寫代碼和逐步更新代碼之前先準(zhǔn)備好自述文件。
對于較少的或沒有日志記錄的情況：像上面一樣，應(yīng)該在編寫代碼時(shí)編寫。
對于變量名使用不當(dāng)?shù)那闆r：名稱應(yīng)該就能說明它在做什么。像I =1這種的變量名并不能很好的說明他的作用。
變量名可能會很冗長。如果變量名很長，那么會導(dǎo)致在應(yīng)該“捕獲”異常的時(shí)候無法“捕獲”到異常。
如果不捕獲異常，就會提前結(jié)束工作流程。
我們看不到最終用戶或應(yīng)用程序會如何使用您的代碼。但用戶使用起來應(yīng)該是簡單的。如果你覺得你的代碼很難插入的話，那你就需要重新設(shè)計(jì)了。
工程師必須要像用戶一樣思考。雖然“把東西變的簡單真的很難”，但用戶喜歡簡單。
IDE可以幫助您避免這種情況。
在理想情況下，它應(yīng)該是模塊化和通用的，這樣就可以重復(fù)使用它。寫一個(gè)超過10行的函數(shù)可以分成兩部分。
構(gòu)建類、抽象、接口或特征都可以節(jié)省大量的工作。
當(dāng)參數(shù)可以配置時(shí)，對其進(jìn)行硬編碼，這樣易于維護(hù)和管理。
當(dāng)腦海中浮現(xiàn)第一個(gè)解決方案時(shí)就停下來，然后再花一整天的時(shí)間進(jìn)行所謂的優(yōu)化。
這樣可以節(jié)省一天的時(shí)間。

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?

你應(yīng)該學(xué)會避免的第一個(gè)錯(cuò)誤就是認(rèn)為程序員要么好要么壞。
讓我們想象一下，如果你問：“真正糟糕的程序員有哪些共同的特質(zhì)？”
那么這些特別不好的詞就有一個(gè)共同的特點(diǎn)，那就是它們在錯(cuò)誤的時(shí)間、錯(cuò)誤的地點(diǎn)都使用過。在另一種情況下，一個(gè)特別不好的詞可能恰恰是你需要的詞，你會很感激能隨時(shí)準(zhǔn)備好它。
當(dāng)然也有一些不可挽回的詞，但即使是最糟糕的詞，人們的看法也會隨著時(shí)間的推移而改變，而且在不同的人群中可能會有不同的含義。
如果我們能超越時(shí)間本身，我們就會看到我們的語言改變了它們所傳遞的信息，并會看到人們對其所表達(dá)意思的看法在逐漸演變。
軟件開發(fā)人員必須不斷的努力，在給定項(xiàng)目（或項(xiàng)目的給定階段）的環(huán)境中做正確的事情。
我們必須適應(yīng)，因?yàn)閷ξ覀兊囊笤诎l(fā)生變化。我們必須決定在什么時(shí)候改變我們的想法和行為。
在某種情況下，一個(gè)合理的決定在另一種情況下可能會被認(rèn)為是愚蠢的。
你可能幾乎在工作的每個(gè)方面都表現(xiàn)的很出色，但如果你沒有在適當(dāng)?shù)臅r(shí)間做出適當(dāng)?shù)倪x擇，那你可能會被認(rèn)為是一個(gè)糟糕的程序員。一時(shí)的疏忽可能會損害你多年的勤奮和成功。難道你真的就不好嗎？不，并不是這樣的。那你現(xiàn)在應(yīng)該怎么做呢？

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.

我看到您只是在要求列出一些常見的錯(cuò)誤，例如對變量進(jìn)行調(diào)整以避免踩到另一個(gè)變量，或者什么時(shí)候不使用遞歸等。但是這個(gè)列表太長了，而且變化也太大了，所以不能作為一個(gè)有用的標(biāo)題。
軟件開發(fā)工具和語言都具有邏輯性和準(zhǔn)確性。所以我們要正確的使用它們，否則它們就不起作用。從這個(gè)層面上來看，這就是科學(xué)。雖然這樣做是正確的，但從一個(gè)狹隘的角度來看，它也會產(chǎn)生一種錯(cuò)誤的印象。
在應(yīng)用軟件工具和語言工作的過程中，會經(jīng)常被一系列的“判斷”所打斷，而這些判斷都取決于在何時(shí)何地以及由誰完成。這樣的決定永遠(yuǎn)不會 100% 正確或 100% 錯(cuò)誤。這是科學(xué)所無法企及的，也不應(yīng)該被簡化為一系列該做和不該做的事情。
但是，如果我的反應(yīng)沒有達(dá)到你們預(yù)期的那樣，那我的回答可能會讓您感到失望。
所以我在這里列出了一些被認(rèn)為是糟糕的程序員可能不會做的事情：
從您正在處理的代碼庫中尋找樣式，然后要么遵循它們，要么提出新的方向。
在你的同行中尋找已建立的實(shí)踐，要么采用它們，要么改進(jìn)它們。
做好準(zhǔn)備。準(zhǔn)備狀態(tài)并不是你真正要達(dá)到的狀態(tài)，而是你應(yīng)該不斷去努力的狀態(tài)。
不要假設(shè)既定的需求不會發(fā)生改變。隨著不斷的開發(fā)，需求就會發(fā)生改變。
要像在粘土中建模一樣仔細(xì)的處理您的工作，而不是要在一塊大理石上雕刻出什么東西一樣。努力工作，表現(xiàn)多一點(diǎn)，改變多一點(diǎn)。
好了，這是顯而易見的。現(xiàn)在讓我來提供一些需要思考更多的信息。一個(gè)表面上很糟糕的程序員不會做的事：
要知道，今天有價(jià)值的技能往往是明天被嘲笑的技能。因?yàn)榧寄苁且淮涡缘摹?/b>
原創(chuàng)翻譯：龍騰網(wǎng) http://nxnpts.cn 轉(zhuǎn)載請注明出處