The Art of Clean Code by Victor Rentea

Whatever paradigm, language, technology stack or devops strategy we use, we will always write code. And that code will need to be understood, maintained and evolved by various developers for many years, hopefully. It will be read 10x more time than it took to write it!

Then, tell me, how do you write your code ?

Stop rushing, and start writing professional code. You'll need to learn to introspect your design, to make it express your thoughts in code. It may take years of practice to reach that point, but the path starts with some basic guidelines and 'code smells' that you ought to know, along with a core toolset of refactoring techniques.

As simple as some of these might seem, they will become the starting point of a lot of discussions about core principles of good software design, such as DRY, SRP, DIP, and KISS. Come and enjoy an entertaining, tangible presentation of key concepts in Clean Code, that will allow you to easily coach others, back at work.

Looking forward to share my passion with you: writing expressive code that is a pleasure to work with.

PS: In the end, let's talk a bit about writing clean code using Java8 lambdas/Streams, shall we? :)

Victor Rentea
Java Craftsman. Sr. Engineer & Technical Lead at IBM. Independent Trainer & Coach. I worked on backend systems over the last 10 years, solving challenges of a broad range of enterprise Java applications as a developer, lead and consultant. 4 years ago I joined the ‘coding craftsmanship’ move, and soon after I started preaching about it as an independent trainer/coach. For hundreds of days I’ve trained more than 1000 trainees in all kinds of settings (including academic), usually bundled with other training modules in my curricula. My experience as a trainer allowed me to refine a very entertaining presentation style, spiced with jokes, non-IT-world analogies, and examples that is able to convey even the most complex ideas

[SlyaQ]

Thank you for presenetation! I have writen down some of your advices. Looking forward to see how my code will develop.

[chriswysocki]

really good talk. and f-ing expressive :) I really resonated with the comment about code comments. I've seen so many times when comments have become obfuscation, and hence the opposite of what they purport to do when the code gets updated and the comments get a lower priority on getting updated.

[thepocguy]

@28:22, on the right, the constructor is named ExtractedMethodCommand while the class name is DoComplexStuffCommand . Should the constructor name not be same as class name ?

[uxmjuzb]

Very very good presentation. Thanks :)

[muntaserabukhadijah]

Does the example at 26:20 has a bug? I mean shouldn't we check if the list values are not null too?
What if Integer.parseInt(null); // throws null

Also If I want to apply not checking for null in this method, how I can do that? I am asking based on the point at 19:30 (NULL wars).

[TheNitramlxl]

If you want code, which looks like prose: write your programs in Rockstar.

[cntagn]

How do you reconcile the developer's desire to take their time to craft their code with business's constant demand for faster features? All the places I've worked at management got addicted to releasing shiny new features and refused to ever prioritize tech debt and refactoring to the point where every single sprint introduced some new tech debt.

[nitinagrawal]

Listen to all & understand what they have to say but follow your common sense. I don't see any generic good/bad in Stateful vs Stateless or Mutable vs Immutable or Imperative vs Functional programming. If one understands the requirements, environment, work culture, mindset etc then that person can pick the right option without doing any arguments around the comparisons of these terms.

[Abdulmajeed-syus]

So we should reduce comments as much as possible? Is it always(or at most times) possible to do this ?

[dengan]

Lol this is an endless fight, and nobody is victorious