The "Antipatterns" section of the site is the verbatim text of "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" [1], which is one of my all-time favorite books, but doesn't seem to credit the original at all. Is this site ripping them off?

[1] https://www.amazon.com/AntiPatterns-Refactoring-Software-Arc...

thread

hgaMar 2015

"No list like this would be complete without a book about design patterns."

If this is true, then no such list is complete without the Antipatterns book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...).

The thesis is that if good software, projects and teams are noted for using good patterns, then bad versions of any of the above will be marked by bad patterns, and one won't have the other. This can also be a lot more useful in practice, since we seldom get complete greenfields to play in, and therefore antipatterns with prescriptions to fix them more often match what we find in the real world.

I note there are a number of other antipatterns books; this was the original, and now seems to be back in print without needing any changes are updating.

thread

mhomdeMar 2015

If anyone hasn't read it I highly recommend the book "Antipatterns" (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...

... or just google antipatterns.

My personal pet peeve is that many programmers don't refactor nearly often nor thorougly enough. It should be natural part of the developing process. Especially with large programs you reach certain points where all encompassing refactoring is needed to simplify the code, yet many power through leading to a bloated mess.

I've found its not uncommon that even decent complex code can be shrunk 70%-80% using refactoring, code generation and config files.

thread

hgaJul 2010

One of the reasons really like and recommend the Antipatterns book (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...) and approach is that it starts with the identification of a bad pattern (this author's complaints are at a higher level, though) and ends with recommendations on how to re-mediate it.

As you indicate, based on this article it's hard to see Mr. Rainey providing constructive help, and for that matter I wonder what he's trying to accomplish with this screed. I suppose that's consistent with it, the major takeaway is "don't get involved with this person or his firm!"

thread

hgaMar 2010

See my other comment on how anti-patterns are supremely useful when you're working in a brownfield (existing subpar codebase, project, etc.) and you need to recognize the problems and having suggestions about how to fix them is very helpful.

You can also try reading the anti-patterns book for an introduction to many of the most important ones, or rather books: http://www.amazon.com/s?index=blended&link_code=qs&f...

Although I can only vouch for the tremendous usefullness of the first: http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...

Hmmm, I think it went out of print but it's back.

thread