How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing strategies. By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
We’ve come a long way in the last 20 years. We start our journey in the late 80s and our "discovery" of design principles such as The Open Closed Principle and the Liskov Substitution Principle. In the middle 90s, we discovered that these principle led to repeating patterns of design. We gave those patterns names such as Visitor and Decorator. At the turn of the millennium we found that the benefits gained from the principles and patterns could be amplified by combining them with practices such as Test Driven Development and Continuous Integration. And now, as the decade is coming to a close, we have found that these principles, patterns, and practices have driven us to define a true profession. What will that profession require of us, and who among us can truly claim to be professional?
Why is functional programming becoming such a hot topic? Just what _is_ functional programming anyway? And when am I going to have to know about it? In this talk Uncle Bob will walk you through the rationale that is driving the current push towards functional programming. He'll also introduce you to the basics by walking through some simple Clojure code.
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection.
This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.