Clean Code - Uncle Bob / Lesson 4

[@camilohernandezruiz2776]

I just replicated the example in Dart. I learned a couple of things: 1. You must have an intermediate level of using the language. 2. Every testing environment is pretty much the same. Still, the conventions used by the Dart test library and the different Exceptions-related objects are different than those used in Jest, so you gotta know them all as well. 3. The KISS principle is the most important one. Don't advance too much further, every time you write something, run the tests. Keep refactoring and running at the same time until the all tests pass. This is the moment when you use all your brain. I also collected every tip/rule Uncle Bob explained about TDD in this video: 1. You are not allowed to write any production code until you have first written a test that fails because the production code doesn't exist. 2. You are not allowed to write any more of a unit test than is sufficient to fail - and not compiling is failing. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 4. Engage as few brain cells as possible, you will need them later. Keep it simple! (KISS) Don't do too much too fast. 5. Try to avoid the core (the golden behavior) of the problem until it is unavoidable. Save the most important feature of it for as long as possible. 6. If you think some code you just wrote is a wrong solution... prove it! Put it to a test. 7. You are not allowed to make the production code more specific than the tests. The tests and the production code must move in opposite directions. Every new test you add makes the test code more specific, more constrained. Everything you do to the production code must make it more general.

[@jaymandell6034]

I wish they would show the screen as he's writing/talking

[@abstractapproach634]

Totally agree, in one of the earlier ones he was asking for an analysis and instead of showing code it showed uncle Bob drinking water?!

[@TranscendentBen]

H2O. :)

[@gajbooks]

Again, captured from a livestream quite clearly. Blame the people editing the capture on-site, not the channel.

[@abstractapproach634]

@@gajbooks i don't see where anyone specified who's at fault.

[@gajbooks]

@@abstractapproach634 I've seen some other comments actively disliking the video because of this, which they have every right, but... Come on. I listened to this series as a podcast and lost no information.

[@JavierRuizGonzalez]

Don't you love when a lecturer shows that they are able to actually put the theory in practice? Also, you can feel how knowledgeable is a guy by counting the number of times he mentions other colleagues. Thanks for these sessions, to the organizers and to the editors!

[@robrick9361]

Yes cause implementing a stack is super difficult. Pushing and popping can be confusing, they both start with p, super difficult to get right.

[@wolverine9632]

There's so much invaluable information in these lectures. Test-driven development was a completely foreign idea to me, but interestingly, when it was first mentioned in Lesson 3, my brain clicked and I _sort of_ saw it inside my mind. I was thinking of the fact that I always have introduced new structs/classes by definition first, followed by implementation. My reasoning was that, "If I design the blueprint first, it will be easier to implement." But I realized this is backwards from what it should be. I should attempt to create an instance of the object, and when that fails, then and only then should I add a declaration for the class. Now I add a call to the non-existent member function, and only after it fails to compile do I implement the function. This way I will automatically develop the class interface in the way that makes the most sense, adding everything as needed, rather than creating an entire implementation before realizing that interacting with it is a real chore. Turns out, this isn't exactly what Uncle Bob meant, but it's well on the right track.

[@HeikkiKetoharju]

This was the best demonstration of TDD I've seen to this day. Really inspiring!

[@TheChillBison]

Here's another good one: kzbin.info/www/bejne/aJOUp5adlL2GiJo

[@headoverbars8750]

Man... I struggled to wrap my head around this discipline until the demonstration. I have seen many demos but non clicked like this. Game changing Book/Series the demonstration for TDD was icing.

[@devsquaredTV]

dear uncle bob, youve been an amazing source of happiness since i discovered you last week

[@yapayzeka]

this dude is legend

[@motamedi_programmer]

Yes Really I Want to meet him One Day

[@PaulSebastianM]

Reminds me of George Carlin... Another legend. The George Carlin of software comedy.

[@unitycoin_original]

0:00 Opening. 0:51 Honest Estimates / What is the chemical formula of water? 7:16 Selection, Secuence and Interaction / No innovations have been made in the software for decades. 13:48 The Hardware has gone crazy!: comparison between the innovation level of hardware and software today. 17:33 You to say "No". 21:40 Test-Driven Development / TDD rules. 36:14 Our code is a document / Double entry Bookkeeping. 40:22 About inheritance / Mutation Testing. 43:48 Demo of Test-Driven Development. 1:12:23 Some tips to learn and practice Test-Driven Development. 1:15:03 Questions and Answers.

[@abstractapproach634]

You can tell your a programmer, you spelled sequence wrong. I think, unless I'm missing something.

[@-parrrate]

"Secuence" -- Sequence "Interaction" -- Iteration

[@GauravSehrawat8888]

Probably pin this comments?

[@aimafirm]

With all the comments everywhere on youtube, it can't possibly be that hard to realize that one should show the code being written and not the presenter.

[@maxfun6797]

Tbh, you don't need to see the code to understand the subject.

[@ryanvogel5895]

@@maxfun6797 You do need to understand the subject to edit the video. You might not need to see the code, but others might need or want to.

[@ugochinwokonko4373]

@@maxfun6797 Ǹj

[@wolverine9632]

"Hey, this video isn't syncing properly with the audio!" "Can't you just scale the video to match it?" "Nah, I'll just cut out parts every now and then to resync it."

[@CPalanysamy]

This video made all the difference when it comes to understand TDD. Thank you uncle Bob

[@jamesnewton6139]

to Uncle Bob: amazing lecture, these principles are absolutely required, to produce good code. however, to make this a 1000 times better, if you have the power and see this, get the video editor to re-edit and show the code. Extremely frustrating to watch you talk about details of code and write something, but nobody can actually see it.

[@georgestampolidis9511]

Revisit this a year or two later

[@ivangloff]

What do you mean? It’s still frustrating. The demo at 45:30 is a good example.

[@ivangloff]

@@a.luckyy The contents of what is not being shown is irrelevant.

[@ivangloff]

@@a.luckyy It isn't, otherwise I would not complain. And it is not relevant. Nice that you hired a producer. Next time hire one that will do the job properly.

[@FranciscoMNeto]

Beautiful lecture, abysmal editing.

[@GerbenWijnja]

I like to think of this flow of test driven development as continuously proving that there are bugs. Prove that's there's a bug (a.k.a. missing or broken feature) with a test, then fix it. Then prove another bug, and fix it. Until you can't think of any other bugs.

[@igorbolotnikov975]

Very nicely put!

[@Matheus.Richard]

Which resembles the previous talks where he talked about science proving things.

[@hanswoast7]

@@Matheus.Richard Yes and no. Scientific hypothesis cannot be verified or proven, only falsified. But if you fail to falsify them in a myriad of ways, you can assert these hypothesis "good enough". That's when a scientific hypothesis receives the great honor to become a scientific theory.

[@Matheus.Richard]

@@hanswoast7 that's what I was refering to. You can't prove your code is 100% right, only that it isn't wrong.

[@alext5497]

@@hanswoast7 that seems to translate to code fairly well. I don't see the contradiction

[@TheInimicus]

I watched this lessons 3 times now, and everytime I learn something new.

[@GongonHD]

Some of my key take-aways: Avoid switch statements that cause a lot of dependencies. (That might hurt the open-close principle) A function should only do one thing. This means: when you can seperate a part of the function into another function it does more than one thing. By doing this you do not get a sea of lots of tiny functions because you will start to properly name them, put them into classes and modules automatically. Variables likes 'isWebPage' that say what the content of the var, are great. Making the code work is only half of the job. Refactoring so it is clean and easy for others to read is the second half. Programmers are slowed down by needing to understand others code. And if it is not clean and easy to understand this really piles up. Clean code does not pay off in the short run but definetely in the long run.

[@milanmidzovic6841]

I don't know anything about programming but I enjoy his lectures.

[@fluffydeveloper]

44:15 Bob: *singing* The subtitle: don't eat it eat it eat you know

[@moganmark]

An absolute legend, thank you for posting

[@samuellourenco1050]

Loved the way he wrote a correct code just based on tests and expected behaviour.

[@BenjaminBK]

Seriously, the "director" responsible for choosing the scenes for this whole task deserves a raise. Either he is a genius and does not show us what Uncle Bob shows on the screen, so the YT viewer starts to think "what should I see" and starts using their brain, or he is so occupied by his sidejob he has to do while this is recorded that he fucks up that much. If none of this is true, get him a new job and find someone who has more than two braincells and does not put uncle bob on view while there is something shown on the projector

[@OleguitoSwagbucks]

44:16-44:19 Video Editor that did that cut, thank you so much, I love you

[@rushi7312]

During previous videos of the talk, I was very attracted by the idea of testing everything you do. But as a beginner programmer this was really overwhelming lol.

[@StefanH]

The problems I have with testing code is once you start interacting with other systems. GUIs are probably the most common example, but as soon as you start interacting with other people's APIs, it becomes increasingly harder to test. The best solution is to mock those external APIs in your unit tests, but it's way harder to do that, and try to emulate their backend. It's by no means impossible! I just find that the most difficult bit when I write code, which often interacts with other systems.

[@Qrzychu92]

For that there is a solution, but beware, we are slosing in on CorporateFizzBuzz :) You put an abstraction over the external system. In your unit tests, you mock the abstraction. You test the abstraction with integration tests, or even system tests against a real system.

[@prajwalpradhan661]

He really got me interested in TDD.. What a great lecture.. Thank you so much for this

[@Name-lt2tz]

after I tried tdd, I am interested in it only in few cases. In most of cases from my experience it is waste of time. Code changes so much, you do not even know how it should work, and for everyt thing need to write tests and throw them away once you find that way written code will not work. For writng stack class as he did, maybe it is ok. BUt how often we write simple things like this? Most of the time things are so complicated so thats why we do not even know if this will work.

[@Dethas1991]

@@Name-lt2tz That's why you need a clean code, to create correct abstractions that are easily testable. Every complicated problem can be deconstructed into few simple ones.

[@mechpeanut]

I think the reason that the test driven development, at least how uncle Bob demonstrated, requires multiple iterations of - fail the test, intentionally make a buggy implementation to pass the test, and add more tests to make it fail again - multiple times is to strengthen the quality of tests first until the code owner reaches to a point where the owner truly believes a buggy implementation is no longer capable of fooling the tests. Then the rules allow the owner to write real production code to make the test passes. At this moment, what we end up with is a strong test suite that can significantly boost the development velocity all the way down the road. And I believe that's the spirit and rationale behind the scene. (Thoughts popped in my head at 1:04:44)

[@mechpeanut]

On the other hand, the problem with this approach is that it cannot be measured. If it cannot be measured, it can only be promoted from a cultural perspective. And if we do that, most likely this is ineffective because it does not scale. Why does it not scale? Because we cannot provide automation support (CI/CD) for unmeasurable thing. So at the end of the day, this principle is probably gonna be something that we can only keep it to ourselves. But still, a very interesting testing methodology indeed!

[@manishm9478]

My teammates are all exceptionally good at debugging. It took me until I was 10 months into the job to realise this was why I'd had so much trouble trying to do TDD, or pair programming, or continuous delivery - the code was too monolithic and tightly coupled for TDD, and the team had grown so used to this they just gave up and debugged everything. I fully agree with Bob that debugging is not a desirable skill for a developer, because by the time you need it you've already failed to engineer a good system.

[@shapedsilver3689]

I want to t-shirt that says “my tests pass, so damn you!” Lol

[@greenlampshade8909]

Depends greatly on how those tests were developed. "...so TDDamn you!"

[@Ashalmawia]

that's cool how being "stupid" on the implementation side forces you to come up with more creative tests

[@Dalendrion]

It kind of makes me think of emergent behaviour. Many agents with stupid simple rules, working together, result in some emergent behaviour. Boids have three rules. I call them attract, avoid, align. And they start behaving in interesting ways. Tests also have three rules. Arrange, act, assert. And as a flock, they too have some interesting behaviour.

[@MalgosO]

I want the introduction to be 50 minutes, this guy is amazing

[@TheJP100]

Smart guy, this lecture taught me more than I would like to admit. The camera should show whats important to the viewer however and who ever made the decision to show Bob ALL THE TIME when the focus was supposed to be shifted to his work, should 100% stop working as camera-douche and apply for a simpler job!

[@TheNewton]

Some good meme material in this series like his coder stance jutsu.

[@lionelleroux1132]

I would love a pair programming session with Uncle Bob

[@Sinebeast]

Those digressions at the start are really cool :)

[@snky1987]

The only terrifying thing is that there is millions of us (programmers) but still only couple of thousands will see these videos :scream: :D

[@zandark88]

Its terrifying that you think other programmers should watch this

[@fabs4058]

@@zandark88 please enlighten us further with your wisdom

[@Detroit_Playa]

I’m just finally starting to take programming serious and watching this hopefully I can start off doing it the right way

[@casperes0912]

"Who else has a problem like that. What other field; What other employment has a problem like that, where they construct documents that are arcane and every symbol has to be correct" Me: "Wizards?"

[@TheNewton]

Print

[@mistalan]

Physicists

[@MrDoboz]

exactly my reaction lol

[@TodorescuProgramming]

that stuff to write a test then write the code makes sense... I mean you're forced to think of functions that take input, produce output or sideeffect ...

[@sergiocoder]

There is a borrow checker in Rust, isn't it something new?

[@elbanj]

For some reason I imagine he also rocks on the electric guitar.

[@dimitarkarazapryanov9710]

Well, the water dipole negative charge is on the Oxygen atom's side. Anyway, it's always refreshing to learn something unexpected during those lectures. :)

[@dmitripogosian5084]

Yep, it is funny how you can invent what seems an easy explanation, and then get the result that is opposite to what really happens

[@unitycoin_original]

Many people just read titles, and dont read all the text of papers, quantum computer is just vaporware. Uncle bob is very clever 13:26

[@harpywraith9017]

My favorite stand-up comedian

[@n0MC]

Folks, relax. Yes the videographer should show the screen but you can get the entire content with audio only. I listened to this entire series on a couple of long car rides.

[@drhhusain]

disliked ... for editing this video, there is no relation between bob's laptop screen while he is writing the code. it just frustrated me

[@rossgeography]

dubbing is off too

[@GerbenWijnja]

yeah well you can kinda guess what he's writing, so it's ok. In my opinion.

[@gajbooks]

This is captured from a livestream and reuploaded. You're free to dislike, but don't blame the uploader for things they physically don't have access to.

[@GeorgeTsiros]

@@rossgeography at 3:50 it glitches and syncs... i hope it doesn't sync out again later >_

[@kemsekov6331]

As he said. You'll be even more frustrated.

[@cedrics7374]

44:02 when he said he’ll do a demo, I almost cheered 🥲

[@ankitsood1088]

Should we write use TDD when writing Acceptance test cases .. ergo should there be a unit test case testing the acceptance test cases or would it be a overkill?

[@MrDoboz]

that's a funny idea. While we are at it, let's write unit tests for the unit test, I mean would you bet your life on the Assert class? I sure wouldn't

[@licriss]

In theory the code itself should validate the acceptance tests, and where the code isnt available but you still need to develop acceptance level tests, you create mocks However some acceptance tests cover such wide and complex workflows that having unit tests for those is valid, this is very uncommon though and you'll often find it under "bad practices" as a claim that the test are too wide, I completely disagree with this but you wont find many references to back up my argument as acceptance testing has evaded deep study for the most part

[@Adiounys]

If he is not going to put all those intros finally into some working anti-gravity model or some other cool thing, I will be pissed off...

[@Chiramisudo]

What's most obnoxious is that this is the best presentation of this lecture I've found, and yet, in a spectacular failure it was uploaded in a mere 720p in an era of 4k. Bob isn't going to be around forever y'all, but his wisdom is timeless. DO IT JUSTICE AND CAPTURE IT PROPERLY!!! 😒😞

[@Ozzah]

21:49 - I'm curious what you guys think about TDD for greenfield projects. Specifically, projects where scope/requirements are likely to change. If you need to implement a small to medium feature inside an existing project, TDD sounds like an amazing idea. What happens when you're starting a new and highly complex project with lots of parts, lots of requirements, lots of code, and you can expect that you will re-write the code 3-4 times by the end of it, not because the code is bad, but because the requirements/scope has changed. In this case, I see TDD as less useful and more of a waste of time, since you are writing tests for code that will end up being culled anyway. The only thing that Bob said that would seem useful in this case is that writing tests in TDD mode is more fun than having to write tests at the end.

[@peddfast]

You're describing the exact point in time you want to use TDD. TDD particularly excels when the specifications change and you have to rewrite code. Rewriting code with TDD is like writing code with TDD, except you can be sure that most of the system still works if you do large changes. Tests are specifications of what you want the code to do. If the specifications changes, you change the tests. If you have to rewrite code with existing coupling, it would be very beneficial to use TDD. If you've ever spent a long time on a greenfield project you will likely notice that maintainability and extensibility goes down the drain the more code you write. Uncle bob explains in one of these videos the fear of writing code some developers experience with long running systems. I have myself been involved in long running projects where the parts that were written early without tests are the no mans land of the code, it's were you dread to go in fear of destroying the system.

[@canbilgeyilmaz]

Watch his other videos on architecture. If you rewrite code 3-4 times over, that might mean too much dependency in your code - i.e. your codebase should be so decoupled that you only need to change a few things at a time to modify or expand functionality. He does not use inheritance much, if at all. Relies on polymorphism to invert dependencies, etc.

[@Ozzah]

​@@canbilgeyilmaz code is rewritten several times over because we're solving difficult problems, and we need to experiment with different approaches, see how they work in practice, experiment with how they scale, work through all the known unknowns and discover the unknown unknowns, etc. It's not a problem with coupling.

[@daniels3980]

3 to 4 times is not that many, It is not that uncommon for a key method or a sql query to be modified over 100 times in a few years timespan, including code that is written for TDD, and not. Not every method mind you, but some. When you start a new job it is good to query git to find the methods that are changed the most of and have git bring it back in order of the count of the number of changes. Those are often the key methods. This sort of stuff about them never changing is more for school than industry. Otherwise we would be writing Word documents in the same app that was used in Windows 3.1

[@vasylstolyarchuk6226]

The best men uncle Bob.

[@alext5497]

Wow. Im actually having a rage reaction at the editing

[@paviad]

I got a question, what if you write a test for a function, and then you end up refactoring that function, and extracting other functions from it. Do you then have to write tests for the extracted functions? Or do you have to write tests for the extracted functions before extracting them? Either way feels like writing test "after the fact" as it were. What is the common practice in this case?

[@BarryMichaelDoyle]

Theoretically using TDD you would write tests for the functions you are going to extract, and THEN you extract them. Initial test won't need to change (if it fails it means the function was refactored incorrectly.

[@AdrianLParker]

@@BarryMichaelDoyle if the function is moved from one class to another, the original test very much has to fail (and could never work). Because the original test is now calling a function in a class which doesn't have that function, and possibly never will, by design. I'm a bit confused by his whole line of thought starting at 1 hour 20 minutes.

[@Daveduddle]

Really nice series! Just one thing where I strongly disagree: there should always be time to learn the stuff you need for work IN YOUR WORK TIME (he spoke about learning TDD in your free time before bringing it to work)

[@pmro]

You know why, go to client and say that You want to learn new stuff during work time so they will pay for it 😅

[@sergiocoder]

@@pmro if you work for a company they should pay for you to learn new stuff if it's related to the job

[@ignorantandblind]

Is this video an alternative to reading his book?

[@ViktorEngelmann]

Prolog actually becomes one of the best languages there are... as soon as you really understand it.

[@garryiglesias4074]

Pure C without preprocessor, is the REAL way to go. It's obvious.

[@igorswies5913]

@@garryiglesias4074 wait so you want to keep all code in one file?

[@garryiglesias4074]

@@igorswies5913 Yeah of course, that's the challenge for the "real" programmer isn't it ? (I am sarcastic... I disagree with the idea of "best languages" even if it's "one of"... Language should be/are domain specific, what is good in one situation can be bad in another one. It's always a matter of context.)

[@igorswies5913]

@@garryiglesias4074 I actually made one small project as a challenge where pretty much everything would be in the main function (yes you can declare classes and structs in functions in C++, as well as lambda functions)

[@garryiglesias4074]

@@igorswies5913 I know, I heavily use that for "anonymous callbacks". I program since 1989, and did some "hardcore" stuff when I was a teen, assembly, software renderer (raster/raytracing), dos extender, etc... I've nothing against "dirty hardcore" when it's for fun an practicing... Or some niche situation, embedded systems or exotic hardware. But I will use Haskell if it makes more sense.

[@jakubk7158]

31:30, 32:30, 36:55, 39:35, 1:24:42 - groups to learn

[@TheWarTurkey]

Air hi-five to all the other programmers here who program the double-entry bookkeeping!

[@immalkah]

I hate that they don't show the screen while he's working on the laptop much. It is much more useful than just seeing his face. Otherwise great series.

[@mohammadazeem7228]

1:11:20 i am wondering that you people are laughing while coding... I wish i also could do that! Uncle Bob you're legend ❤️

[@sagarjoshi8444]

Can we refer manual tets cases from QA and write aut or integration test for it, is it a good practice ??

[@BryonLape]

I don't think they young lady understood Bob's answer. I hope she got clarification later.

[@GeorgeTsiros]

well, if she reads the comments, she might be able to clarify what exactly she meant, i think there was a misunderstanding? Also, keep in mind that during the lecture, your brain is overloaded with all of the stuff that is happening, plus the psychological loading of talking to bob. I'm not saying he is scary or anything, just that it is exciting. I respect that she asked, clearly, in a language not her own.

[@jackofnotrades15]

Man, I wish I could do this kind of development in my interview coding rounds...😅.

[@violetjellyfish2089]

Потрясный мужик. Смотрела бы и смотрела)))

[@zolv]

Implementing a stack is very efficient. Good luck implementing a Mars lander code using TDD this strict way. See You in year 2134...when You finish implementing the stack.

[@wolverine9632]

See you when your implementation fails because of that one overflowing rounding error in that one counter in that one function in that one class in that one library that controls the gyroscopic sensors.

[@bazooka712]

@@wolverine9632 that is the trade off. As a system gets linearly more complex, the amount of tests become exponential. That is just how things are.

[@SantaClausdtm]

What happens if you build your system on one test that was designed false. Would your whole system be false?

[@redbread6852]

How'd ya code in c++ on Intellij IDEA CE? Is this a Mac/Ultimate feature? The one plugin I found is outdated

[@alexo4600]

"i'm on a mission to kill all braces" "i want lisp to be the last programming language" yeahh right

[@RaffaeleCastagno]

It's just me or the video is constantly out of sync, and re-synced every now and then?

[@leonardkupper5057]

You’re right. Feels like with every lesson of this lecture the editing becomes worse.. At least the good talk makes up for it.

[@RaffaeleCastagno]

@@leonardkupper5057 seems like the video is slightly faster than the audio, so it had to compensate from time to time. Great lessons tho.

[@hosseinamiri1516]

First, If you are not going to use a switch-case statement, maybe he said in previous videos, please use the if-elseif-else structure to make sure that the compiler and then the processor is not struggling with many if statements when checking relative conditions. Second, writing tests before coding is a good practice when you are a senior developer or at least an experienced one, who decouples every part wisely. As a junior developer keep calm and write tests after you realize what to do. DO NOT KILL YOUR MOTIVATION AT THE BEGINNING BY WRITING TESTS.

[@victordrouinviallard1700]

The parachute parabolla should be replaced by a submarine one :D

[@Name-lt2tz]

interesting idea about extracting to new classes but not writign tests for new clases because old test should still cover. Yes, that should make tests not fragile, but test becomes very complicated. Lot of setup to get till that deep code which you are testing. So looks same as if code would not be extracted - I know lot of setup is required to test big function which is not extracted into small classes.

[@TruthNerds]

4:50 I have a comment which is OT, as is the intro. (Don't get me wrong - I love it!) The claim that it's about the ions and not about the dipole moment was at least popularized by KZbinr Veritasium. Just a week or so ago, another KZbinr called Thunderf00t (a British chemist) thoroughly debunked these claims. Well, not entirely, ions do play a role but the dipole moment alone is sufficient, as he demonstrates with substances other than water. As far as I understand it, water autoprotolyzes and is therefore never free of ions, even if it's demineralized, so to show that ions are not necessary, different dipolar liquids are best used.

[@BienestarMutuo]

The extratetrrestrial "that have spaceships with antigravity", say that our understanding of electromagnetism and matter is all wrong.

[@TruthNerds]

@@BienestarMutuo That may well be… but if they started explaining it to us properly, would we be able to understand a word? 😄

[@BienestarMutuo]

@@TruthNerds A good teacher guides you to gain knowledge for yourself. A bad teacher gives you the knowledge and makes you dependent on the teacher. they are a lot more smart that us, but we (the humans) are a lot more powerful (in potency).

[@THEMithrandir09]

Can anyone link a github repo that does TDD exactly like he describes it around 29:00.

[@lcppproductions7910]

The only issue with this is that if the compile times are long you're not gonna want to hit compile every single time you make a change. I guess you could change the build target and isolate dependencies so it doesn't take forever, but Idk exactly how this would work with a large system.

[@Follyaxel]

By applying Uncle Bob's other principles like SOLID, especially the Dependency Inversion principle, which allow you to minimize dependencies and thus the classes/components/modules that need to be recompiled

[@TheTigercore]

Not being able to see the code is painful. Why am I staring at a guy writing code?

[@somebodyoncetoldme1704]

couldn't the sound be synced with the picture?

[@GRHmedia]

Close but no cigar on the Alpha Centauri comment. 4.1x10^23 not 22.

[@DavidWoodMusic]

The contrast between the cringe of the intros/editing and the quality of the content is astounding.

[@avimehenwal]

Can anyone please post the link to uncle bob pair programming with Sandro Mancuso 15 hrs youtube video series he talked about at 1:18:50 ? If they are on youtube?

[@JoyfulJabber]

They are for sale at cleancoders.com/series/comparativeDesign and do not appear to be on KZbin.

[@paxvostrum4824]

Could anybody recommend lectures like these 6, from Uncle Bob or anyone else as good as him (if there is one 😁)??

[@alext5497]

A bunch of nerds drooling over best practices and good organization. I love it

[@AdrianLParker]

@1:22:26 I don't understand this. Your test calls a function on a class, if that function is removed from the class during the refactoring process, then your test will fail. How do you refactor your classes, without breaking all of your tests which call the functions in those classes which end up being refactored? Has anyone an example? Unit tests are very tightly coupled to the class methods they test, how could they not be?

[@MrDoboz]

what, you would refactor push or pop out of the code, or what do you mean? also how else would you test a class? You have no way of interacting them other than through it's methods. And if you rename a method for example, the test is a good warning that you may have to rename it somewhere else too. but if you don't need the method for example, you don't need the test anymore either. so then what's your problem?

[@AdrianLParker]

@@MrDoboz listen to what he said at @1:22:26 and then read my question again

[@AdrianLParker]

@@MrDoboz exactly my point, but the video seems to say contrary

[@irmaosver]

You should write your tests on the public methods and not the private methods. That's the implicit part.

[@emilhuseynli]

Mr. Robert C. Martin, hope you'll read this some time. The statement about not mapping unit test class to corresponding production class was very surprising to me. Why not maintaining 1:1 mapping? If you extract some new class out of existing production class, isn't it possible also do same thing with corresponding test class? After all, it's unit testing (and classes are units most of the time) so why having a single test class which covers multiple production units? It's very confusing...

[@BienestarMutuo]

Sorry to say, but we just edit the video, this is his blog: blog.cleancoder.com/

[@lucasdarianschwendlervieir3714]

kzbin.info/www/bejne/e4uTZphterKCgq8 This video is excellent at explaining the problem with highly coupling production code to test code.

[@emilhuseynli]

@@lucasdarianschwendlervieir3714 This guy and the company/team where he worked had really issues with writing clean understandable tests which test behaviour and not implementation. Having 1:1 association between production class with corresponding test class has nothing to do with coupling. Extensive and careless use of mocking framework to test every implementation detail - that is coupling and is main focus in that video.

[@lucasdarianschwendlervieir3714]

@@emilhuseynli But if you have 1:1 association between production class and a corresponding test class there are many refactoring steps you could that that would break these tests, and you you have to throw them away and write new tests for the refactored code. If a change in one part of the system breaks another (in this case a refactoring in production breaks tests), that's what I would call coupling.

[@emilhuseynli]

@@lucasdarianschwendlervieir3714 Which refactorings? Rename, move? Both are very good supported by modern IDEs and if you do refactoring to a production class (e.g. move to another package) then IDE will take care of corresponding test class and there's no overhead. If you e.g. split a class into two classes you clearly change behaviour and it's perfectly fine to invest some time to adapt the tests to cover new set of behaviours.

[@AZ-bu7ss]

Thanks

[@RSFeed]

51:56 out thru the nose comes the hot tea flying!

[@RSFeed]

1:00:16 I´m not drinking any more tea untill this finishes...

[@PNadav183]

44:00 - little did the know they are about to see a demo of a test driven DEVELOPER rather than the actual development. smh.

[@TheChillBison]

Here's a good one where you can see the developer and the code at the same time: kzbin.info/www/bejne/aJOUp5adlL2GiJo

[@Kitsune_Dev]

Sound is faster than light

[@romanext921]

Very nice demo 😅

[@MiseryKira]

Does rly java "compiles"?

[@wolverine9632]

For everyone ranting about the "camera guy," I would like to point out that there are multiple cameras, and only one editor.

[@Денис-ж3ф5р]

10:30 Hello from an iOS developer :)

[@worldshaper1723]

I created a new language called the intuition code. This might be the golden language. I need seed capital. Who should I talk to.

[@unitycoin_original]

Friend, please give us a brief, and please a comparison with the jai language. Thanks. [e-mail] We believe (we can be wrong) that a programming language must have: - composition instead of inheritance - modules instead of encapsulation - first class functions instead of methods - records for mutable state

[@csbnikhil]

Rust's Ownership & Borrowing were new, I thought.

[@albertmarashi3666]

They are

[@NadChel1]

They don't write Stacks in production, though

[@rockstarjazzcat]

"No." The period goes inside of the quotation marks. :)

[@rockstarjazzcat]

"Programmer!!!" Lol.

[@michelgent7419]

He got the water dipole reversed (not critical but fyi..)

[@rainaldkoch9093]

Yes, due to the empty orbitals at the other two vertices of the tetrahedron.

[@Name-lt2tz]

I want to see that experiment with 45 volts :) I do not want to spend money doing that

[@zolv]

How is this possible that a developer who implements a stack's tests knows exactly how does a stack work but the same developer implementing an actual stack doesn't know anything and doesn't do the job right? It's not frustrating, it's illogical. And no, it was not the test who forced You to implement a stack. Science and engineering worlds achieve much more trying to do the proper implementation and test it after is roughly done, than the opposite (TDD). An engineer needs to ask Yourself: do I want the business logic to be implenented or do I want my tests to pass? A real engineer implements the logic looking for possibilities to solve a problem. A fake engineer does nothing more than fulfilling tests looking for excuses when an implementation fails (aka: "Not my fault, tests pass!") This fits perfectly to Pareto's rule. A good developer can fulfill 80% of a logic just by implementing it even without tests. A TDD actually concentrates on these 20%. Why? Because if a developer concentrates on making tests pass, the tests has to cover 100% use cases Otherwise such a weak developer will find a hack to fulfill the test and not to fulfill the logic. Trying to cover 100% use cases by tests also fits to Pareto's rule. 20% of tests cover 80% of the logic. But You spend 80% of time trying to cover these 20% of logic. It's not efficient at all. If You think TDD (in the pure form) is efficient, why don't we write a tests only and leave the actual implementation to genetical/evolution algorithms to do the job? Let's run it 1000 times (generations) and at some point we will get an implementation which makes tests to pass. My bet is that the genetical algorithm solution will concentrate exactly on this one job: make tests to pass and NOT implement the logic. This is broken by design and brings actually more harm than helps.

[@drcl7429]

If AI will take the jobs of programmers, what you describe is how it will happen.

[@florenckaf]

Whoever decides which camera angle or the slides will be displayed in the video stream and when, really sucks at this task.