Here is another highly recommended(controversial) and eye-opening presentation that can help you get better at coding.
https://www.infoq.com/presentations/7-ineffective-coding-habits/
I’m leaving here just 2 screenshots that were important to me and that I identify with them.
1. About Comments
2. About TDD
Also I like the phrase, “OOP Assembly”… that is we write procedural code in OOP
Another great article on TDD
They went really fast at first — but it didn’t last. Their speed dropped precipitously, until reaching a depressing asymptote. That asymptote kills teams. It kills their spirit.
I highly recommend this post:
https://levelup.gitconnected.com/test-driven-development-is-overrated-ad9f0491c11d
“It’s slow”
The developers who say this are usually the ones who have tried TDD out for a little while and then they went back to writing tests post-development. Regardless, this is the reason most often given as to why a developer does not do TDD.
I can understand why people think that too. Thinking about code before it’s written, and spending extra time writing tests for everything that is implemented, even for the methods which may even have not had tests anyways, can take extra time. Figuring out how to stub and mock effectively for the given case can also be frustrating sometimes.
It also doesn’t help that most business units in companies only use speed and time taken to deliver as a measurement of efficiency and effectiveness, which means teams have pressure to be faster
It also doesn’t help that most business units in companies only use speed and time taken to deliver as a measurement of efficiency and effectiveness, which means teams have pressure to be faster
When looking at the Four Key Metrics (I like to reference these a lot) from Accelerate, two of the metrics are Change Failure Rate, and Deployment Frequency.
When looking at the Four Key Metrics (I like to reference these a lot) from Accelerate, two of the metrics are Change Failure Rate, and Deployment Frequency.
With TDD, as I mentioned above, assuming the system was built exclusively using TDD, a team will know instantly whether or not a change to the code has broken functionality elsewhere in the system and also increase the speed with which they find a Bug. The locality of the tests also allows developers to know where the problem is very quickly. This results in broken functionality getting to the customer less often, decreasing the team’s Change Failure Rate.
Having high confidence in the resilience and functionality of the software means the team can decide to deploy whenever the tests are passing. Deploy on Demand anyone?
When looking at the Four Types of Work from The Phoenix Project, one of the types of work is “Unexpected”. This is whenever developers have to stop what they are doing in order to work on something else, usually as the result of a bug. Self Tested Code means minimizing bugs. Minimizing bugs means minimizing unexpected work. Minimizing unexpected work means maximizing developer happiness. Happy developers are good developers.
I have found this great excerpt about TDD, Original articles:
https://khalilstemmler.com/articles/software-professionalism/developer-principles/
One of the most controversial trends to hit the industry has been TDD. It’s worked for some, and failed for many others. But the reason I think it fails is because sometimes we try to treat TDD as law.
In TDD, there’s a concept of a Red-Green-Refactor loop. It goes like this.
Red: Write a failing test
Green: Write the code to make the test pass
Refactor: Refactor the code when needed in order to improve the design.
Don’t treat this as a dogma. You don’t have to execute TDD in this order to feel like you’re doing it properly.
That’s not important. You don’t have to stick to the loop by the letter.
What’s important is that you write the tests while you code (or before you code) in order to reap the benefits of TDD.
The primary benefit of doing this is that you know right away if your code is testable or not. And if it’s not, you can take action right then and there before you pour some concrete that is going to be hard for yourself and anyone else to change in the future.
Knowing how to write testable code can be taught. That’s one of the benefits of the SOLID principles, and it aims to address that.
Into Java 