Slide 1

Slide 1 text

Codemotion ROME @bit_shark Andrea Giuliano Think horizontally do not use lighters to open beers Giulio De Donato andreagiuliano.it welcometothebundle.com @liuggio 11-12 april 2014

Slide 2

Slide 2 text

Think horizontally @bit_shark @liuggio #codemotion hint We won't use technicisms and acronyms. Please see the references, we have had a lot of inspiration

Slide 3

Slide 3 text

thinking ideal @bit_shark @liuggio #codemotion Given an application with certain requirements which is the technology that fit the application requirements?

Slide 4

Slide 4 text

thinking real @bit_shark @liuggio #codemotion Given an application with certain requirements, I’m guru on Java I’ll use Java.

Slide 5

Slide 5 text

think too much… … at the same technology @bit_shark @liuggio #codemotion What’s wrong here? I’m developing a tech-centric application I’m fitting business requirements with technical boundaries

Slide 6

Slide 6 text

rethink to the origin @bit_shark @liuggio #codemotion But what about our preferred technology? Was it the coolest? The most requested for working? Or trivially the simplest?

Slide 7

Slide 7 text

think about laziness @bit_shark @liuggio #codemotion A developer should choose not the simplest tech The developer laziness drive the developer to reuse its code!

Slide 8

Slide 8 text

different thoughts @bit_shark @liuggio #codemotion A language can lack on some structural characteristic (polymorphism, strong typing)

Slide 9

Slide 9 text

think with ease @bit_shark @liuggio #codemotion The success of a language is it’s distributability (cheap, easy, zero-conf)?

Slide 10

Slide 10 text

a thought for thought @bit_shark @liuggio #codemotion There are successful application written in lacking languages The success of the business make the success of the application

Slide 11

Slide 11 text

thinking relational @bit_shark @liuggio #codemotion EAV thousand of libraries choose the relational model instead of schemaless • simplicity to distribute and install • even though some arguable tech detail

Slide 12

Slide 12 text

think to aim the success @bit_shark @liuggio #codemotion nosql Using the right technology in some cases could lead to a wrong choice

Slide 13

Slide 13 text

Shaggio theorem @bit_shark @liuggio #codemotion Hypothesis: supposing a developer knows every technology and make a good choice for a complex application Thesis: whatever will be the choice could be the wrong choice …we are thinking to the app as a one big global ‘entity'

Slide 14

Slide 14 text

think modular @bit_shark @liuggio #codemotion we want to split the application in as many as possible modules choosing the “right” technology for each module

Slide 15

Slide 15 text

think… @bit_shark @liuggio #codemotion • Split the business needs in subsets… a subset could be composed by services... • Spit and conquer and Object Oriented Design • If you have to implement a complex system, don’t implement a complex system, implement a lot of simple systems

Slide 16

Slide 16 text

think procedural @bit_shark @liuggio #codemotion developing with procedural is misleading, at the beginning you feel powerful, fast…

Slide 17

Slide 17 text

think WTF! @bit_shark @liuggio #codemotion • How many times you will modify the application, did you think about Maintenance costs? • Procedural is when you create a fast program (at the beginning) but difficult to maintain. “Tragically, the very same forces that make it so easy to add new features to a brand new Rails application are the ones that start to hold you back as the number of features grows.” cit. Matt Wynne

Slide 18

Slide 18 text

think connected Time Feature @bit_shark @liuggio #codemotion

Slide 19

Slide 19 text

think connected Time Feature @bit_shark @liuggio #codemotion • The procedural code is sick with a disease called "code connected” • Object-oriented programming is not immune • Time increases exponentially with the addition of new features.

Slide 20

Slide 20 text

think “Operation” @bit_shark @liuggio #codemotion All the programs are difficult to maintain, but decoupled software is easier How to understand if my code is decoupled? If you modify here and you don’t break over there.

Slide 21

Slide 21 text

Time Feature think maintainability @bit_shark @liuggio #codemotion TDD

Slide 22

Slide 22 text

Time Feature think maintainability @bit_shark @liuggio #codemotion TDD • Modularity is the main concept of Object Oriented Design • The trend has changed (90 years ago), now we have to focus on maintainability • The overhead of testing before code is smaller than you think and the real adding value is the way you develop better your application

Slide 23

Slide 23 text

Think back to ‘89 @bit_shark @liuggio #codemotion responsability driven approach! SOLID principles • R. Wirfs-Brock, B. Wilkerson, “Object-Oriented Design: A Responsibility-Driven Approach” • Single responsibility principle Uncle Bob • Create a module coupling things that changes together? • Modules that communicates, but how?

Slide 24

Slide 24 text

think tell don’t ask Matt Wayne, Uncle Bob, Alec Sharp and Martin Fowler @bit_shark @liuggio #codemotion

Slide 25

Slide 25 text

think behaviour @bit_shark @liuggio #codemotion dependency injection • Modules that communicate via protocols • Modules that exhibit a behavior not their data • Data are the guts of the module, they must not be exposed • All the public functions are API, let's take care and give them a meaning. • Each module should have its own explicit dependencies

Slide 26

Slide 26 text

think and code @bit_shark @liuggio #codemotion 1. An employee has always a name and a salary! 2. The salary is always greater than zero! 3. A company could add an employee

Slide 27

Slide 27 text

think and code @bit_shark @liuggio #codemotion 1. An employee has always a name and a salary! 2. The salary is always greater than zero! 3. A company could add an employee

Slide 28

Slide 28 text

@bit_shark @liuggio #codemotion think invariant 1. An employee has always a name and a salary! 2. The salary is always greater than zero! 3. A company could add an employee

Slide 29

Slide 29 text

@bit_shark @liuggio #codemotion think consistent 1. An employee has always a name and a salary! 2. The salary is always greater than zero! 3. A company could add an employee

Slide 30

Slide 30 text

@bit_shark @liuggio #codemotion think business language 3. A company could hire an employee 1. An employee has always a name and a salary! 2. The salary is always greater than zero! 3. A company could add an employee

Slide 31

Slide 31 text

think behaviour not data @bit_shark @liuggio #codemotion Bdd! specification

Slide 32

Slide 32 text

think
 Behaviour Driven Development @bit_shark @liuggio #codemotion That's why with BDD (stories and specs) you are more forced not to test the application but you focus on describe the behaviors. With BDD you tend to describes the behavior before coding, you specify what a function should do.

Slide 33

Slide 33 text

think behaviour defer implementation @bit_shark @liuggio #codemotion

Slide 34

Slide 34 text

think onion @bit_shark @liuggio #codemotion hexagonal Database as implementation detail Framework as implementation detail

Slide 35

Slide 35 text

think to clean the Architecture Application goal: separation of concerns Easy substitution of obsolete elements without affecting others components of the architecture

Slide 36

Slide 36 text

Andrea Giuliano @bit_shark andreagiuliano.it Giulio De Donato @liuggio welcometothebundle.com T h i n k y o u ! Thank

Slide 37

Slide 37 text

References https://farm3.staticflickr.com/2491/4193434786_306120fe90_b.jpg https://farm8.staticflickr.com/7185/13732796883_58bb40fae9_b.jpg https://farm8.staticflickr.com/7290/12859759305_51e8685d43_b.jpg https://www.flickr.com/photos/lovezonero/5304831965/sizes/l/ http://i.imgur.com/xl9v1on.jpg https://farm4.staticflickr.com/3404/3633209399_467123a6ca_o.jpg https://farm1.staticflickr.com/188/391815999_2725ca688c_b.jpg https://farm2.staticflickr.com/1116/1486403962_d055d8b1f9_o.jpg https://farm4.staticflickr.com/3055/2852526965_bee2642e0f_o.jpg - Growing Object-Oriented Software by Guided by Tests, Steve Freeman, Nat Pryce - Implementing Domain-Driven Design by Vaughn Vernon - Unbreakable Domain Models by Mathias Verraes - Uncle Bob the clean Architecture http://blog.8thlight.com/uncle-bob/2012/08/13/ the-clean-architecture.html - DDD community - Matt Wayne GoRuCo 2012 Hexagonal Rails by Matt Wynne - Implementing Domain-Driven Design with Spring and vFabric Wes Williams, Vaughn Vernon - The RSpec Book Behaviour-Driven Development with RSpec, Cucumber, and Friends by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North - Alberto Brandolini http://www.slideshare.net/ziobrando/ https://farm6.staticflickr.com/5134/5449083311_9a856145fa_b.jpg https://farm3.staticflickr.com/2583/3752448573_4cc6a2698a_b.jpg https://farm4.staticflickr.com/3325/3420223723_2805816861_b.jpg https://farm1.staticflickr.com/118/313590022_25c580474c_b.jpg https://farm4.staticflickr.com/3274/2886945884_8dfa5d849f_b.jpg https://farm5.staticflickr.com/4013/4290367973_c58749d73f_b.jpg https://farm9.staticflickr.com/8327/8091221482_dce187e288_b.jpg https://farm1.staticflickr.com/48/108484055_b07800b7c7_b.jpg https://farm8.staticflickr.com/7115/7445550970_32ac507395_b.jpg Assets