He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
Functions that only do one job
Testing makes refactoring easier
The standard SOLID OOP stuff.
Tech debt is bad
Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
Insulate yourself from change
Duplication is bad
Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
Don’t mix high level code with low level.
Build solid Entity classes to model the data and their interactions.
Don’t write multithreaded code if you don’t have to.
If you have to do your best to write it so they don’t share memory.
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
Refactoring is expensive and the cost is often not justified.
Premature abstraction is the absolute devil
You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
Less changes also lead to less bugs.
Too much emphasis on functions being few lines of code instead of just being simple.
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
I’m going to suggest not using an ORM. I used three so far and it really likes to tell you what you can and can’t do when query builders can do the same thing by creating the SQL string for you. SQL is also very nice and easy (just parameterise all inputs to avoid the SQL injection)
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.
The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.
That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.
He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
It’s literally what an orm does, and it’s good enough for 80% of apps out there. Using it for the wrong purpose is what’s silly.
I see. It seems like you may be one of the people that try to coerce relational models into nosql stores like Dynamo.
Or course it’s possible. They even trick you into thinking it’s a good pattern by naming things “tables”.
But if you’re using Dynamo to its fullest an ORM is not going to be able to replicate that into a relational store without some fundamental changes.
Hence 80%.
Most apps out there are a CRUD with a thin layer of logic.
If you are in the 20% that needs real performance, an ORM is not gonna cut it, no matter what DB you have.
I’m going to suggest not using an ORM. I used three so far and it really likes to tell you what you can and can’t do when query builders can do the same thing by creating the SQL string for you. SQL is also very nice and easy (just parameterise all inputs to avoid the SQL injection)
While he advocates for it, that’s also a point that Martin brings up multiple times when he talks about his project “fitnesse”.
Basically saying that they left it open how stuff can be saved, but the need has never arisen to actually pivot to a different system.
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.
The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.
That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.