[PL] Jak programować aby nie zwariować

  • 276 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
276
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Jak programować abynie zwariować?Jakub Marchwicki20.05.2013
  • 2. Na początek
  • 3. Co to za gość?
  • 4. Co ja tu robię?
  • 5. Co ja tu robię?
  • 6. Co ja tu robię?
  • 7. Co ja tu robię?ból
  • 8. Co ja tu robię?bólliczba slajdów
  • 9. Co ja tu robię?bólliczba slajdówOKRyzykoutratyzdrowia35 slajdów
  • 10. Co ja tu robię?bólliczba slajdówOKRyzykoutratyzdrowia148 slajdów
  • 11. Punkt wyjścia
  • 12. Kiedy software jest dobry?Oprogramowanie musi działaćMusi być na czasMusi być rozbudowywalneModyfikowalneMusi mieć odpowiednią jakośćPunkt wyjścia
  • 13. Punkt wyjścia
  • 14. I po co to wszystko?Bo software to nasze hobby
  • 15. I po co to wszystko?Bo software to nasze hobbyfach
  • 16. I po co to wszystko?Bo software to nasze hobbyfachzawód
  • 17. I po co to wszystko?Bo software to nasze hobbyfachzawódprzyjemność
  • 18. I po co to wszystko?bo płacą nam za pisaniedokumentacjipisanie kodu to przyjemność
  • 19. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  • 20. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  • 21. „Jakość (jak piękno) jest sądemwartościującym, wyrażonym przezużytkownika. Jeśli nie ma takiegoużytkownika – nie ma takiego sądu”PlatonWięc czym jest jakość
  • 22. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  • 23. „Jakość to sposób myślenia,który powoduje, że stosuje się ibez przerwy poszukujenajlepszych rozwiązań”William Edwards DemingWięc czym jest jakość
  • 24. Jak programować aby nie zwariować?
  • 25. Czysty kod
  • 26. Czysty kod
  • 27. • Uczymy się… bez wnikania w kontekst Nazywaj zmienne w taki a taki sposób Stosuj komentarze w takich a nie innychprzypadkach Dziel funkcje na części zgodnie z takimia takimi zasadami• Z czasem zobaczymy że z czystymkodem lepiej się pracuje… tak poludzku
  • 28. Nasz mózg lepiej reaguje na czysty kod• Utrzymujemy koncentrację• Nie gubimy wątków, swobodniejpodążamy tokiem myślenia• Cognitive load – możemy pomieścićposzczególne kawałki kodu w głowiewięc potrafimy się miedzy nimiswobodnie przemieszczać
  • 29. • Nazwy• Funkcje• Komentarz• Formowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 30. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 31. int d1; //dni od rozpoczęciaint d2; //dni do zakończeniaint d3; //dni wolnychint daysSinceStart;int daysTillEnd;int daysOf;public List<int[]> getThem() {List<int[]> list1 = new ArrayList<int[]>();for (int[] x : theList)if (x[0] == 4)list1.add(x);return list1;} public List<int[]> getDates() {List<int[]> dateList = new ArrayList<int[]>();for (int[] week : theWeeksArray)if (week[0] == BEGIN_DATE)dateList.add(x);return dateList;}
  • 32. for (int i=0; i<10; i++){k += ((l[i]*1.5) / 3 );}float milleageRate;const int NUMER_OF_EMPLOYEE = 3;float sum = 0;for ( int i=0; i<numberOfTrips; i++ ){float totalCompensation = tripLength[i] * milleageRate;float deduction = totalCompensation / NUMER_OF_EMPLOYEE;sum += deduction;}
  • 33. public class CsmrDt {public void crtshpcrt() {/*...*/};public void remcrt() {/*...*/};private final int ssntm = 10;/*...*/}public class CustomerDataset {public void createShoppingCart() {/*...*/};public void removeCart() {/*...*/};private final int sessionTimeout = 10;/*...*/}
  • 34. • Nazwy powinny sugerować co zwracają• Nazwy muszą mówić o całym zakresiefunkcjonalnościMetodyString findLastNameOfCustomerWithId(long customerId){...}Map<Long, Customer> customers;Customer getCustomer(Long id){Customer customer = customers.get(id);if(customer == null){customer = createNewCustomer(id);}return customer;}
  • 35. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 36. • Zasada pierwsza:funkcje powinny być małe• Zasada druga:funkcje powinny być jeszcze mniejszeFunkcje
  • 37. Functions should do one thing.Should do it wellShould do it only!Funkcje
  • 38. writeField(outputStream, name);outputStream.writeField(name);createSquare(width, height);calculateRectangularPrismVolume(double height,double width, double depth);calculateRectangularPrismVolume(Area rectangle,double depth);
  • 39. FunkcjeDRY – Don’t repeat yourself• Duplikacja zmniejsza czytelność• Zwiększa koszty utrzymania, refactoringu ipoprawiania błędów• Prowadzi do rozbieżności funkcjonalnejmodułów wykonujących to samo• Zmniejsza reusability kodu
  • 40. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 41. KomentarzeDON’T
  • 42. Komentarze„Nie komentuj złego kodu – popraw go”Brian W. Kernighan i P.J. Plaugher
  • 43. //Sprawdzenie czy klient ma możliwość korzystania ze zniżkiif (customer.isStudent() ||(customer.age < 18) || (customer.age > 65))if (customer.isEligibleForDiscount())
  • 44. „If you decide to write a comment, thenspend the time necessary to make sure it isthe best comment you can write”Robert C. MartinKomentarze
  • 45. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 46. Formatowanie• Konwencje formatowania w zespole.Ustal i się ich trzymaj
  • 47. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 48. • Prawo Demeter – zasada minimalnejwiedzy• Moduł powinien nie wiedzieć nic ownętrzu obiektów, którymi manipulujePrawo Demeter
  • 49. • Prawo Demeter głosi, że metoda fklasy C powinna wywoływać tylkometody z:• Klasy C,• Obiektu utworzonego przez f,• Obiektu przekazanego jako argument f,• Obiektu umieszczonego w zmiennejinstancyjnej klasy C.Prawo Demeter
  • 50. • Możesz bawić się ze sobą• Możesz bawić się własnymizabawkami (ale nie możesz ichrozbierać)• Możesz bawić się zabawkami któredostałeś• Możesz bawić się zabawkami którezrobiłeś samodzielniePrawo Demeter
  • 51. final String outputDir = context.getOptions().getScratchDir().getAbsolutePath();Options options = context.getOptions();File scratchDir = options.getScratchDir();final String outputDir = scratchDir.getAbsolutePath();
  • 52. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  • 53. Zwracanie nullDON’T
  • 54. • Wykorzystuj zgłaszanie wyjątków lubzwracanie obiektu specjalnegoprzypadkuZwracanie nullList<Item> items = getItems();if (items != null) {for (Item i : items) {totalCost += i.getCost();}}List<Item> items = getItems();for(Item i : items) {totalCost += i.getCost();}
  • 55. public interface Animal {public void makeSound();}public class Dog implements Animal {public void makeSound() {System.out.println("woof!");}}public class NullAnimal implements Animal {public void makeSound() {}}
  • 56. • Przekazywanie null jest gorsze odjego zwracaniaPrzekazywanie nullpublic class MetricsCalculator {public double rectanglePerimeterCalculate(double x, double y) {return 2 * (y + x);}/* ... */}
  • 57. • Defensive programmingPrzekazywanie nullpublic class MetricsCalculator {public double rectanglePerimeterCalculate(double x, double y) {if (x == null || y == null) {throw InvalidArgumentException("Niewłaściwyargument.");}return 2 * (y + x);}} public class MetricsCalculator {public double rectanglePerimeterCalculate(double x, double y) {assert x != null : "x nie może być null";assert y != null : "y nie może być null";return 2 * (y + x);}}
  • 58. Miara czystego kodu
  • 59. Czysty projekt
  • 60. Poziom II - SOLIDny programista• The Single Responsibility Principle – klasapowinna mieć tylko jeden powód do zmiany• The Open Closed Principle – klasę możnałatwo rozszerzać, nie modyfikując jej• The Liskov Substitution Principle – klasypochodne muszą być przeźroczystymizamiennikami klasy nadrzędnej
  • 61. • The Interface Segregation Principle – dlaróżnych klientów twórz osobne interfejsy• The Dependency Inversion Principle –bądź zależny od abstrakcji a nie odkonkretnych implementacjiSOLIDny programista
  • 62. To znaczy jaki?Kod obiektowy
  • 63. • Odpowiedzialność – tylko jedna obiekty maja własną osobowość,unikaj schizofrenicznych obiektów• Enkapsulacja – to co się zmienia jesthermetyzowane• Preferencja kompozycji ponaddziedziczenie
  • 64. • Dokładanie ponad modyfikacje– Gdy dodajemy nową funkcjonalność raczej dokładamynowe byty niż modyfikujemy istniejące.• Lokalne zmiany– Zmiana ma konsekwencje lokalne, a nie globalne.Zasięg rażenia zmian jest jak najmniejszy.• Nieinwazyjność zmian– Dodanie nowych rzeczy (odpowiedzialności,funkcjonalności, zachowań) do istniejących bytów jestprzezroczyste ich dla klientów.
  • 65. public class Sql {public Sql(String table, Column[] columns)public String create()public String insert(Object[] fields)public String selectAll()public String fieldByKey(String keyColumn, String keyValue)private String ColumnList(Column[] columns)private String valuesList(Object[] fields, final Column[] columns)}
  • 66. abstract public class Sql {public Sql(String table, Column[] columns)abstract public String generate();}public class CreateSql extends Sql {public CreateSql(String table, Column[] columns)@Override public String generate()}public class SelectSql extends Sql {public SelectSql(String table, Column[] columns)@Override public String generate()}public class InsertSql extends Sql {public InsertSql(String table, Column[] columns)@Override public String generate()private String valuesList(Object[] fields, final Column[] columns)}public class FindKeyBySql extends Sql {public FindKeyBySql(String table, Column[] columns, String keyColumn, String keyValue)@Override public String generate()}public class ColumnList {public ColumnList(Column[] columns)public String generate()}
  • 67. Odpowiedzialność. Enkapsulacja. Kompozycja• To co leży u podstaw możemystosować na każdym poziomie• Projektując klasy• Projektując moduły, komponenty• Projektując systemy
  • 68. • Każdy wzorzec opisujemy w trzechkontekstach: Odpowiedzialność Enkapsulacja / hermetyzacja KompozycjaWzorce projektowe
  • 69. • Rozdziela i przesłania implementacjęzachowań, czynności.• Hermetyzujemy zmienny sposóbtworzenia obiektów• Nowe funkcjonalności uzyskujemypoprzez dodawanie komend, poprzezkompozycję.Wzorce projektowe: komenda
  • 70. Wzorce projektowe: komenda
  • 71. • Każdy element systemu: Ma swoją odpowiedzialność Hermetyzuje pewne zachowania Składa się z kilku współpracującychelementówModuły
  • 72. • Każdy framework opisujemy w trzechzdaniach: Odpowiedzialność Enkapsulacja Preferowanie kompozycjiFrameworki
  • 73. • Spring czy EJBNie ma idealnych rozwiązań
  • 74. • Spring czy EJB• JSF czy JSPNie ma idealnych rozwiązań
  • 75. • Spring czy EJB• JSF czy JSP czy VelocityNie ma idealnych rozwiązań
  • 76. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatisNie ma idealnych rozwiązań
  • 77. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBCNie ma idealnych rozwiązań
  • 78. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBC• MVC czy MVPNie ma idealnych rozwiązań
  • 79. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBC• MVC czy MVP• Java czy .NETNie ma idealnych rozwiązań
  • 80. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBC• MVC czy MVP• Java czy .NET czy PythonNie ma idealnych rozwiązań
  • 81. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBC• MVC czy MVP• Java czy .NET czy Python czy PHPNie ma idealnych rozwiązań
  • 82. Nie ma idealnych złoytych środków
  • 83. SOLIDny programista
  • 84. • Kod jest podstawowym mediumkomunikacji w projekcie• Kod to miejsce w którym spędzamynajwięcej czasu• Zły kod to jak solenie herbaty koledzez zespołu albo plucie do kanapki – aprzecież nie jesteśmy złośliwiWartości
  • 85. • Jako zespół jesteśmy jednością– Jak ja pójdę na skróty, to kolegabędzie się męczył– I jako całość i tak będziemynieefektywniWartości
  • 86. • Programy są częściej czytane niżpisane• Więcej czasu poświęcamy namodyfikację istniejącego kodu niż natworzenie nowegoImplementation Patterns
  • 87. • Komunikacja – kod źródłowy powinnosię czytać jak książkę• Prostota – wprowadzaj złożonośćtylko wtedy, kiedy jest to konieczne• Elastyczność – elastyczność tododatkowa złożoność, więcwprowadzaj ją tylko tam gdzie tokonieczneImplementation patterns
  • 88. • Lokalne konsekwencje – zmiana wjednym miejscu nie powoduje zmian winnych• Minimalne powtórzenia – DRYImplementation patterns
  • 89. • Dane i logika razem – ponieważ danei logika z reguły zmieniają się w tymsamym czasie• Symetria – utrzymuj podobny poziomabstrakcji w obrębie metody / klasyImplementation patterns
  • 90. „Czysty kod jest prosty i bezpośredni.Czysty kod czyta się jak dobrzenapisaną prozę. Czysty kod nigdy niezaciemnia zamiarów projektanta; jestpełen trafnych abstrakcji i prostychścieżek sterowania.”Grady Booch – to jeden z tych panów od UMLa
  • 91. Po co to wszystko?
  • 92. Complexity and confusion
  • 93. Complexity and confusion
  • 94. Affordance
  • 95. Affordancea quality of an object, whichallows an individual to performan action. For example, a knobaffords twisting, and perhapspushing, while a cord affordspulling
  • 96. public class Sql {public Sql(String table, Column[] columns)public String create()public String insert(Object[] fields)public String selectAll()public String fieldByKey(String keyColumn, String keyValue)private String ColumnList(Column[] columns)private String valuesList(Object[] fields, final Column[] columns)}
  • 97. abstract public class Sql {public Sql(String table, Column[] columns)abstract public String generate();}public class CreateSql extends Sql {public CreateSql(String table, Column[] columns)@Override public String generate()}public class SelectSql extends Sql {public SelectSql(String table, Column[] columns)@Override public String generate()}public class InsertSql extends Sql {public InsertSql(String table, Column[] columns)@Override public String generate()private String valuesList(Object[] fields, final Column[] columns)}public class FindKeyBySql extends Sql {public FindKeyBySql(String table, Column[] columns, String keyColumn, String keyValue)@Override public String generate()}public class ColumnList {public ColumnList(Column[] columns)public String generate()}
  • 98. Po co to wszystko?
  • 99. Budujemy nawyki
  • 100. By żyło się lepiej
  • 101. Szukamy doświadczenia, pytamy
  • 102. Samodzielnie poszukujemy drogi
  • 103. Stosujemy framework na siłę
  • 104. Porzucamy framework i robimy po staremu
  • 105. By w sytuacjach trudnych…
  • 106. … brniemy nie wiadomo gdzie …
  • 107. … mimo że cel był wyraźny
  • 108. Jak żyć?
  • 109. Jak żyć?
  • 110. Jak żyć?
  • 111. Jak żyć?
  • 112. Jak żyć?
  • 113. Jak żyć?2010
  • 114. Jak żyć?2010
  • 115. Jak żyć?20102009
  • 116. Jak żyć?20102009
  • 117. Jak żyć?20102009
  • 118. Jak żyć?201020092009
  • 119. Jak żyć?201020092009
  • 120. Jak żyć?2010200920092008
  • 121. Jak żyć?2010200920092008
  • 122. Jak żyć?20102009200920082007
  • 123. Jak żyć?
  • 124. Jak żyć?2002
  • 125. Jak żyć?2002
  • 126. Jak żyć?20021996 / 2000
  • 127. Jak żyć?20021996 / 2000
  • 128. Jak żyć?20021996 / 20002002
  • 129. Jak żyć?20021996 / 20002002
  • 130. Jak żyć?20021996 / 200020021994
  • 131. Jak żyć?
  • 132. Jak żyć?
  • 133. Shu-Ha-Ri
  • 134. jmarchwicki@ydp.eutwitter: @kubemStoisko 25Shu-Ha-Ri