[PL] Jak programować aby nie zwariować

546 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
546
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

[PL] Jak programować aby nie zwariować

  1. 1. Jak programować abynie zwariować?Jakub Marchwicki20.05.2013
  2. 2. Na początek
  3. 3. Co to za gość?
  4. 4. Co ja tu robię?
  5. 5. Co ja tu robię?
  6. 6. Co ja tu robię?
  7. 7. Co ja tu robię?ból
  8. 8. Co ja tu robię?bólliczba slajdów
  9. 9. Co ja tu robię?bólliczba slajdówOKRyzykoutratyzdrowia35 slajdów
  10. 10. Co ja tu robię?bólliczba slajdówOKRyzykoutratyzdrowia148 slajdów
  11. 11. Punkt wyjścia
  12. 12. Kiedy software jest dobry?Oprogramowanie musi działaćMusi być na czasMusi być rozbudowywalneModyfikowalneMusi mieć odpowiednią jakośćPunkt wyjścia
  13. 13. Punkt wyjścia
  14. 14. I po co to wszystko?Bo software to nasze hobby
  15. 15. I po co to wszystko?Bo software to nasze hobbyfach
  16. 16. I po co to wszystko?Bo software to nasze hobbyfachzawód
  17. 17. I po co to wszystko?Bo software to nasze hobbyfachzawódprzyjemność
  18. 18. I po co to wszystko?bo płacą nam za pisaniedokumentacjipisanie kodu to przyjemność
  19. 19. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  20. 20. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  21. 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. 22. Więc czym jest jakośćDla kogoś Dla siebieDla kogo pracuje?
  23. 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. 24. Jak programować aby nie zwariować?
  25. 25. Czysty kod
  26. 26. Czysty kod
  27. 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. 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. 29. • Nazwy• Funkcje• Komentarz• Formowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  30. 30. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  31. 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. 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. 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. 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. 35. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  36. 36. • Zasada pierwsza:funkcje powinny być małe• Zasada druga:funkcje powinny być jeszcze mniejszeFunkcje
  37. 37. Functions should do one thing.Should do it wellShould do it only!Funkcje
  38. 38. writeField(outputStream, name);outputStream.writeField(name);createSquare(width, height);calculateRectangularPrismVolume(double height,double width, double depth);calculateRectangularPrismVolume(Area rectangle,double depth);
  39. 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. 40. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  41. 41. KomentarzeDON’T
  42. 42. Komentarze„Nie komentuj złego kodu – popraw go”Brian W. Kernighan i P.J. Plaugher
  43. 43. //Sprawdzenie czy klient ma możliwość korzystania ze zniżkiif (customer.isStudent() ||(customer.age < 18) || (customer.age > 65))if (customer.isEligibleForDiscount())
  44. 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. 45. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  46. 46. Formatowanie• Konwencje formatowania w zespole.Ustal i się ich trzymaj
  47. 47. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  48. 48. • Prawo Demeter – zasada minimalnejwiedzy• Moduł powinien nie wiedzieć nic ownętrzu obiektów, którymi manipulujePrawo Demeter
  49. 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. 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. 51. final String outputDir = context.getOptions().getScratchDir().getAbsolutePath();Options options = context.getOptions();File scratchDir = options.getScratchDir();final String outputDir = scratchDir.getAbsolutePath();
  52. 52. • Nazwy• Funkcje• Komentarz• Formatowanie kodu• Obiekty i struktury danych• Obsługa błędówPoziom I
  53. 53. Zwracanie nullDON’T
  54. 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. 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. 56. • Przekazywanie null jest gorsze odjego zwracaniaPrzekazywanie nullpublic class MetricsCalculator {public double rectanglePerimeterCalculate(double x, double y) {return 2 * (y + x);}/* ... */}
  57. 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. 58. Miara czystego kodu
  59. 59. Czysty projekt
  60. 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. 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. 62. To znaczy jaki?Kod obiektowy
  63. 63. • Odpowiedzialność – tylko jedna obiekty maja własną osobowość,unikaj schizofrenicznych obiektów• Enkapsulacja – to co się zmienia jesthermetyzowane• Preferencja kompozycji ponaddziedziczenie
  64. 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. 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. 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. 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. 68. • Każdy wzorzec opisujemy w trzechkontekstach: Odpowiedzialność Enkapsulacja / hermetyzacja KompozycjaWzorce projektowe
  69. 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. 70. Wzorce projektowe: komenda
  71. 71. • Każdy element systemu: Ma swoją odpowiedzialność Hermetyzuje pewne zachowania Składa się z kilku współpracującychelementówModuły
  72. 72. • Każdy framework opisujemy w trzechzdaniach: Odpowiedzialność Enkapsulacja Preferowanie kompozycjiFrameworki
  73. 73. • Spring czy EJBNie ma idealnych rozwiązań
  74. 74. • Spring czy EJB• JSF czy JSPNie ma idealnych rozwiązań
  75. 75. • Spring czy EJB• JSF czy JSP czy VelocityNie ma idealnych rozwiązań
  76. 76. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatisNie ma idealnych rozwiązań
  77. 77. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBCNie ma idealnych rozwiązań
  78. 78. • Spring czy EJB• JSF czy JSP czy Velocity• JPA czy iBatis czy JDBC• MVC czy MVPNie ma idealnych rozwiązań
  79. 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. 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. 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. 82. Nie ma idealnych złoytych środków
  83. 83. SOLIDny programista
  84. 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. 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. 86. • Programy są częściej czytane niżpisane• Więcej czasu poświęcamy namodyfikację istniejącego kodu niż natworzenie nowegoImplementation Patterns
  87. 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. 88. • Lokalne konsekwencje – zmiana wjednym miejscu nie powoduje zmian winnych• Minimalne powtórzenia – DRYImplementation patterns
  89. 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. 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. 91. Po co to wszystko?
  92. 92. Complexity and confusion
  93. 93. Complexity and confusion
  94. 94. Affordance
  95. 95. Affordancea quality of an object, whichallows an individual to performan action. For example, a knobaffords twisting, and perhapspushing, while a cord affordspulling
  96. 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. 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. 98. Po co to wszystko?
  99. 99. Budujemy nawyki
  100. 100. By żyło się lepiej
  101. 101. Szukamy doświadczenia, pytamy
  102. 102. Samodzielnie poszukujemy drogi
  103. 103. Stosujemy framework na siłę
  104. 104. Porzucamy framework i robimy po staremu
  105. 105. By w sytuacjach trudnych…
  106. 106. … brniemy nie wiadomo gdzie …
  107. 107. … mimo że cel był wyraźny
  108. 108. Jak żyć?
  109. 109. Jak żyć?
  110. 110. Jak żyć?
  111. 111. Jak żyć?
  112. 112. Jak żyć?
  113. 113. Jak żyć?2010
  114. 114. Jak żyć?2010
  115. 115. Jak żyć?20102009
  116. 116. Jak żyć?20102009
  117. 117. Jak żyć?20102009
  118. 118. Jak żyć?201020092009
  119. 119. Jak żyć?201020092009
  120. 120. Jak żyć?2010200920092008
  121. 121. Jak żyć?2010200920092008
  122. 122. Jak żyć?20102009200920082007
  123. 123. Jak żyć?
  124. 124. Jak żyć?2002
  125. 125. Jak żyć?2002
  126. 126. Jak żyć?20021996 / 2000
  127. 127. Jak żyć?20021996 / 2000
  128. 128. Jak żyć?20021996 / 20002002
  129. 129. Jak żyć?20021996 / 20002002
  130. 130. Jak żyć?20021996 / 200020021994
  131. 131. Jak żyć?
  132. 132. Jak żyć?
  133. 133. Shu-Ha-Ri
  134. 134. jmarchwicki@ydp.eutwitter: @kubemStoisko 25Shu-Ha-Ri

×