Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PHPCon Poland 2015 - Jak stać się lepszym programistą - Jerzy Zawadzki

2,660 views

Published on

Pisanie czystego kodu, znajomość i przestrzeganie zasad SOLID, DDD, BDD czy TDD nie wystarczy, by być dobrym programistą. Opowiem, co tak naprawdę składa się na jakość oprogramowania, postaram się Was przekonać do bardziej pragmatycznego podejścia do jego tworzenia oraz pokażę proste zasady, które sprawią, że każdy Wasz projekt będzie udany.

Published in: Software
  • Świetna prezentacja! Ja bym tylko zamienił pytanie "dlaczego?" na "po co?". Zazwyczaj klienci nie do końca rozumieją swoje rzeczywiste potrzeby, a to pytanie lepiej kieruje na proces odkrycia celowości danej funkcjonalności. Pytanie "dlaczego?" bardziej skłania do poszukiwania uzasadnienia (potwierdzenia) konieczności wprowadzenia funkcjonalności, bez analizy rzeczywistych potrzeb.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

PHPCon Poland 2015 - Jak stać się lepszym programistą - Jerzy Zawadzki

  1. 1. JAK STAĆ SIĘ LEPSZYM PROGRAMISTĄ? 1
  2. 2. Jerzy Zawadzki - Programista PHP z 10-letnim stażem - Senior PHP Developer w firmie Polcode, w której pracuje ponad 7 lat - na co dzień zajmuje się prowadzaniem projektów opartych o Symfony2 lub Magento. - Zend Certified Engineer - Magento Certified Developer - w wolnych chwilach chodzę po górach, biegam z aparatem za służbami specjalnymi albo buduje coś z klocków LEGO 2
  3. 3. - założona w 2006r. przez programistów - PHP (m.in. Symfony 2, Laravel, ZF, Magento, Wordpress) - Ruby On Rails - Python - klienci głównie z Ameryki Północnej, Europy Zachodniej i Australii - 800 zadowolonych klientów - 1200 zakończonych projektów - >100 programistów - Warszawa, Kraków, Katowice, Łodź, Białystok - + zdalnie - - założona w 2006r. przez programistów - PHP (m.in. Symfony 2, Laravel, ZF, Magento, Wordpress) - Ruby On Rails - Python - klienci głównie z Ameryki Północnej, Europy Zachodniej i Australii - 800 zadowolonych klientów - 1200 zakończonych projektów - >100 programistów - Warszawa, Kraków, Katowice, Łódź, Białystok + zdalnie 3
  4. 4. 4
  5. 5. JAK STAĆ SIĘ LEPSZYM PROGRAMISTĄ? 5
  6. 6. CO TO ZNACZY BYĆ DOBRYM PROGRAMISTĄ? 6
  7. 7. JESTEM DOBRYM PROGRAMISTĄ BO ... MAM 10 LAT DOŚWIADCZENIA? 7
  8. 8. JESTEM DOBRYM PROGRAMISTĄ BO ... MAM 10 LAT DOŚWIADCZENIA? 8
  9. 9. JESTEM DOBRYM PROGRAMISTĄ BO ... ZNAM WSZYSTKIE METODYKI/ZASADY PROGRAMOWANIA? 9
  10. 10. Abstraction principle, Code reuse, Cohesion, Command–query separation, Defensive programming, Dependency inversion principle, Discoverability, Don't repeat yourself, Fail-fast, GRASP, Hollywood principle, Information hiding, Interface segregation principle, Inversion of control, KISS principle, Law of Demeter, Liskov substitution principle, Loose coupling, MINASWAN, Open/closed principle, Principle of least astonishment, Separation of concerns, Separation of mechanism and policy, Single responsibility principle, SOLID, Uniform access principle, 80:20 rule, Amdahl's law, Code smell, Deutsch limit, Greenspun's tenth rule, Gustafson's law, If it ain't broke, don't fix it, IIABDFI, MINASWAN, Ninety-ninety rule, Rule of three, Zero one infinity rule, Acceptance test-driven development, After the Software Wars, Agile Manifesto, Agile software development, Behavior-driven development, The Cathedral and the Bazaar, Comment programming, Cowboy coding, Design-driven development, Domain-driven design, Extreme programming, Formal methods, Hollywood principle, Homesteading the Noosphere, Integration competency center, Iterative and incremental development, Kanban, KISS principle, Lean integration, Lean software development, Lightweight methodology, The Magic Cauldron, Mayo-Smith pyramid, Micro-innovation, Minimalism, Open/closed principle, Planning poker, PM Declaration of Interdependence, Release early, release often, Retrenchment, Rule of least power, Secure by design, Slow programming, Specification by example, Test double, Continuous test-driven development, Test-driven development, Test-Driven Development by Example, There's more than one way to do it, Transformation Priority Premise, Unix philosophy, Waterfall model, Worse is better, You aren't gonna need it, https://en.wikipedia.org/wiki/Category:Software_development_philosophies 10
  11. 11. JESTEM DOBRYM PROGRAMISTĄ BO ... NIE KORZYSTAM Z FRAMEWORKÓW? 11
  12. 12. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ W NOTATNIKU? 12
  13. 13. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ DOBRY KOD? 13
  14. 14. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ DOBRY KOD?? 14
  15. 15. 1. O DOBRYM KODZIE 15
  16. 16. “”Zawsze pisz kod tak, jakby gość, który ma się nim zajmować był agresywnym psychopatą, który wie, gdzie mieszkasz” – Martin Golding. 16
  17. 17. KISS 17
  18. 18. nie da się napisać idealnego kodu 18
  19. 19. da się napisać wystarczająco dobry kod 19
  20. 20. BRZYDKI KOD który robi to co powinien jest LEPSZY od najpiękniejszego ale NIEDZIAŁAJĄCEGO 20
  21. 21. 2. O DOBRYM PROJEKCIE 21
  22. 22. The Psychology of Computer Programming Gerald M. Weinberg 1971 22
  23. 23. Jakość oprogramowania wg Weinberga - Używaj symfony - DDD! - BDD! - Absolutnie nie pisz w Laravelu - Nie dotknij nigdy Wordpressa - Najlepiej to w ogóle nie pisz w php bo jest głupi 23
  24. 24. Jakość oprogramowania wg Weinberga - Używaj symfony - DDD! - BDD! - Absolutnie nie pisz w Laravelu - Nie dotknij nigdy Wordpressa - Najlepiej to w ogóle nie pisz w php bo jest głupi 24 X
  25. 25. Jakość oprogramowania zgodne ze specyfikacją o czasie i w budżecie wydajne w danym środowisku łatwe w adaptacji do zmieniających się wymagań 25
  26. 26. zgodne ze specyfikacją 26
  27. 27. poszukiwanie wymagań 27
  28. 28. o czasie i w budżecie 28
  29. 29. “Zadanie zawsze zajmie więcej czasu niż myślisz. Nawet jeśli wziąłeś pod uwagę Prawo Hofstadtera - Douglas Hofstadter Prawo Hofstadtera 29
  30. 30. “Napisanie pierwszych 90% kodu aplikacji zajmuje 90% czasu pracy. Napisanie pozostałych 10% kodu zajmuje pozostałe 90% czasu pracy. - Tom Cargill, Bell Labs Zasada wiarygodności (90:90) 30
  31. 31. wydajne w danym środowisku 31
  32. 32. Nie piszecie facebooka* 32
  33. 33. Optymalizacja jako “sztuka dla sztuki” 33
  34. 34. Serwery są tańsze od czasu programistów 34
  35. 35. Najszybsze zapytanie to takie które się nie wykona 35
  36. 36. 36
  37. 37. Najszybszy kod to taki który się nie wykona 37
  38. 38. łatwe w adaptacji do zmieniających się wymagań 38
  39. 39. które wymagania systemu mogą się zmienić? Wszystkie! 39
  40. 40. 40
  41. 41. 41 X
  42. 42. W dużych projektach nie ma możliwości przygotowania się na każdą zmianę. 42
  43. 43. Jakość oprogramowania zgodne ze specyfikacją o czasie i w budżecie wydajne w danym środowisku łatwe w adaptacji do zmieniających się wymagań 43
  44. 44. 44
  45. 45. 45
  46. 46. 3. O DOBRYM PROGRAMIŚCIE 46
  47. 47. MYŚL 47
  48. 48. Nie myśl TYLKO o kodzie 48
  49. 49. - kliencie i jego potrzebach - użytkowniku - problemie - utrzymaniu kodu - przyszłości - innych programistach MYŚL O 49
  50. 50. Zachowuj się jak PROFESJONALISTA 50
  51. 51. Trzymaj się standardów 51
  52. 52. Nie bój się powiedzieć: NIE WIEM 52
  53. 53. Sprawdź w specyfikacji Pytaj klienta 53
  54. 54. Pytaj DLACZEGO? 54
  55. 55. Komunikacja 55
  56. 56. Empatia. 56
  57. 57. 57
  58. 58. Nie ma jednego słusznego rozwiązania dla większości problemów 58
  59. 59. 59
  60. 60. Jeśli coś jest głupie, ale działa, to nie jest głupie. 60
  61. 61. DZIĘKUJĘ Pytania? 61

×