6 ms·

I think almost every programmer would benefit from reading "Refactoring". It sharpened my skills quite a bit, and I was already experienced before encountering

I think almost every programmer would benefit from reading "Refactoring". It sharpened my skills quite a bit, and I was already experienced before encountering the book. The book was an easy read and was an efficient use of my time. I expect that rewrite in Javascript will further improve the information density.

jammygit 8y ago
The seller apparently needs my address to sell me an ebook, and it thinks my postal code is fake and locked me out. Well played, Pearson.
- luckydata 8y ago
  Fraud detection. You could be using a stolen credit card, address helps with that.
  - jhayward 8y ago
    Also tax computation, and sometimes trade regulations.
kristiandupont 8y ago
I bought the book ages ago and remember not really finding anything of value in it. I don't mean to sound like someone from /r/iamverysmart but I recall thinking I would benefit in the way I did from the design patterns book: by giving me terminology for things I already did. But as far as I remember, the names were really obvious ("rename parameter", "extract method", etc.) and the instructions equally so. Can you give an example of something you learned from it?
- quietbritishjim 8y ago
  I remember having exactly the same experience, including the anticipation that I would benefit from it the way I would from Design Patterns. For most of the refactorings in the book, a bullet point in a list would've seemed a bit excessive, never mind a step-by-step sequence of instructions. In the end I literally threw the book away – the only technical book I've ever done that to. I distinctly remember one of the things in the book, which in retrospect isn't even really a refactoring, called something like "null object". The idea was that if you were going to return null from a function (e.g. get student by ID but that ID doesn't exist) then you could instead return a concrete singleton object that represented null. That way, if you forgot to check for it then at least your program wouldn't crash. Now, the merits of this idea are debatable and I don't think I've ever used it in the years since. But I strongly remember thinking at the time that it was the only idea in the book that wasn't totally obvious. There was a good chapter early on about testing, which I think was my first exposure to that idea. It was a bit brief but that's not a surprise given it was a bit of a digression from the main topic. A whole book on that might've been quite a bit more interesting.
  - myth_buster 8y ago
    Null Object Pattern https://en.wikipedia.org/wiki/Null_object_pattern https://en.wikipedia.org/wiki/Null_object_pattern
    - endgame 8y ago
      Thinking more about this, null object are meant to be neutral with respect to some behaviour, but that behaviour isn't really specified alongside the object. It seems like it's a weaker reinvention of the idea of an "identity element" from e.g., the `Monoid` typeclass. I say "weaker" because `Monoid` specifies the neutral element (`mempty`) alongside the behaviour (`mappend`), whereas the null object pattern does not.
  - dennisgorelik 8y ago
    > if you forgot to check for it then at least your program wouldn't crash If I forgot to check for null (or missing data) then I would rather have my program to raise an exception (to prevent data corruption). Then my error handling code will email that exception to me. I will analyze exception message (NPE) and stack trace. Then I will fix my program and deploy it to production.
    - Too 8y ago
      Depends on the context. In game engines it's quite common to just render a generic pattern when a texture could not be found, instead of crashing the whole game. That's a good use for this pattern, not so good example would be in a bank transaction backend.
  - paulddraper 8y ago
    Ay ay ay. This is basically a workaround for a defect of certain typed programming languages that allow null everywhere. Worst mistake of computer science. https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
    - 8y ago

jammygit 8y ago

The seller apparently needs my address to sell me an ebook, and it thinks my postal code is fake and locked me out. Well played, Pearson.

luckydata 8y ago
Fraud detection. You could be using a stolen credit card, address helps with that.
- jhayward 8y ago
  Also tax computation, and sometimes trade regulations.

kristiandupont 8y ago

I bought the book ages ago and remember not really finding anything of value in it. I don't mean to sound like someone from /r/iamverysmart but I recall thinking I would benefit in the way I did from the design patterns book: by giving me terminology for things I already did. But as far as I remember, the names were really obvious ("rename parameter", "extract method", etc.) and the instructions equally so. Can you give an example of something you learned from it?

quietbritishjim 8y ago
I remember having exactly the same experience, including the anticipation that I would benefit from it the way I would from Design Patterns. For most of the refactorings in the book, a bullet point in a list would've seemed a bit excessive, never mind a step-by-step sequence of instructions. In the end I literally threw the book away – the only technical book I've ever done that to. I distinctly remember one of the things in the book, which in retrospect isn't even really a refactoring, called something like "null object". The idea was that if you were going to return null from a function (e.g. get student by ID but that ID doesn't exist) then you could instead return a concrete singleton object that represented null. That way, if you forgot to check for it then at least your program wouldn't crash. Now, the merits of this idea are debatable and I don't think I've ever used it in the years since. But I strongly remember thinking at the time that it was the only idea in the book that wasn't totally obvious. There was a good chapter early on about testing, which I think was my first exposure to that idea. It was a bit brief but that's not a surprise given it was a bit of a digression from the main topic. A whole book on that might've been quite a bit more interesting.
- myth_buster 8y ago
  Null Object Pattern https://en.wikipedia.org/wiki/Null_object_pattern https://en.wikipedia.org/wiki/Null_object_pattern
  - endgame 8y ago
    Thinking more about this, null object are meant to be neutral with respect to some behaviour, but that behaviour isn't really specified alongside the object. It seems like it's a weaker reinvention of the idea of an "identity element" from e.g., the `Monoid` typeclass. I say "weaker" because `Monoid` specifies the neutral element (`mempty`) alongside the behaviour (`mappend`), whereas the null object pattern does not.
- dennisgorelik 8y ago
  > if you forgot to check for it then at least your program wouldn't crash If I forgot to check for null (or missing data) then I would rather have my program to raise an exception (to prevent data corruption). Then my error handling code will email that exception to me. I will analyze exception message (NPE) and stack trace. Then I will fix my program and deploy it to production.
  - Too 8y ago
    Depends on the context. In game engines it's quite common to just render a generic pattern when a texture could not be found, instead of crashing the whole game. That's a good use for this pattern, not so good example would be in a bank transaction backend.
- paulddraper 8y ago
  Ay ay ay. This is basically a workaround for a defect of certain typed programming languages that allow null everywhere. Worst mistake of computer science. https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
  - 8y ago