clean code

May 26, 2017

OWASP Juice Shop – Achieving sustainability for open source projects

If you didn’t have the chance to be at the AppSecEU 2017 conference in Belfast or you didn’t make it to my talk there, here’s the official recording:

OWASP Juice Shop is a “shooting star” among broken web applications. To make sure it does not end as a “one-hit wonder”, the project embraces principles and techniques that enhance its sustainability, e.g. Clean Code, TDD, CI/CD, Quality Metrics and Mutation Testing.

In this session you will see how
– even a horrible language such as Javascript can be written in a maintainable manner
– a complete and reliable test suite eliminates the “fear of change”
– automation is a key to increased productivity – even for small open source projects
– free-for-open-source SaaS tools can improve your development process

Where is light, there is shadow! You will also learn
– about some limitations in the automation processes
– the pain keeping Javascript dependencies up to date
– why some 3rd party services had to be dropped

If the Internet gods are with us, we will even perform a production release of OWASP Juice Shop during the session!

You can find the original HTML5 slide deck at http://bkimminich.github.io/juice-shop/appseceu_2017.html. The slightly less fancy PDF-version is available on SlideShare:

May 26, 2017

Batman v Supername – Dawn of Legacy Code

“Good names – for classes, functions and variables alike – are a simple but powerful way of creating understandable code. Understandable code gives you improved maintainability. Bad names on the other hand are a heavy burden that the whole development team has to carry. Bad names hide the authors intent, leave false clues and often obscure the meaning of code. And all this calls for a certain action that developers should never have to apply lightly: The Batman Mode™. Forced into detailed detective work, developers try to find the meaning and correct pronunciation of class names like GyqfaChBppResDao. They investigate the difference between intended and entrenched meaning of variable names like ssd, sd and cd. They argue with code-villains about Encodings, Hungarian Notation and if an interface name should start with an I or not. Putting a little bit of extra care into name choices and following some simple concepts such as the “Scope Rule” and “Newspaper Metaphor” can have huge positive effects on your code. By choosing Supernames™ your team might even prevent the Dawn of Legacy Code for its own project!

You can find the original presentation slides here: http://batman-v-supername.kimminich.de

December 3, 2015

// No Comment!

“Comments are – at best – a necessary evil” (Uncle Bob, “Clean Code”) – Over the years I gathered quite a collection of examples for bad code comments. The most precious gems among them I would like to share with you. You will listen in on developer monologues and dialogues, try to analyze cryptic bylines, experience different levels of UnCamelCasing(tm) skill and fight your way through a redundant, useless and misleading inline thicket. You will also hear about well-meant tools and plugins that should not even exist if the motto “No Comment!” would be valued as it should be.

You can find the original presentation slides here: http://no-comment.kimminich.de

Some comments on // No Comment! from Clean Code Days 2015:

 

 

 

 

February 16, 2014

Practicing Advanced Unit Testing with the TCG Kata

Doing Code Katas alone or in a Dojo can help sharpen our elementary skills as software developers. Practicing IDE shortcuts and TDD mini-step cycles is very useful for the daily business, yet I find some existing Code Katas too far away from real-life programming situations. That’s why I came up with the Trading Card Game Kata – which is (very loosely) based on Blizzard Entertainment’s free-to-play online-game “Hearthstone – Heroes of Warcraft”. This Kata is focused on practicing TDD in a slightly more complex (but not complicated) situation where you might have to think about rules like Single Responsibility Principle or Command Query Separation and might even feel the urge to use a Mocking framework at some point.

First I will introduce the ideas of Katas and Dojos in general and explain the TCG Kata rules to you. Then I will demo some real-life best-practices for writing good developer tests, using my TCG Kata sample solution as a showcase. This will include:

  • Picking the right Test Double
  • Test Data Builders
  • Behavior Tests with BDDMockito
  • Prose-like Assertions with Hamcrest
  • Readability Sugar

The full Kata ruleset and a sample solution in Java 8 can be found on https://github.com/bkimminich/kata-tcg.

September 19, 2013

Kommt Clean Code in Studium und Ausbildung zu kurz?

These are the slides of my talk at the Clean Code Days 2013 in Dresden, Germany. They are in German, so I didn’t bother writing an English abstract. Sorry!

Themen wie Clean Code oder praktische Aspekte agiler Softwareentwicklung tauchen in den Curricula der wenigsten Hochschulen an prominenter Stelle auf. Warum ist das eigentlich so? Wieso fragen wir Bewerber nach ihren beherrschten Programmiersprachen oder bereits verwendeten Frameworks, aber selten nach ihren tatsächlichen handwerklichen Fähigkeiten. Sauberen, nachvollziehbaren und wartbaren Code zu schreiben, sollte viel weiter oben auf der Checkliste bei Bewerbungsgesprächen stehen.

In dem Vortrag “Kommt Clean Code in Studium und Ausbildung zu kurz?” wird von Erfahrungen aus mehreren Clean Code-Schulungen sowie Hochschulvorlesungen zum Thema berichtet. Ziel des Vortrags ist es, für eine deutlich qualitätszentriertere Ausbildung von Softwareentwicklern zu werben, sowohl an Hochschulen als auch in Ausbildungsbetrieben. Ausserdem können Manager einige Tipps mitnehmen, wie man Bewerbern auf Entwickler-Positionen die richtigen Fragen nach ihren wirklich wichtigen Fähigkeiten stellt.

September 19, 2013

Agile Software Development In Practice

These are the slides to my “Agile Software Development in Practice” lectures. They are intended especially for Software Development students but have also partially been used in inhouse Clean Code developer trainings.

The following topics are covered:

  • most aspects of Agile Methodology from Pair Programming to Collective Code Ownership
  • Clean Code based on Robert C. Martins work
  • Test Driven Development
  • advanced Unit Testing techniques like Mockito mocks and Hamcrest matchers

The deck is divided into 9 lectures which each consist of a theoretical part and a practical excercise for the students. Included are building a Mars Station from building blocks (using agile methods and SCRUM roles), Uncle Bobs famous Bowling Game Code Kata and a smallscale Code Retreat.

Accompanying source code and examples can be found on https://github.com/bkimminich/AgileSoftwareDevelopmentInPractice