I wish they would show the screen as he's writing/talking
@abstractapproach634
4 жыл бұрын
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
4 жыл бұрын
H2O. :)
@gajbooks
4 жыл бұрын
Again, captured from a livestream quite clearly. Blame the people editing the capture on-site, not the channel.
@abstractapproach634
4 жыл бұрын
@@gajbooks i don't see where anyone specified who's at fault.
@gajbooks
4 жыл бұрын
@@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.
@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.
@wolverine9632
3 жыл бұрын
"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."
@yapayzeka
4 жыл бұрын
this dude is legend
@mahdimotamedi6812
3 жыл бұрын
Yes Really I Want to meet him One Day
@PaulSebastianM
3 жыл бұрын
Reminds me of George Carlin... Another legend. The George Carlin of software comedy.
@FranciscoMNeto
4 жыл бұрын
Beautiful lecture, abysmal editing.
@JavierRuizGonzalez
4 жыл бұрын
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.
@HeikkiKetoharju
4 жыл бұрын
This was the best demonstration of TDD I've seen to this day. Really inspiring!
@TheChillBison
3 жыл бұрын
Here's another good one: kzitem.info/news/bejne/k5hn3JedmIqEhW0
@GerbenWijnja
4 жыл бұрын
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
4 жыл бұрын
Very nicely put!
@Matheus.Richard
4 жыл бұрын
Which resembles the previous talks where he talked about science proving things.
@hanswoast7
3 жыл бұрын
@@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
3 жыл бұрын
@@hanswoast7 that's what I was refering to. You can't prove your code is 100% right, only that it isn't wrong.
@alext5497
3 жыл бұрын
@@hanswoast7 that seems to translate to code fairly well. I don't see the contradiction
@aimafirm
4 жыл бұрын
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
2 жыл бұрын
Tbh, you don't need to see the code to understand the subject.
@ryanvogel5895
2 жыл бұрын
@@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
3 жыл бұрын
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.
@devincustodio2258
2 жыл бұрын
dear uncle bob, youve been an amazing source of happiness since i discovered you last week
@jamesnewton6139
3 жыл бұрын
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
2 жыл бұрын
Revisit this a year or two later
@ivangloff
2 жыл бұрын
What do you mean? It’s still frustrating. The demo at 45:30 is a good example.
@ivangloff
2 жыл бұрын
@@a.luckyy The contents of what is not being shown is irrelevant.
@ivangloff
2 жыл бұрын
@@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.
@unitycoin_original
5 жыл бұрын
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
4 жыл бұрын
You can tell your a programmer, you spelled sequence wrong. I think, unless I'm missing something.
@-parrrate
3 жыл бұрын
"Secuence" -- Sequence "Interaction" -- Iteration
@GauravSehrawat8888
3 жыл бұрын
Probably pin this comments?
@headoverbars8750
4 жыл бұрын
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.
@GongonHD
3 жыл бұрын
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.
@CPalanysamy
3 жыл бұрын
This video made all the difference when it comes to understand TDD. Thank you uncle Bob
@fluffydeveloper
3 жыл бұрын
44:15 Bob: *singing* The subtitle: don't eat it eat it eat you know
@moganmark
3 жыл бұрын
An absolute legend, thank you for posting
@milanmidzovic6841
3 жыл бұрын
I don't know anything about programming but I enjoy his lectures.
@BenjaminBK
9 ай бұрын
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
@TheInimicus
2 жыл бұрын
I watched this lessons 3 times now, and everytime I learn something new.
@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!
@samuellourenco1050
3 жыл бұрын
Loved the way he wrote a correct code just based on tests and expected behaviour.
@OleguitoSwagbucks
8 ай бұрын
44:16-44:19 Video Editor that did that cut, thank you so much, I love you
@StefanH
2 жыл бұрын
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
2 жыл бұрын
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.
@Ashalmawia
3 жыл бұрын
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.
@rushi7312
2 жыл бұрын
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.
@prajwalpradhan661
2 жыл бұрын
He really got me interested in TDD.. What a great lecture.. Thank you so much for this
@Name-lt2tz
2 жыл бұрын
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
2 жыл бұрын
@@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.
@manishm9478
8 ай бұрын
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.
@snky1987
4 жыл бұрын
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
4 жыл бұрын
Its terrifying that you think other programmers should watch this
@fabs4058
3 жыл бұрын
@@zandark88 please enlighten us further with your wisdom
@Detroit_Playa
3 жыл бұрын
I’m just finally starting to take programming serious and watching this hopefully I can start off doing it the right way
@TheJP100
3 жыл бұрын
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!
@MalgosO
4 жыл бұрын
I want the introduction to be 50 minutes, this guy is amazing
@lionelleroux1132
4 жыл бұрын
I would love a pair programming session with Uncle Bob
@dimitarkarazapryanov9710
2 жыл бұрын
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
@Sinebeast
3 жыл бұрын
Those digressions at the start are really cool :)
@drhhusain
4 жыл бұрын
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
4 жыл бұрын
dubbing is off too
@GerbenWijnja
4 жыл бұрын
yeah well you can kinda guess what he's writing, so it's ok. In my opinion.
@gajbooks
4 жыл бұрын
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
4 жыл бұрын
@@rossgeography at 3:50 it glitches and syncs... i hope it doesn't sync out again later >_
@kemsekov6331
2 жыл бұрын
As he said. You'll be even more frustrated.
@Chiramisudo
3 жыл бұрын
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!!! 😒😞
@casperes0912
4 жыл бұрын
"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
3 жыл бұрын
Print
@mistalan
3 жыл бұрын
Physicists
@MrDoboz
2 жыл бұрын
exactly my reaction lol
@elbanj
3 жыл бұрын
For some reason I imagine he also rocks on the electric guitar.
@TheNewton
3 жыл бұрын
Some good meme material in this series like his coder stance jutsu.
@shapedsilver3689
3 жыл бұрын
I want to t-shirt that says “my tests pass, so damn you!” Lol
@greenlampshade8909
3 жыл бұрын
Depends greatly on how those tests were developed. "...so TDDamn you!"
@harpywraith9017
9 ай бұрын
My favorite stand-up comedian
@alexo4600
2 жыл бұрын
"i'm on a mission to kill all braces" "i want lisp to be the last programming language" yeahh right
@cedrics7374
Жыл бұрын
44:02 when he said he’ll do a demo, I almost cheered 🥲
@n0MC
3 жыл бұрын
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.
@hosseinamiri1516
3 жыл бұрын
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.
@TodorescuProgramming
4 жыл бұрын
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 ...
@unitycoin_original
2 жыл бұрын
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
@immalkah
2 жыл бұрын
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.
@alext5497
3 жыл бұрын
Wow. Im actually having a rage reaction at the editing
@vasylstolyarchuk6226
3 жыл бұрын
The best men uncle Bob.
@ankitsood1088
2 жыл бұрын
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
2 жыл бұрын
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
@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
@RaffaeleCastagno
3 жыл бұрын
It's just me or the video is constantly out of sync, and re-synced every now and then?
@leonardkupper5057
3 жыл бұрын
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
3 жыл бұрын
@@leonardkupper5057 seems like the video is slightly faster than the audio, so it had to compensate from time to time. Great lessons tho.
@Adiounys
4 жыл бұрын
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...
@Ozzah
3 жыл бұрын
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
3 жыл бұрын
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
3 жыл бұрын
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
2 жыл бұрын
@@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
2 жыл бұрын
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
@violetjellyfish2089
4 жыл бұрын
Потрясный мужик. Смотрела бы и смотрела)))
@Name-lt2tz
2 жыл бұрын
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.
@DavidWoodMusic
3 жыл бұрын
The contrast between the cringe of the intros/editing and the quality of the content is astounding.
@TheWarTurkey
2 жыл бұрын
Air hi-five to all the other programmers here who program the double-entry bookkeeping!
@jackofnotrades15
2 жыл бұрын
Man, I wish I could do this kind of development in my interview coding rounds...😅.
@sergiocoder
Жыл бұрын
There is a borrow checker in Rust, isn't it something new?
@paxvostrum4824
Жыл бұрын
Could anybody recommend lectures like these 6, from Uncle Bob or anyone else as good as him (if there is one 😁)??
@victordrouinviallard1700
4 жыл бұрын
The parachute parabolla should be replaced by a submarine one :D
@GRHmedia
4 ай бұрын
Close but no cigar on the Alpha Centauri comment. 4.1x10^23 not 22.
@paviad
3 жыл бұрын
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
3 жыл бұрын
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
2 жыл бұрын
@@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.
@zolv
3 жыл бұрын
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
3 жыл бұрын
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
2 жыл бұрын
@@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.
@TruthNerds
2 жыл бұрын
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 KZitemr Veritasium. Just a week or so ago, another KZitemr 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
2 жыл бұрын
The extratetrrestrial "that have spaceships with antigravity", say that our understanding of electromagnetism and matter is all wrong.
@TruthNerds
2 жыл бұрын
@@BienestarMutuo That may well be… but if they started explaining it to us properly, would we be able to understand a word? 😄
@BienestarMutuo
2 жыл бұрын
@@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).
@ignorantandblind
Жыл бұрын
Is this video an alternative to reading his book?
@ViktorEngelmann
3 жыл бұрын
Prolog actually becomes one of the best languages there are... as soon as you really understand it.
@garryiglesias4074
3 жыл бұрын
Pure C without preprocessor, is the REAL way to go. It's obvious.
@igorswies5913
3 жыл бұрын
@@garryiglesias4074 wait so you want to keep all code in one file?
@garryiglesias4074
3 жыл бұрын
@@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
3 жыл бұрын
@@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
3 жыл бұрын
@@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.
@romanext921
2 жыл бұрын
Very nice demo 😅
@mohammadazeem7228
3 жыл бұрын
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 ❤️
@THEMithrandir09
3 жыл бұрын
Can anyone link a github repo that does TDD exactly like he describes it around 29:00.
@marcdietmann724
2 жыл бұрын
What happens if you build your system on one test that was designed false. Would your whole system be false?
@jakubk7158
Жыл бұрын
31:30, 32:30, 36:55, 39:35, 1:24:42 - groups to learn
@redbread6852
3 жыл бұрын
How'd ya code in c++ on Intellij IDEA CE? Is this a Mac/Ultimate feature? The one plugin I found is outdated
@alext5497
3 жыл бұрын
A bunch of nerds drooling over best practices and good organization. I love it
@sagarjoshi8444
3 жыл бұрын
Can we refer manual tets cases from QA and write aut or integration test for it, is it a good practice ??
@lcppproductions7910
2 жыл бұрын
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
3 жыл бұрын
What if, and hear me out here, what if instead of removing the problem of debugging simple things like the minor change you're implementing right now, we instead make it easier to solve that problem? The harder problems of major changes and distant interactions remain in both situations, but if we removed the need to debug the simple things, we no longer have the exercise to learn to solve the bigger problems. What if we could make debugging both the simple and complex things easier? What if we could make debugging easier and more useful than testing? That seems like a better solution than removing the problem in just one situation.
@AdrianLParker
2 жыл бұрын
But it's not only debugging, TDD can catch logical and business logic errors which compile just fine. Imagine an add function which takes two integers, should return the sum of them, but always returns -1. It's a bug, but it will compile without error
2 жыл бұрын
@@AdrianLParker That is true. But what worries me are the hard bugs that unit tests can't detect, or that it's not immediately obvious that the behavior is incorrect. I'm also concerned about how hard it is for developers to understand the big picture of what the whole program is doing, and how the system works not just in the ideal case, but also in the weirder cases. It's not enough that we know which values a simple and isolated function returns. Reading the source code or running tests is not enough to understand why things happened, you need a good debugger. Here is what I mean by making debugging easier. It's a small prototype (not fully featured or bug-free), but it should show why I think that a better debugger can do everything that TDD can do, and even more, and better. Even if you don't agree, I would like to know your thoughts. clinei.github.io/codeliteral/
@michelgent7419
3 жыл бұрын
He got the water dipole reversed (not critical but fyi..)
@rainaldkoch9093
3 жыл бұрын
Yes, due to the empty orbitals at the other two vertices of the tetrahedron.
@AZ-bu7ss
3 жыл бұрын
Thanks
@NadChel1
8 ай бұрын
They don't write Stacks in production, though
@BryonLape
3 жыл бұрын
I don't think they young lady understood Bob's answer. I hope she got clarification later.
@GeorgeTsiros
3 жыл бұрын
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.
@somebodyoncetoldme1704
2 жыл бұрын
couldn't the sound be synced with the picture?
@TheTigercore
4 жыл бұрын
Not being able to see the code is painful. Why am I staring at a guy writing code?
@user-yd9xy3rb4x
2 жыл бұрын
10:30 Hello from an iOS developer :)
@PNadav183
3 жыл бұрын
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
3 жыл бұрын
Here's a good one where you can see the developer and the code at the same time: kzitem.info/news/bejne/k5hn3JedmIqEhW0
@RSFeed
3 жыл бұрын
51:56 out thru the nose comes the hot tea flying!
@RSFeed
3 жыл бұрын
1:00:16 I´m not drinking any more tea untill this finishes...
@Name-lt2tz
2 жыл бұрын
I want to see that experiment with 45 volts :) I do not want to spend money doing that
@AdrianLParker
2 жыл бұрын
@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
2 жыл бұрын
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
2 жыл бұрын
@@MrDoboz listen to what he said at @1:22:26 and then read my question again
@AdrianLParker
2 жыл бұрын
@@MrDoboz exactly my point, but the video seems to say contrary
@irmaosver
2 жыл бұрын
You should write your tests on the public methods and not the private methods. That's the implicit part.
@kiwiskilled
3 жыл бұрын
fire the guy who is responsonsible for not showing the screen.
@csbnikhil
3 жыл бұрын
Rust's Ownership & Borrowing were new, I thought.
@albertmarashi3666
2 жыл бұрын
They are
@avimehenwal
3 жыл бұрын
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?
@CuriousCritter9
3 жыл бұрын
They are for sale at cleancoders.com/series/comparativeDesign and do not appear to be on KZitem.
@MiseryKira
2 жыл бұрын
Does rly java "compiles"?
@emilhuseynli
4 жыл бұрын
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
4 жыл бұрын
Sorry to say, but we just edit the video, this is his blog: blog.cleancoder.com/
@lucasdarianschwendlervieir3714
4 жыл бұрын
kzitem.info/news/bejne/ppBmm5ltfn-Af4I This video is excellent at explaining the problem with highly coupling production code to test code.
@emilhuseynli
4 жыл бұрын
@@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
4 жыл бұрын
@@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
4 жыл бұрын
@@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.
@Kitsune_Dev
4 жыл бұрын
Sound is faster than light
@jonilarsen-haikarainen8733
4 жыл бұрын
I think this has put me off TDD and the Java language, for life.
@socrattt
3 жыл бұрын
Punishment goes to those who deserve it.
@wolverine9632
3 жыл бұрын
For everyone ranting about the "camera guy," I would like to point out that there are multiple cameras, and only one editor.
@worldshaper1723
3 жыл бұрын
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
3 жыл бұрын
Friend, please give us a brief, and please a comparison with the jai language. Thanks. info@unitycoin.net 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
Пікірлер: 293