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.
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.