Your SlideShare is downloading. ×
[PL] Jak programować aby nie zwariować
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

[PL] Jak programować aby nie zwariować

332

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
332
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
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

×