5 ms·

Tidy First?

153 points by ingve 3y ago

Toutouxc 3y ago
Would anyone else recommend the book?
- azemetre 3y ago
  I would under the condition you have never read or heard about refactoring. If you’re expecting thorough techniques, you won’t find them. They’re literally single page chapters where the advice might be “move functions near their argument declarations.” It’s very basic, but the content is quite ever green. It’s something that should be included in every employee handbook and often feels like trying to change SWE culture to one of “fix then ship.” I’m really curious what Beck’s other books in this series will be. I’m about halfway thru, can’t comment on the last third which is different and offers a newish mental model. tldr: Good but expensive for the content amount. Should be $15 IMO.
  - loevborg 3y ago
    It's funny. The last third is where it gets interesting. And then it stops – to be continued in the next volume. Except that Volume I is only 100 pages, and many of them blank.
    - azemetre 3y ago
      That's really exciting to hear. I hope I didn't come across as negative in my view. I am enjoying the book immensely but so far doesn't seem too different than other refactoring books.
- thanatos519 3y ago
  I haven't read it but it sounds like it gives names to and elucidates a lot of the stuff I am doing these days so I will read it soon.
- eweise 3y ago
  Bought it with work money but would be unhappy spending $38 of my own since its pretty short and a lot is common sense. Some good nuggets of info in there though.
  - GuB-42 3y ago
    > a lot is common sense Probably the best compliment one can make of such a book. Common sense tends to be lacking when it comes to coding practices, and books about it don't really help. Instead, they tend to go with practices that are completely detached from reality. Also, things that require unreasonable effort, so that if you don't do it because you are too neurotypical for that, then "you are doing it wrong" and if it doesn't work then it is not the author's fault. And even if it common sense in that that's what every experienced programmer is already doing, then, still great. First because not every programmer is an experienced programmer, obviously. And even if you are, seeing it writing helps with consolidation. So really, you are getting me very interested right now.
  - ghostpepper 3y ago
    I thought a lot of it was common sense too but I've been coding for 15+ years. I wonder how much of it is common sense to someone with less experience.
  - joshka 3y ago
    Perhaps a good metric for how much this should be worth would be to ask whether buying this book for a junior developer with your own money would save you that amount in the long term. Based on the article only, and the amount of times I've personally had to have similar discussions, I'd say it's worth that amount at least (and likely more).
- Brajeshwar 3y ago
  On the pricing that the other comments mentioned, if you happen to have friends coming from India -- it is less than $10 here. ;-)
- actionfromafar 3y ago
  Everything mentioned in the article is obvious to me ... however it has been hard won lessons over years and years and years. Someone more freshly baked could probably get a real nice head start with the advice in the book.
gregdoesit 3y ago
For anyone interested in reading full chapters of the book (all are relatively short!), here are three full ones [1], shared with the permission of the author (Kent Beck) and publisher (O’Reilly). [1] https://newsletter.pragmaticengineer.com/p/dead-code-getting-untangled-and-coupling https://newsletter.pragmaticengineer.com/p/dead-code-getting...
klooney 3y ago
> In many work places, there are high fixed costs (in time and effort) associated with PR reviews. The ideal solution for this, according to the author, is to not require PR reviews for only tidyings. Well that sounds like a loaded footgun.
- CuriousCosmic 3y ago
  I think requiring reduced rigor for housekeeping changes is reasonable but there should 100% be somebody in the loop doing manual reviews for all changes.
IshKebab 3y ago
Seems like mostly good advice that we all learn (well most of us) but is rarely written down. I have to caveat this though: > Therefore, reducing coupling will reduce the cost of change. This seems like unwise advice. People are going to read it as "coupling = bad" and then try to eliminate coupling even between components that are still coupled, through things like dynamic typing, queues and so on. This only reduces the appearance of coupling. For example say you have an API endpoint that is supposed to perform some action in another service. A lot of people would "decouple" them by having the endpoint place a request in some shared Kafka/MQTT queue or a file or whatever, and then the other service can poll that. Tada! Decoupled! Much better than a direct RPC call right? Except they still depend on each other - you've just made the coupling less robust, so it can easily break when you make a mistake refactoring.
- ngcazz 3y ago
  I read the book a few weeks ago and I don't remember the passages very clearly but I definitely didn't get the sense it made blanket judgments on coupling, in fact it appeals to an awareness of weaker, perhaps implicit forms of coupling like you the one suggested.
- throwaway13623 3y ago
  > - you've just made the coupling less robust In my opinion this depends on the use case. If one service has a strong dependency to a different service, it may be a case of "distributed monolith" and they should consider if the functionality should be moved to the original service instead. If two services need to communicate with each other, I don't see how a message queue makes the coupling less robust. What is the difference between sending a message or making a http call? You still have a coupling between the two services. Message queues used right can actually increase operational robustness in my opinion. By placing a message on a queue you get a lot of functionality for free. - You distribute the load automatically so that the risk of overloading a single instance is reduced - You can limit the ingestion flow, so that services only process the data at a rate that they can handle - If a service fails or shuts down, the message remains on the queue for the next instance to retry. You get a lot of retry logic for "free". - You can easily monitor and scale resources based on the processing rate of the queue itself. Some queues can be allowed to grow large during peek hours, because they can be processed during off hours, while others may require scaling up the service capacity to cover a minimum latency requirement. Misuse of message queues may of course lead to distributed monoliths and add a lot of complexity in understanding how data flows within the system. This is not something specific for queues and it's the same for direct HTTP calls. As all things, we need to use the right tool for the right purpose. Actually, one of my pet peeves are internal web hooks. Web hooks are good at notifying an external partner compared to the alternatives, but the complexity is too great to justify its use for internal services as well. Just use a message queue instead for your own services.
aulin 3y ago
Guard clauses, something so simple yet so underrated, you never know how much you love them until you meet people from the single return per function church. It still amazes me how they can believe that putting all the guards in tens of nested ifs can be saner than a few extra returns at the top. And don't get me started on those that goto is bad but it's ok to put everything inside a do while (0) they can break out of and clean up at the end. Sorry for the off-topic rambling, tidying is like "clean" code, everyone has their own definition and sometimes changing code for the sake of making it tidy is more dangerous than just changing the behaviour, especially if it was already tidy by some other people standard.
- DeathArrow 3y ago
  >Sorry for the off-topic rambling, tidying is like "clean" code, everyone has their own definition That's blasphemy. There is only one true clean code and that is what Uncle Bob is preaching himself.
- WesolyKubeczek 3y ago
  Does this church still exist?
  - blowski 3y ago
    I’ve definitely run into its members recently. They tend to have other strange beliefs, like “methods can’t have more than four lines” and “you can instantiate an object only in a factory service”.
    - WesolyKubeczek 3y ago
      I didn't know the Clean Code church was also preaching the single point of return. Single point of return used to be big when Structured Programming was this "newfangled stuff". I'd rather expect some CS professor types smelling of mothballs and shambling about in empty hallways.
  - aulin 3y ago
    Definitely. Let's wait if some adept shows up. I met plenty IRL. One specific case I have in mind I think it came from the company mostly hiring fresh graduates and seniors indoctrinating them with their blind and badly aged structured programming rules.
CraigJPerry 3y ago
“One pile” vs “extract helper” - I like this distinction. This is the main mental model I’ve arrived at for reading Peter Norvig’s style of coding - a style which i can’t help but be really drawn to. I’d understand one pile not as just throw everything in one function but thoughtfully arrange code with surgical precision into purposeful blocks with no noise or distractions. I.e. it’s as much about getting rid of crap as it is about concentrating the line of execution.
- scotty79 3y ago
  I'm fairly certain I used one pile for functions that were broken down to multitude of poorly named ad-hoc helpers. Bringing in the logic into one place then enabled me to eliminate dead code, redundancy and pinpoint bugs that were hidden deep inside helpers but could only be recognized as bugs in the context of the rest of the algorithm. Sometimes veritable forest of helpers reduces to a single short, clear function.
ilitirit 3y ago
Often when I read articles/books with this sort of advice I get halfway and think to myself "Hmmm... I really should write my own book about programming stuff". I'm sure many other senior programmers have similar thoughts.
deleted 3y ago
[deleted]
akoboldfrying 3y ago
>move declaration and initialization together Another, even better reason to do this is to prevent the declared object ever being in an invalid (e.g., undefined or null) state. If it's born in a valid state, and every method call leaves it in a valid state, it's harder for things to go wrong. In the C++ world this approach is encouraged, finding its highest form as RAII: the convention of designing classes to be declared as objects (not references to them), with constructors that leave them fully formed, and destructors that silently and automatically clean them up (thanks to deterministic destructor calls -- one of the best decisions made by the language designers.) Sadly Java prefers the "bean" convention of new-ing up a "blank" object and then calling setAbc(), ..., setXyz() on it. I hope every time you create an object, you remember to call set...() for every field! Including when you add a new field later!
- bzzzt 3y ago
  Current Java practices seem to prefer the 'builder pattern' where you chain a few setter functions and the call a .build() function that returns the object. If a new field is required you can add an assertion in the builder. The 'never and invalid state' pattern has one downside: there always seem to be exceptions in business logic and models so it's very hard to require things to be there 100% of the time. I've seen a system being built over a few years that started with valid objects/hard requirements that were partly removed when business needs and exceptions to the rule became more clear. Those changes caused bugs due to code not handling the null/doesn't exist case. Handling that from the start would have been a lot less work.
  - akoboldfrying 3y ago
    Good point about the Builder pattern. Not a fan of the additional boilerplate but it does give the class developer the opportunity to detect forgotten fields and fail fast.
- augustk 3y ago
  Am I the only one who thinks that code where declarations are mixed with statements is harder to read?
saladdays 3y ago
Bought with work education fund. Read it in a few hours on a flight. Like others have mentioned, it is a lot of common sense, but seeing techniques on paper was useful to me. I learned a few new things and it reinforced the things I have already picked up in my career so far.
jharohit 3y ago
Kent is an amazing guy! Met him a year+ ago at a friend's house and was fantastic to discuss the initial idea he had around this book, which was based on tons of experience at various engineering firms. He has been posting parts of chapters or thoughts in his newsletter for a while now - so it's awesome to see it compiled in one place! Newsletter if anyone wants to subscribe https://tidyfirst.substack.com/ https://tidyfirst.substack.com/

Tidy First?

153 points by ingve 3y ago

Toutouxc 3y ago

Would anyone else recommend the book?

azemetre 3y ago
I would under the condition you have never read or heard about refactoring. If you’re expecting thorough techniques, you won’t find them. They’re literally single page chapters where the advice might be “move functions near their argument declarations.” It’s very basic, but the content is quite ever green. It’s something that should be included in every employee handbook and often feels like trying to change SWE culture to one of “fix then ship.” I’m really curious what Beck’s other books in this series will be. I’m about halfway thru, can’t comment on the last third which is different and offers a newish mental model. tldr: Good but expensive for the content amount. Should be $15 IMO.
- loevborg 3y ago
  It's funny. The last third is where it gets interesting. And then it stops – to be continued in the next volume. Except that Volume I is only 100 pages, and many of them blank.
  - azemetre 3y ago
    That's really exciting to hear. I hope I didn't come across as negative in my view. I am enjoying the book immensely but so far doesn't seem too different than other refactoring books.
thanatos519 3y ago
I haven't read it but it sounds like it gives names to and elucidates a lot of the stuff I am doing these days so I will read it soon.
eweise 3y ago
Bought it with work money but would be unhappy spending $38 of my own since its pretty short and a lot is common sense. Some good nuggets of info in there though.
- GuB-42 3y ago
  > a lot is common sense Probably the best compliment one can make of such a book. Common sense tends to be lacking when it comes to coding practices, and books about it don't really help. Instead, they tend to go with practices that are completely detached from reality. Also, things that require unreasonable effort, so that if you don't do it because you are too neurotypical for that, then "you are doing it wrong" and if it doesn't work then it is not the author's fault. And even if it common sense in that that's what every experienced programmer is already doing, then, still great. First because not every programmer is an experienced programmer, obviously. And even if you are, seeing it writing helps with consolidation. So really, you are getting me very interested right now.
- ghostpepper 3y ago
  I thought a lot of it was common sense too but I've been coding for 15+ years. I wonder how much of it is common sense to someone with less experience.
- joshka 3y ago
  Perhaps a good metric for how much this should be worth would be to ask whether buying this book for a junior developer with your own money would save you that amount in the long term. Based on the article only, and the amount of times I've personally had to have similar discussions, I'd say it's worth that amount at least (and likely more).
Brajeshwar 3y ago
On the pricing that the other comments mentioned, if you happen to have friends coming from India -- it is less than $10 here. ;-)
actionfromafar 3y ago
Everything mentioned in the article is obvious to me ... however it has been hard won lessons over years and years and years. Someone more freshly baked could probably get a real nice head start with the advice in the book.

gregdoesit 3y ago

For anyone interested in reading full chapters of the book (all are relatively short!), here are three full ones [1], shared with the permission of the author (Kent Beck) and publisher (O’Reilly). [1] https://newsletter.pragmaticengineer.com/p/dead-code-getting-untangled-and-coupling https://newsletter.pragmaticengineer.com/p/dead-code-getting...

klooney 3y ago

> In many work places, there are high fixed costs (in time and effort) associated with PR reviews. The ideal solution for this, according to the author, is to not require PR reviews for only tidyings. Well that sounds like a loaded footgun.

CuriousCosmic 3y ago
I think requiring reduced rigor for housekeeping changes is reasonable but there should 100% be somebody in the loop doing manual reviews for all changes.

IshKebab 3y ago

Seems like mostly good advice that we all learn (well most of us) but is rarely written down. I have to caveat this though: > Therefore, reducing coupling will reduce the cost of change. This seems like unwise advice. People are going to read it as "coupling = bad" and then try to eliminate coupling even between components that are still coupled, through things like dynamic typing, queues and so on. This only reduces the appearance of coupling. For example say you have an API endpoint that is supposed to perform some action in another service. A lot of people would "decouple" them by having the endpoint place a request in some shared Kafka/MQTT queue or a file or whatever, and then the other service can poll that. Tada! Decoupled! Much better than a direct RPC call right? Except they still depend on each other - you've just made the coupling less robust, so it can easily break when you make a mistake refactoring.

ngcazz 3y ago
I read the book a few weeks ago and I don't remember the passages very clearly but I definitely didn't get the sense it made blanket judgments on coupling, in fact it appeals to an awareness of weaker, perhaps implicit forms of coupling like you the one suggested.
throwaway13623 3y ago
> - you've just made the coupling less robust In my opinion this depends on the use case. If one service has a strong dependency to a different service, it may be a case of "distributed monolith" and they should consider if the functionality should be moved to the original service instead. If two services need to communicate with each other, I don't see how a message queue makes the coupling less robust. What is the difference between sending a message or making a http call? You still have a coupling between the two services. Message queues used right can actually increase operational robustness in my opinion. By placing a message on a queue you get a lot of functionality for free. - You distribute the load automatically so that the risk of overloading a single instance is reduced - You can limit the ingestion flow, so that services only process the data at a rate that they can handle - If a service fails or shuts down, the message remains on the queue for the next instance to retry. You get a lot of retry logic for "free". - You can easily monitor and scale resources based on the processing rate of the queue itself. Some queues can be allowed to grow large during peek hours, because they can be processed during off hours, while others may require scaling up the service capacity to cover a minimum latency requirement. Misuse of message queues may of course lead to distributed monoliths and add a lot of complexity in understanding how data flows within the system. This is not something specific for queues and it's the same for direct HTTP calls. As all things, we need to use the right tool for the right purpose. Actually, one of my pet peeves are internal web hooks. Web hooks are good at notifying an external partner compared to the alternatives, but the complexity is too great to justify its use for internal services as well. Just use a message queue instead for your own services.

aulin 3y ago

Guard clauses, something so simple yet so underrated, you never know how much you love them until you meet people from the single return per function church. It still amazes me how they can believe that putting all the guards in tens of nested ifs can be saner than a few extra returns at the top. And don't get me started on those that goto is bad but it's ok to put everything inside a do while (0) they can break out of and clean up at the end. Sorry for the off-topic rambling, tidying is like "clean" code, everyone has their own definition and sometimes changing code for the sake of making it tidy is more dangerous than just changing the behaviour, especially if it was already tidy by some other people standard.

DeathArrow 3y ago
>Sorry for the off-topic rambling, tidying is like "clean" code, everyone has their own definition That's blasphemy. There is only one true clean code and that is what Uncle Bob is preaching himself.
WesolyKubeczek 3y ago
Does this church still exist?
- blowski 3y ago
  I’ve definitely run into its members recently. They tend to have other strange beliefs, like “methods can’t have more than four lines” and “you can instantiate an object only in a factory service”.
  - WesolyKubeczek 3y ago
    I didn't know the Clean Code church was also preaching the single point of return. Single point of return used to be big when Structured Programming was this "newfangled stuff". I'd rather expect some CS professor types smelling of mothballs and shambling about in empty hallways.
- aulin 3y ago
  Definitely. Let's wait if some adept shows up. I met plenty IRL. One specific case I have in mind I think it came from the company mostly hiring fresh graduates and seniors indoctrinating them with their blind and badly aged structured programming rules.

CraigJPerry 3y ago

“One pile” vs “extract helper” - I like this distinction. This is the main mental model I’ve arrived at for reading Peter Norvig’s style of coding - a style which i can’t help but be really drawn to. I’d understand one pile not as just throw everything in one function but thoughtfully arrange code with surgical precision into purposeful blocks with no noise or distractions. I.e. it’s as much about getting rid of crap as it is about concentrating the line of execution.

scotty79 3y ago
I'm fairly certain I used one pile for functions that were broken down to multitude of poorly named ad-hoc helpers. Bringing in the logic into one place then enabled me to eliminate dead code, redundancy and pinpoint bugs that were hidden deep inside helpers but could only be recognized as bugs in the context of the rest of the algorithm. Sometimes veritable forest of helpers reduces to a single short, clear function.

ilitirit 3y ago

Often when I read articles/books with this sort of advice I get halfway and think to myself "Hmmm... I really should write my own book about programming stuff". I'm sure many other senior programmers have similar thoughts.

deleted 3y ago

[deleted]

akoboldfrying 3y ago

>move declaration and initialization together Another, even better reason to do this is to prevent the declared object ever being in an invalid (e.g., undefined or null) state. If it's born in a valid state, and every method call leaves it in a valid state, it's harder for things to go wrong. In the C++ world this approach is encouraged, finding its highest form as RAII: the convention of designing classes to be declared as objects (not references to them), with constructors that leave them fully formed, and destructors that silently and automatically clean them up (thanks to deterministic destructor calls -- one of the best decisions made by the language designers.) Sadly Java prefers the "bean" convention of new-ing up a "blank" object and then calling setAbc(), ..., setXyz() on it. I hope every time you create an object, you remember to call set...() for every field! Including when you add a new field later!

bzzzt 3y ago
Current Java practices seem to prefer the 'builder pattern' where you chain a few setter functions and the call a .build() function that returns the object. If a new field is required you can add an assertion in the builder. The 'never and invalid state' pattern has one downside: there always seem to be exceptions in business logic and models so it's very hard to require things to be there 100% of the time. I've seen a system being built over a few years that started with valid objects/hard requirements that were partly removed when business needs and exceptions to the rule became more clear. Those changes caused bugs due to code not handling the null/doesn't exist case. Handling that from the start would have been a lot less work.
- akoboldfrying 3y ago
  Good point about the Builder pattern. Not a fan of the additional boilerplate but it does give the class developer the opportunity to detect forgotten fields and fail fast.
augustk 3y ago
Am I the only one who thinks that code where declarations are mixed with statements is harder to read?

saladdays 3y ago

Bought with work education fund. Read it in a few hours on a flight. Like others have mentioned, it is a lot of common sense, but seeing techniques on paper was useful to me. I learned a few new things and it reinforced the things I have already picked up in my career so far.

jharohit 3y ago

Kent is an amazing guy! Met him a year+ ago at a friend's house and was fantastic to discuss the initial idea he had around this book, which was based on tons of experience at various engineering firms. He has been posting parts of chapters or thoughts in his newsletter for a while now - so it's awesome to see it compiled in one place! Newsletter if anyone wants to subscribe https://tidyfirst.substack.com/ https://tidyfirst.substack.com/