TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Anti-Patterns Every Programmer Should Be Aware Of

242 点作者 willk大约 10 年前

22 条评论

ffn大约 10 年前
I like how the first three or so anti-patterns are in the exact opposite direction as the last three or so. The art of being a programmer is literally &quot;don&#x27;t waste time over-thinking things, but also don&#x27;t ship under-thought trash&quot;. For all our fixation on simplistic and ease of use, programming is actually incredibly difficult and way more art than science.<p>And it&#x27;s exactly this requirement of masterful manipulation of balance that makes me love this field so much and long to get better at it. Getting a handle on the artsy spirit of programming is really what separates the wheat from the chaff in terms of programmer skill. There is no formal programmer guild in real life, but if there was, and there was some sort of test a journey-man programmer must undergo in order to become a master programmer, it would be the test of being given a large project and then deciding correctly exactly how much technical debt to take on to be able to ship a product within a reasonable time-frame and yet have its internals not be complete unmanageable spaghetti.
评论 #9524156 未加载
评论 #9522992 未加载
评论 #9524392 未加载
chriswarbo大约 10 年前
&gt; Fear of Adding Classes<p>I&#x27;ve seen this a lot, and is often made worse by attaching a load of unnecessary baggage&#x2F;repurposing to classes.<p>For example, I&#x27;ve worked on PHP projects which, over time, have gained coding standards like:<p>- All classes should be in separate files, named to match the class name<p>- All classes should be built from a PHPSpec specification<p>- All classes should have their own test class<p>- No class can instantiate another, unless it&#x27;s a &quot;Manager&quot; class which does only that. Everything else is dependency injected.<p>- Test classes can only instantiate their associated class; everything else must be mocked<p>And so on.<p>Now, each of these has its merits, but as each new practice was added, it increased the &#x27;fear of adding classes&#x27;, even if just subconsciously. Refactoring to break up classes became less and less common, since a simple code change would require:<p>- Whole new test classes (OK)<p>- New files (seems a bit like Java-envy, but OK)<p>- Injecting new instances wherever the old class was used (seems a bit overkill...)<p>- Mocking the behaviour of the first class in tests for the second, and vice versa (this is getting a bit silly...)<p>- Creating &#x27;Manager&#x27; classes to instantiate the new classes (hmm...)<p>- Creating new test classes for these managers (erm...)<p>- Mocking the dependencies of the managers...<p>In the end, it was just far easier to just throw all new logic into existing classes, which grew and grew.
评论 #9524070 未加载
jammycakes大约 10 年前
I always get a bit nervous when I see Knuth&#x27;s quote about premature optimisation. While the points the author makes are valid, the fact that it gets bandied about as an out-of-context sound bite results in a lot of code getting written with a complete disregard for any optimisation whatsoever.<p>Another far more common antipattern that isn&#x27;t mentioned here is premature abstraction. You see a lot of this in enterprise .NET codebases -- such as the widespread &quot;best practice&quot; to build ineffective and obstructive abstraction layers &quot;just in case you might want to swap out Entity Framework for a web service.&quot;
评论 #9523102 未加载
评论 #9523417 未加载
评论 #9524134 未加载
评论 #9523142 未加载
评论 #9526759 未加载
评论 #9523956 未加载
评论 #9523535 未加载
评论 #9523135 未加载
评论 #9523197 未加载
评论 #9524396 未加载
评论 #9527359 未加载
评论 #9523786 未加载
lugg大约 10 年前
If you&#x27;re a dev and have never read these two wikipedia links, I highly recommend it.<p><a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Code_smell#Common_code_smells" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Code_smell#Common_code_smells</a><p><a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Anti-pattern#Examples" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Anti-pattern#Examples</a>
评论 #9522879 未加载
评论 #9523052 未加载
sulam大约 10 年前
You forgot the most important anti-pattern of all:<p>&quot;Not Invented Here&quot;.<p>The urge to rewrite things that you encounter is strong in software engineers, and you should always be suspicious when you find yourself thinking &quot;I could do this so much better.&quot; Especially when it&#x27;s true!
评论 #9522867 未加载
评论 #9523045 未加载
评论 #9523333 未加载
fsloth大约 10 年前
I think example 9. (the stack that wraps a linked list) is not a necessarily an antipattern. Removing degrees of freedom and adding obvious constraints make systems simpler and easier to comprehend.
评论 #9523472 未加载
arbsn大约 10 年前
Surely the purpose of the LabStack example is to restrict the interface of a LinkedList to that of a Stack? Defining a new type to present a more restricted interface is not useless... it helps one reason about what has or hasn&#x27;t been done to an object.
评论 #9522962 未加载
erikb大约 10 年前
I&#x27;m a little confused. I&#x27;d say that an anti-pattern is something one can avoid. Sure, I can think about every optimization I&#x27;m doing, and if I already know well enough that I&#x27;ll need it and doing it right. But I can&#x27;t really avoid discussing about something that is unimportant in my eyes, because the person who will discuss about it usually thinks it&#x27;s important. I&#x27;d say that in the &quot;bike shedding&quot; regard my anti-pattern would be that I ignore some complaint as unimportant because I still don&#x27;t understand it well enough.<p>Other things are also hard to avoid by myself, like<p>- God Classes (I could refactor here, but then the anti-pattern is fear of refactoring)<p>- Management by Numbers (I&#x27;m not a manager, what can I do about it? Actually I&#x27;m happy if my management is already that good that they have numbers. Nothing is more horrible than management who doesn&#x27;t tell you explicitly what they want and then complains about details for half a year, then starts with the next project without declaring the last one to be finished or anything. I&#x27;d say numbers are good, finding the right ones is tricky, though.)<p>- Useless classes are avoided by simply not writing them? No, they develop when code gets refactored and nobody had looked at the responsibility of that specific class for some time. Nobody writes classes without having a goal for them in mind. Mostly calling methods of another class is fine. It happens in design patterns like Observer, Delegator, or Compositor.
kristopolous大约 10 年前
I read this many years ago. Let me find the source.<p>Edit: I can&#x27;t find it. Anyone else remember reading this? The mysql job queue reference was from a popular article that went out about it at the time<p>Edit 2: the job queue article is from 2011.<p>Edit 3: still can&#x27;t find it. But I know every part of this article before seeing it ... I tested myself and remembered all the details... Where is this thing from?<p>Still can&#x27;t find it. My confidence in the permanence of the web is pretty destroyed right now. I can&#x27;t even find references to it existing.
评论 #9522785 未加载
Hermel大约 10 年前
How could they forget premature generalization?
评论 #9523034 未加载
Kiro大约 10 年前
&gt; God Class<p>I don&#x27;t understand how to avoid this even if you break it up in smaller classes. You still need a point of entry where the logic begins and where it is decided which components to use. ThIs always means some kind of Manager or Main class for me. How do I fix it?
评论 #9522974 未加载
评论 #9523100 未加载
aidos大约 10 年前
Enjoyed this list. Over the years I&#x27;ve become better and better at spotting these issues, but even still sometimes it&#x27;s hard to see them creeping up on you.<p>The worst for me these days is analysis paralysis. I&#x27;m currently working on my own so I don&#x27;t have anyone around to bounce ideas off. For smaller tasks it&#x27;s not a problem, but there are bigger design decisions that have ended up taking longer than probably should. When you&#x27;re left to figure them out on your own it takes a lot longer to convince yourself of the &quot;better&quot; way of doing something.
评论 #9523488 未加载
jongdubois大约 10 年前
&quot;It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.&quot;<p>Great quote - It reminds me of the story of when Michelangelo unveiled the statue of David, someone asked him how he managed to create such a masterpiece and Michelangelo answered &quot;It was simple, I just chipped away all the rock that wasn&#x27;t David&quot;.
评论 #9524709 未加载
techar大约 10 年前
Is <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Facade_pattern" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Facade_pattern</a> a God class? I like the idea if it only delegates to other classes. Its downside is the dependencies to many classes.
acbart大约 10 年前
#5 is a classic example of the Expression Problem[1]. Are you trying to add more shapes or more functions that operate on shapes?<p><a href="http:&#x2F;&#x2F;c2.com&#x2F;cgi&#x2F;wiki?ExpressionProblem" rel="nofollow">http:&#x2F;&#x2F;c2.com&#x2F;cgi&#x2F;wiki?ExpressionProblem</a>
paulus_magnus大约 10 年前
Having worked for big corporations in Europe, I&#x27;d like to see manager types spend 10% of time technical people spend on self-optimising themselves, their working environment, post-mortems, understanding antipatterns, productivity etc.
dvh大约 10 年前
Most of the evil done in my company seems to be by Ctrl+C Ctrl+V and then changing 1 line of code.
评论 #9523507 未加载
NoMoreNicksLeft大约 10 年前
Half afraid to read this, I think they might be our programming conventions at work.
Sami_Lehtinen大约 10 年前
It&#x27;s nice to notice that top three actually does not have anything to do with programming. Those are absolutely general issues when ever doing anything at all.
dmichulke大约 10 年前
Isn&#x27;t it blasphemy to quote <i>Greenspun&#x27;s tenth rule</i> right after insisting in two consecutive rules that people create enough classes?
评论 #9525342 未加载
smegel大约 10 年前
&gt; &quot;Magic Numbers and Strings&quot;<p>I don&#x27;t know about this one...we need something have a chuckle (or cry) about over beer after work, and to make sure software archaeologists in 100 years time have an interesting job (not to mention plenty of opportunities to write blog-spam)!
评论 #9522807 未加载
评论 #9522747 未加载
allan_s大约 10 年前
for<p>&quot; Writing a task scheduler for your web-server in PHP&quot;<p>Is the author talking about &quot;at&quot; and &quot;cron&quot; instead ?
评论 #9522836 未加载
评论 #9522779 未加载
评论 #9525923 未加载