Defensiv Programmering

...færre WTF pr minutt, også i produksjon...

Transcript

1. E N A B L I N G E F F I C I E N T H E A L T H C A R E Defensiv Programmering @hjerpbakk 11. desember 2015 …færre WTF pr minutt, også i produksjon…
2. E N A B L I N G E F F I C I E N T H E A L T H C A R E Spørsmål? Ikke krasj
3. E N A B L I N G E F F I C I E N T H E A L T H C A R E Defensiv Programmering er en framgangsmåte for å forbedre: • Generell kvalitet • Lesbarheten til koden • Forutsigbarheten til programmet Wiki
4. E N A B L I N G E F F I C I E N T H E A L T H C A R E Korrekt kode Validere input Returnere forventede verdier Håndtere exceptions Logging Feilmeldinger Annet? Det jeg tenker på
5. E N A B L I N G E F F I C I E N T H E A L T H C A R E “… Railway industry use CENELEC 50128 to drive software development to higher possible standard due to the sensitiveness of the matter they usually manage : human life.” Sikkerhet: “freedom from unacceptable level of risk” Jernbanen i USA
6. E N A B L I N G E F F I C I E N T H E A L T H C A R E 1. Variables should be range checked 2. Where possible, values should be checked for plausibility 3. Parameters to procedures should be type, dimension and range checked at procedure entry 4. Input variables and intermediate variables with physical significance should be checked for plausibility 5. The effect of output variables should be checked, preferably by direct observation of associated system state changes CENELEC 50128
7. E N A B L I N G E F F I C I E N T H E A L T H C A R E
8. E N A B L I N G E F F I C I E N T H E A L T H C A R E Vite hva Clean Code er Skriv Clean Code Refactoring for å gjøre koden bedre! Ingen enkel fasit, men flere enkle tips man kommer langt med SOLID! Clean Code
9. E N A B L I N G E F F I C I E N T H E A L T H C A R E Clean Code er: Enkel å lese Lett å forstå Enkel Minimal Gjennomtenkt Clean Code
10. E N A B L I N G E F F I C I E N T H E A L T H C A R E Metoder har rammebetingelser: Parameterne den tar inn Typen(e) den returnerer Exceptions som kan bli kastet Trust but verify Husk at verden rundt metoden kan endre seg Metoder
11. E N A B L I N G E F F I C I E N T H E A L T H C A R E Clean, testbare og forutsigbare metoder: Tydelig mening Gode navn Fokusert kode Få parametre Kort lengde Dekket av automatisert test Forventede resultat Metoder i C#
12. E N A B L I N G E F F I C I E N T H E A L T H C A R E Det viktigste parameteret først i parameterlisten Bruk samme rekkefølge i beslektede metoder Variabler skal deklareres så nært der de brukes som mulig Alltid { Foretrekk positive if Husk default i switch! Riktig antall bool inn i en public metode? Metoder i C#
13. E N A B L I N G E F F I C I E N T H E A L T H C A R E Strukturerte Selvdokumenterende Automatiske Kan kjøres om og om igjen… … i en hvilken som helst rekkefølge Hvordan får vi disse egenskapene i testene? Automatiserte tester
14. E N A B L I N G E F F I C I E N T H E A L T H C A R E Hva kan gå galt i C#?
15. E N A B L I N G E F F I C I E N T H E A L T H C A R E Null! DivideByZero Lengde på Arrays og Lister Manglende dispose og opprydding Strenger på feil format Data utenfor gyldighetsområde Eventer Overflow i numeriske typer Tegnsett Lokalisering Dato og tid Manglende { Dårlig trådhåndtering Hva kan gå galt i C#?
16. E N A B L I N G E F F I C I E N T H E A L T H C A R E Velg den enkle løsningen først Et tall er ikke bare et tall: uint, short etc. Bruk strenger kun der du må Async? Vær tydelig! Vær deklerativ Vær idiomatisk as vs. is vs. cast Parse vs. TryParse var internal Kjenn språket
17. E N A B L I N G E F F I C I E N T H E A L T H C A R E Hver varsom med state, det er her kompleksiteten lurer Utnytt typesystemet Foretrekk immutable typer MVVM Utnytt triks fra funksjonell programmering State suxx!
18. E N A B L I N G E F F I C I E N T H E A L T H C A R E Beskytt deg mot data som kommer fra: Brukeren Tjenester Annet eksternt Og input i public metoder/properties All data er dårlig fram til den er verifisert Gjør dette én gang slik at resten av koden slipper å være paranoid Beskytt deg mot det ukjente
19. E N A B L I N G E F F I C I E N T H E A L T H C A R E Sjekk argumentene og kast ArgumentExceptions Guard Clauses: Gjør dette i starten og returner tidlig Resten av metoden / klassen kan jobbe ut i fra alt er bra Så lenge sjekken kjøres hver gang dataene endres (hvis man opererer på state) Annoter med NotNull for verdier du forventer skal være med. Vil tro dette er alle… Xenofobi
20. E N A B L I N G E F F I C I E N T H E A L T H C A R E catch(Exception e) er et antipattern… … men kan være vanskelig å unngå? Husk finally! Dokumenter hvilke exceptions din metode kaster Noen ganger er det lov å prøve på nytt ALDRI bruk exceptions som en del av vanlig programflyt! throw, ikke throw e Ikke overfør for mye info om serverfeil til klienten Hvordan håndtere out of memory exception? Feilhåndtering
21. E N A B L I N G E F F I C I E N T H E A L T H C A R E Skriv en melding som er relevant for bruker Ikke nevn ting bruker ikke kan gjøre noe med Hvor i koden skal man vise feilmeldingen til bruker? Feilmeldinger til bruker
22. E N A B L I N G E F F I C I E N T H E A L T H C A R E Logg uventede hendelser Logg det vi trenger for å følge flyten Husk på loggnivåene vi har Ikke skriv sensitiv data i loggfilene Sleng på det Sindre vil ha Logging
23. E N A B L I N G E F F I C I E N T H E A L T H C A R E Ikke konkatiner strenger for å lage spørring! Bruk bind-variable Og aller helst putt SQL-en der den hører hjemme: i basen Database
24. E N A B L I N G E F F I C I E N T H E A L T H C A R E Ikke la brukeren gjøre noe som ikke går an gitt context -> disable knapper og felt Vis melding om feil input nært der input skrives Beskriv HVORFOR dette var feil og hva bruker kan gjøre for å skrive inn rett Input
25. E N A B L I N G E F F I C I E N T H E A L T H C A R E Ikke stol på brukeren Ikke stol på utviklere Ikke stol på deg selv Siste ord…
26. E N A B L I N G E F F I C I E N T H E A L T H C A R E … men ikke vær som papegøyen