@stainlesssteellemming
12:08 "A politician level when it comes to rhetoric" ... Absolutely. I was kicking around and quite active in the OO and Patterns communities back in the 90s. I've been involved in numerous discussions with people like Bob, Kent, Ward, John Vlissides, etc from the early days of XP. (For context, I used Rational Rose when it came on a single 3.5" floppy). You need to remember that Bob Martin is primarily someone who provides training and books, not who actually writes code for a living. He tried consultancy for a while (Object Mentor was his firm), but that didn't last. If you were to trawl through the old usenet archives like comp.lang.c++ or comp.object from that era, you would simultaneously see him developing the skills and others getting pissed off with him. He's a classic example of one of the tragedies of Software Engineering. Methodologists are the televangelists of the industry. Look at what has happened to agile itself. Today, at least in the valley, it is much less a way to develop systems, than it is a way to sell books, consultancy, and training. I speak as someone who has seen (and used) everything from Jackson (COBOL in the 70's), through Yourdon in the 80s, XP and the explosion of OOA/OOD and design patterns in the 90s and, currently, Agile.
@Tekay37
One of the interesting aspects of Uncle Bobs parts is that he basically goes through his talking points he uses almost 1:1 in his talks and presentations. As he got to the end of his talking points, he claims to not have much more time for the discussion.
@optimizt8555
Great video. If the point of "Clean Code" is that it optimizes the experience for the developer, then I find in many cases it falls into the "premature optimization is the root of all evil" camp. Early in my career I saw lots of services containing eight layers of abstraction through three different modules with everything dependency injected through magic XML configuration, and at the time I was inexperienced and accepted that it's just "what you do to keep things clean and extensible." The code was "clean" in the sense that yeah, if we wanted to inject new functionality we easily could; it would probably be a dream for the developer that would add that code. Years went by and nothing was added; the code as it stood was fine and served the hyper-specific business need that it did. All the "cleanliness" did was make it harder to reason about in the future. Any changes we did end up making were in the business logic ends of the clean code abstractions; we would've lost nothing if the business logic ends were just directly connected because we only ever had one or two implementations of any abstracted away subunit.
@64jcl
Bob should try to measure how much jumping around the code a programmer has to do in order to actually read a piece of code when its spread in a gazillion functions and files. Believe me, it's a nightmare every time I join some project where I do not know the code to try to figure out how stuff works. My editor has like 30 tabs open just to read a red line of execution and I have no idea which one I put the breakpoint in and if I press the wrong tab, how to find my way back. If anything I had to learn to use the development tool way better than I did before. My rule is, I only separate stuff into a function if I see that two methods need this with a minor variation that I can pass as a parameter, if not I never bother as it takes the code out of where it is actually used. I recently did a Javascript game engine for educational games that supports 5 different game types. I have 9 files. One for a "from the ground up" developed game framework doing all the dom manipulation using plain Javascript, one for the actual game engine implementation using this and one for each game style. There is also one html file (never touched as it has one container tag), and one css file. Believe me, to work with this is extremely simple and I can actually have all my source open in the editor and know where everything is. I use the editor scope collapse all and can practically see every function title in one screen height to quickly find whatever I am going to work on. I have fun and enjoy coding whenever I work on this, and is facing depression every time I have to join some 2000 source files project. Also not using any framework whatsoever is such a great feeling of achievement, plain Javascript, html and css. No mucking about trying to get around whatever someone else did in some endless node_modules pit.
@DetectivePoofPoof
I remember watching two an hour and something long talks by Uncle Bob some time ago and I remember how during the whole thing everything sounded about right, but then when it was over I was left with : "Ok so what do I take away from this? I don't feel like I've learned anything of substance that would help me make better software, but it sounded nice while he way saying stuff." That's when I started thinking this was the scam. He IS exactly a politician, goes up, says a bunch of stuff, sounds good enough, but doesn't actually say anything worth a damn. At some point he mused on how "people weren't doing solid or object-orientation right" and that back when him and whoever else were doing stuff they had a different idea of how to actually do it and I was like "Oh ok then, uncle, please enlighten us HOW DO we use this the currect way exactly?" but he didn't elaborate. Now Casey, on the other hand I've seen some of his stuff and I was able to actually take away some real, tangible lessons that improved the way I do things a bit. So if its a matter of any kind of dispute between the two I'm on Casey's side simply because I tend to agree with the things hes saying and I've built a very poor opinion of uncle Bob over the years.
@steshaw6510
You're right about the rhetoric! It's everywhere. Right on front of the book is this manipulative beauty: "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.". Translation: either obey our rules or be expelled from the industry!
@GarrethandPipa
been programming for 45 years. Bob is a salesman he is arrogant enough to argue his point even when he is wrong. Most programming practices are religious in feel and inquisition in policy. The only thing I care about is speed and the amount of time spent to achieve that speed.
@Lightstrip
Uncle Bob is a real pro at what he does, which is very good for him... Probably unfortunate for programming community.
@hareepjoshi
Bob's livelihood, his persona and his ego all revolve around Clean Code. He will defend it by any means possible.
@dukereg
20:40 An overengineered bridge made to take 10 ton trucks might take a 15 ton truck without failing, but "overengineered" code rarely has the analogous quality. "Overengineered" code would usually be better called "overcomplicated", "oversized" or even "overwrought" đ
@bitskit3476
There are several problems that I have with TDD. One is that to have full test coverage on any module, you need to create numerous tests for every state transition, and a singular module can have many states. Take for example, a simple stack. Test case 1, you need to check all of the member variables to make sure that the stack is initialized properly. Test case 2, you need to check the top stack item to make sure that the program sanely handles doing so on an empty stack. Test case 3, you need to attempt to pop the stack to make sure that the program sanely handles doing so on an empty stack. Test case 4, you need to attempt to push the stack and ensure that the stack depth is properly increasing afterwards. Test case 5, you need to make sure that the item that's currently on the top of the stack is equal to the previous item. Test cases 6 and 7, you need to repeat test cases 4 and 5 to make ensure that successive pushes are working properly. Test case 8, you need to keep pushing stack items until the stack buffer is resized and then verify that the items in the newly resized buffer are all correct. That, or just to an isolated test of the stack resizing procedure. Test case 9, you need spoof the alloc function and replace it with one that fails so that you can ensure that the stack resizing function gracefully handles a failure to allocate more memory. Test case 10, you need to make sure that the item pushing also gracefully handles a failure to resize the stack buffer when needed. Test case 11, you need to pop an item off the stack and make sure that the stack depth changes appropriately. Test case 12, you need to make sure that after a pop, the new top of the stack is correct. Test case 13 and 14, you need to repeat cases 11 and 12 to ensure that successive pops work correctly. A stack is quite literally the simplest data structure I can think of, and yet, bar minimum, we're looking at 14 test cases with probably around 400 lines of code to test something that can be implemented in like < 10 lines of code. Imagine now, doing this for a more complicated object that has 20+ different states. If you did this for an entire project, 99.9% of your codebase would be nothing but tests. And you're spending potentially hundreds of hours writing code that doesn't actually deliver any features. This then leads to my second gripe, which is that the second you need to change the structure of any object or the behavior of any function at all, you need to throw out all of your old tests and write new ones. It immensely slows down the development process. Third, there's just the simple fact that many things aren't easily testable. Consider, for example, that you're writing a triangle rasterizer based on the Bresenham algorithm. How do you test whether or not the triangle splitting is working correctly? Do you sit down with pencil and paper, draw a diagram, work out the linear interpolation for binary floating point, and compare your hand calculated value with what the computer does for a mock triangle? Maybe. Well how do you check that there are no gaps in the seams between triangles? There's problems like this all the time, where the easiest way to test it is to just run the program and look at it with your own eyes. And keep fiddling with the algorithm until it seems like it's doing the correct thing.
@mynameistrez
Regardless of anything else, Martin not having watched Casey's entire video before their talk is WTF
@jurgentreep
Iâve seen both of them on YouTube. Didnât know there was a âfightâ between them going on. Do agree with the other people here after watching Martins video I felt like I learned nothing and after Caseys I felt like I did learn something.
@handmadegamesdev
A person's writing reflects the clarity of their thinking. In other words, writing is thinking. I'm glad this discussion was put into writing because Martin's convoluted writing perfectly captures the nebulous, unclear thinking around "Clean Code." I am so glad to see this type of discussion get more spotlight. It can only lead to good things as more programmers become aware of these other perspectives. You guys are putting into words those misgivings so many of us have felt for years but couldn't articulate. Keep at it!
@YonoZekenZoid
watching video. it's interesting. as an FYI, in OOP, a dependency is any interface (class, type, etc with public members) that you pass into another member (class constructor, method, property, function, etc) to be consumed by said member. dependency inversion simply means the dependent member will depend on the interface of said dependency, rather than a concrete type, which you can then move downward in the hierarchy. Also (now getting towards the end of the video), dynamic polymorphism is not the same as inheritance. you can have polymorphism without inheritance (using composition), and most of the people I know who have tried it (myself included), prefer it over inheritance.
@onetruetroy
âClean Codeâ is one of those buzz phrases that really doesnât mean much. As a programmer, there are some nice ideals defined but are only doable in certain situations. Clean Code is a nice selling point to lure managers whom have poor coding skills in forcing the programmers to endure the courseware with promises of efficiency, productivity and readability. If the programmers canât do this after taking the course then obviously they arenât putting the proper skills into practice. Letâs invite Uncle Bob to see whatâs wrong. â The cleanest code Iâve written or read is when the programmers communicate and agree on practices that work best for the projects. Of course, some of the code may look dirty but it gets the job done. Yes, the documentation can sometimes have an essay on why this particular âdirty codeâ is necessary.
@batlin
I saw Casey's video when it came out and it was a breath of fresh air. Having started programming in Basic, C and assembly in the 1990s before going to university, I didn't really get the draw of SOLID principles which grew and grew in hype. After many years working with over-abstracted "clean" codebases it was great to see someone point out how much of those practices are backed by unvalidated subjective assertions.
@vbachris
the audience of each philosophy is VERY important. "Uncle" Bob's main audience is business/enterprise developers where most code is modeling business processes that are added to and changed constantly. Where structure is king, clearly delineated boundaries of logic are needed. Where, historically, you deal with very poorly written and highly confusing procedural code baked into form code behind files in upwards of 10k lines. These are some of the core motivations for creating a culture of "clean code." Where OLTP transaction "performance" is a secondary concern to having very readable extendable code.
@johnterpack3940
Applying the Clean Code mindset to basically any other field shows how insane it is; "We need to design cars so that they are easier for mechanics to work on, how they perform is secondary." Code exists to solve a problem for an end user. It isn't an art project. The only priority is allowing the end user to solve their problem as quickly and easily as possible. If that requires intricate code, so be it. Programmers aren't any different from plumbers, carpenters, or factory workers in that it's literally your job to deal with the complicated bits.
@travisthompson1679