Download to read offline
TDD = bra design?
- 1. TDD = bradesign? KJETIL KLAUSSEN
- 2.
- 3. Red GreenRefactor TDD 1. Skriv test 2.Sjekk at testen feiler 3. Implementer 4. Sjekk at alle tester er OK 6. Sjekk at alle tester er OK 5. Forbedring KJETIL KLAUSSEN 3
- 4. Vil TDD føre til bedredesign? KJETIL KLAUSSEN 4
- 5.
- 6.
- 7. Bedre enn hva? KJETILKLAUSSEN 7
- 8.
- 9.
- 10.
- 11.
- 12. Hva er bradesign? KJETIL KLAUSSEN 12
- 13.
- 14.
- 15.
- 16. Man må vitehva bra design er hvis man ønsker å skape det - Kjetils postulat KJETIL KLAUSSEN 16
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 24.
- 25.
- 26.
- 27. Prinsipper Domain-driven design (DDD) Singleresponsibility (SRP) Open/closed (OCP) Liskov’s substitution (LSP) Interface segregation (ISP) Dependency inversion (DIP) Law of Demeter (LoD) Tell, don’t ask Principle of least surprise (PoLP) Design by Contract Feature envy High cohesion / low coupling 4 rules of simple design (4RoSD) Balanced abstraction Separation of concerns (SoC) You ain’t gonna need it (YAGNI) Don’t repeat yourself (DRY) Keep it simple stupid (KISS) KJETIL KLAUSSEN 27
- 28. Design Patterns Factory Singelton Monostate Prototype Adapter Bridge Composite Decorator Facade Flyweight Proxy Command Mediator Memento Null Object Specification State Strategy Templatemethod Visitor Repository Aggregate Entity Value Object Model View Controller Model View Presenter KJETIL KLAUSSEN 28
- 29. Architectural Patterns Structure ◦ Component-based (CBSE) ◦Monolithic ◦ Layered ◦ Pipes and filters Shared Memory ◦ Data-centric ◦ Blackboard ◦ Rule-based Messaging ◦ Event-driven (EDA) ◦ Pub-sub ◦ Message-oriented Adaptable ◦ Plug-ins ◦ Microkernel ◦ Reflection ◦ DSL Distributed ◦ Client-server ◦ Shared nothing (SN) ◦ Space-based ◦ Object request broker ◦ Peer-to-peer ◦ REST ◦ Service-oriented ◦ Microservices KJETIL KLAUSSEN 29
- 31.
- 32. "You can't dogood design without experience. When less experienced people do TDD they typically don't refactor enough, leading to sub- optimal designs" - Martin Fowler KJETIL KLAUSSEN 32
- 33.
- 34. TDD = bradesign? KJETIL KLAUSSEN 34
- 35. "Be humble aboutwhat tests can achieve. Tests don’t improve quality: developers do." - James O. Coplien KJETIL KLAUSSEN 35
- 36.
- 37.
- 38.
- 39.
Editor's Notes
- #3 For de som ennå ikke har fått med seg hva TDD er – og det bør ikke være noen i dette rommet her – så tar vi en rask intro
- #4 TDD handler om å skrive en test for en funksjonalitet man ønsker, sjekke at testen feiler, implementer funksjonalitetet og sjekke at testen går gjennom. Man implementerer så lite som overhodet mulig for å få testen til å passere og når man er i grønn sone så tar man seg tid til å forbedre koden gjennom refaktorering. Når man er fornøyd sjekker man at alt fortsatt fungerer og skriver neste test.
- #5 Så vil TDD føre til bedre design? Håndsopprekking?
- #6 For de som vil bevare spenningen til slutt; vennligst lukk øyne og øre
- #7 Nei, TDD vil ikke gi deg et bedre design. Kanskje et litt annet design, men ikke nødvendigvis et bra design
- #8 Det første vi må spørre oss om da er; bedre enn hva?
- #9 Bedre enn vannfall?
- #10 Jeg har sett mange som mener at TDD er bedre enn vannfall, men vi må huske at TDD primært er en arbeidsflyt - ikke en prosess-metodikk
- #11 Da er det mer naturlig å sammenligne med denne arbeidsflyten. Og ja; jeg vil påstå at TDD er en bedre arbeidsflyt er dette.
- #12 Så hvis du vil endre ratioen til fordel for koding, så vil jeg absolutt anbefale TDD. Personlig synes jeg koding er langt morsommere enn debugging, så av den grunnen alene ville heller valgt TDD. Men hverken TDD eller Debug-driven development sier noe om design…
- #13 Spørsmålet vi trenger å stille oss er; hva er bra design?
- #14 Er dette et bra design?
- #15 Eller dette?
- #16 Dette?
- #18 Uansett om det handler om visuelt design…
- #19 … eller underliggende struktur og arkitektur, så må man vi vite hvilke design-muligheter man har og velge det som man tror passer best for den løsningen man bygger. Det å designe et system for hinsides skalerbarhet når systemet skal brukes av 14 brukere er et like dårlig valg som å designe et system uten skalerbarhet hvor man har millioner av brukere. Man må vite hva bra design er i den konteksten man er. Hvis ikke….
- #20 Hvis ikke ender man opp med dette.
- #21 … eller dette
- #22 … eller dette
- #23 … eller dette
- #24 TDD er ingen magisk trylledrikk.
- #25 Det å kunne trylle fram et godt design – om man bruker TDD eller ikke – handler om hardt arbeid. Kanskje ikke fysisk, men det krever mye innsats og det krever at du kjære seer prioriterer tid til å lære hva bra design i kontekst av software-utvikling er.
- #26 I vårt fagfelt er det primært 2 kilder til godt design: Prinsipper…
- #27 … og mønster – eller patterns på nynorsk.
- #28 Her er det 18 prinsipper listet opp. Hvor mange kan minst 3 av dem? Og med kan mener at hvis jeg spør deg så kan du forklare meg hva f.eks. Single Reponsibility Principle er. Mer enn 5? 10? Alle 18?
- #29 Og 26 av de mest populære design patterns. Hvem kan 5 eller flere? 10? Alle 26?
- #30 Dette er verktøyene våre! Dersom du ikke har tenkt å være en ufaglært grov-snekker resten av livet, så må du utvide verktøykassa di. Du må lære disse – og vite hvilke fordeler og ulemper de har, og i hvilken kontekst det ene eller andre prinsippet eller patternet bør velges.
- #31 Hvis alt du har er en hammer… Ja, okei – noen klarer seg kanskje godt med bare en hammer
- #32 …men for alle oss andre så er det viktig å kunne velge riktig verktøy til oppgaven
- #33 Som Martin Fowler sier det; Man kan ikke lage et godt design uten erfaring. Og det å lære prinsipper og patterns handler om å bygge erfaring. En vanlig nybegynner-feil i TDD er at man ikke refaktorerer nok, hvilket igjen fører til sub-optimalt design. Fowler er flink til å velge ord. Hadde de ordene kommet fra meg hadde nok ‘sub-optimalt’ vært byttet ut med ‘røtent’.
- #34 Refaktorerings-fasen i TDD er helt essensiell – og kanskje den viktigste fasen. Og for å kunne utnytte den fasen må man vite hvordan man refaktorerer og hva man skal refaktorere til
- #35 Så er det slik at man kan putte TDD inn i ene enden og så ramler det vakkert design og englemusikk ut i den andre enden?
- #36 Det er ikke TDD i seg selv som skaper designet – det er personen i andre enden av tastaturet som gjør det. Det finnes ikke det verktøy eller den metodikk i verden som automagisk kan gi deg det. Det er fortatt vi som utviklere som må tenke selv. Det er ikke antall kodelinjer pr time vi betales for – det er for å trøkke inn de riktige kodelinjene.
- #37 Og da er det prinsipper…
- #38 Og patterns som gjelder. Lær dem. Lær så mange du klarer. Og enda litt fler.
- #39 Har du det på plass, så vil TDD være til veldig stor nytte
- #40 Og suksess vil være innenfor rekkevidde.